Data posture and deployment · Saphan Studio documentation

Your machines, your record: what the product asks of your infrastructure, what runs centrally, and what it asks you to own.

Your machines, your record. Saphan's execution model is your fleet: the control plane and the runners are machines you own or rent, the record lives in a PostgreSQL store on infrastructure you control, and the product opens no listening port on a runner. The management surface binds to loopback by default; widening the bind is a deliberate, explicitly-addressed act refused at every configuration tier when ambiguous.

Distribution is deliberately boring, and it has two halves. For a fleet machine — a runner, or a seat you dispatch work to — a deb, an rpm, or the macOS installer delivers exactly three binaries — the CLI (saphan), the agent (saphan-agent) and the console (saphan-gateway): no services started, no configuration written, no home directory touched, and every scripted path verifies checksums before anything lands (Installation). What runs is inspectable; what is installed is enumerable.

Centrally, the product is a set of servers rather than a single daemon, and each is a separate process you start by an explicit verb — nothing on any install path starts one for you:

saphan server — the owner's console and every screen under it, the read-only MCP projection, and the route a fleet machine bootstraps from. It is a verb of the saphan CLI, not a separate artifact, so it needs no install of its own.
saphan-gateway — the versioned client contract under /v1, and the console screens built from the shipped UI bundle. Stateless by construction: it owns no database, decision cache or session, and the boundary is asserted by a test that cuts the import graph at the engine door rather than by this sentence.
saphan-oauth — the OAuth 2.1 authorization server this product ships: a standalone issuer publishing its own discovery documents and key set, with seat and client administration. Its issuer name comes from configuration and from no request header. It is one of the three ways the bearer-gated management surface can be fed, beside the self-issued PKCE server built into saphan server and your own IdP — and like an external IdP it reaches the engine only through the human-gated issuer trust list, never by being present.

What a central deployment places, beyond what every delivery route carries: these two programs. Central servers gives the numbered start-up ceremony for each and what to do when either refuses to start. Which delivery route carries which program is machine-checked: the product's own suite reads what each route actually carries and refuses any disagreement with these pages.

Identity is the only thing a hosted service should touch. The product doctrine for Saphan-operated convenience services is fixed and simple: identity passes; data never. Hosted components exist to make authentication and authorization convenient across a team — they are not a channel for repository content, and the self-hosted path remains first-class for organizations that want nothing of theirs to transit anyone else's infrastructure.

Deployment postures. Solo runs everything on one machine, management surface on loopback. Team adds hosted identity and remote reach. Enterprise differs by features, not by scale caps: the customer's own IdP behind the issuer trust list (an external IdP authenticates; authorization vocabulary and actor binding remain the engine's — measured live against a third-party client that attempted to grant itself claims through dynamic registration and was refused by construction), central PostgreSQL record, and the observability surface in section 10.

What we ask you to own. Consistent with the security document's candor: egress control ships and is opt-in per run — a dispatch that passes saphan run --egress-policy is judged by a policy you author and confined to a per-run proxy, and one that does not is not. Until every dispatch in your fleet asks for it, egress control at your network boundary remains your responsibility, and runners should hold nothing beyond their own scope. There is no fleet-wide switch in this release (Writing a policy is the operator's procedure, Documented limits the auditor's statement). Where a control does not enforce by default, Saphan documents the gap instead of claiming it.

Added for this site

Where this page comes from, and what is deliberately not here. The product's docs/Enterprise deployment is written for three readers — a security architect, a compliance officer, a platform owner — and only one of its eleven sections is about deployment. That section is above, whole. Its neighbours belong to sections of this site that other chapters fill: the enterprise control floor and the signed record, the gate and segregation-of-duties argument, the cryptographic inventory, and the regulatory mapping to ISO/IEC 42001, ISO/IEC 27001, SOC 2, the NIST AI RMF and the EU AI Act.

One forward reference above points at a document that is not on this site. "the observability surface in section 10" is Enterprise deployment section 10, the enterprise roadmap. It is named rather than linked, because inventing what it says here would create a second text — and there is only ever one. The other two are published: Egress control is the operator's policy chapter and Security the auditor's statement on documented limits.