Data posture and deployment

Your machines, your record. Saphan Studio's execution model is your fleet: the control plane and the runners are machines you own or rent, the record lives in a store on infrastructure you control — an embedded file by default, PostgreSQL when you configure it — and nothing the product runs on a runner listens beyond loopback. The management surfaces bind to loopback by default; widening a bind is a deliberate act, and an ambiguous or unprotected address is refused rather than read as "every interface".

Distribution is deliberately boring. For a fleet machine — a runner, or a machine you dispatch work to — the one-line install, a deb, an rpm, or the macOS installer delivers the same four binaries: the CLI (saphan), the agent (saphan-agent), the console (saphan-gateway) and the server (saphan-server). The packages start no services, write no configuration and touch no home directory, and every scripted path verifies checksums before anything lands (Deployment). What runs is inspectable; what is installed is enumerable.

Centrally, the product is a set of processes rather than a single daemon, and each is started by an explicit verb or by the supervisor units you choose to register:

• saphan-server — the mailbox and chat integrations, the act authority that verifies a person's passkey before an act is recorded, and the read-only projection of the record.
• saphan-gateway — the versioned client contract under /v1, and the console screens. Stateless by construction: it owns no database, decision cache or session.
• saphan-oauth — the OAuth 2.1 authorization server: 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, and like an external identity provider it reaches the engine only through the human-gated issuer trust list, never by being present. ⚠ No release artifact carries it today.

Central servers says what each one needs from you.

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 — they are not a channel for repository content. ⚠ In this release the browser setup page signs the owner in through the Saphan portal; a site that wants no outside call at all sets the machine up from a terminal with saphan install instead.

Deployment postures. Solo runs everything on one machine, management surface on loopback. Team adds shared identity and remote reach; Enterprise differs by features, not by scale caps: the customer's own identity provider behind the issuer trust list (an external provider authenticates; authorization vocabulary and actor binding remain the engine's), and a central PostgreSQL record. ⚠ This release sets up Solo only; Team and Enterprise cannot be chosen at setup yet.

What we ask you to own. Egress control is closed by default: a run reaches only its backend's model hosts and its declared toolchain registries, and a machine that cannot enforce that refuses the run rather than running it open. A run is opened only by an explicit, recorded --egress-open "<reason>". It is still one layer: egress control at your network boundary remains your responsibility, and runners should hold nothing beyond their own scope (Egress control is the operator's chapter, its limits the auditor's statement).