Team begins when one workstation is no longer the whole organization.
Saphan Team puts central identity and fleet services around the same governed work. Saphan operates the identity service and mobile notification signalling; the fleet, code and operational record remain on customer-controlled infrastructure.
What exists today
Saphan manages Team identities
In Team, Saphan operates saphan-oauth as a SaaS identity service. Invite, claim, list, reset and revoke remain explicit human acts; revocation closes sessions, passwords, pending invitations and standing credentials. Seats are counted. Workloads are not.
The fleet has central surfaces
saphan-gateway serves the versioned client API and shipped console bundle. saphan server serves the owner console, read-only MCP projection and machine bootstrap route. The gateway is stateless and owns no parallel decision store.
Machines and seats are governed facts
Every machine is admitted by an explicit owner act. Each execution slot carries a named seat with its own isolated agent profile, so several accounts and agent backends can coexist without sharing sessions or credentials. Capability is probed and recorded, not assumed.
The record has a shared-store foundation
The PostgreSQL backend exists, alongside the local SQLite posture. Gates, refusals, cost and provenance retain the same vocabulary across surfaces; projections are views over the record, never a second source of truth.
What changes from Solo
From local trust to Saphan-managed identity
Solo can trust a local operating-system boundary. Team introduces named people and server-side sessions through the Saphan-operated OAuth service, with an account lifecycle Saphan administers for the organization.
From one machine to an admitted fleet
The control plane connects outward to customer-owned machines. Runners expose no listening port and hold no credential to the control plane. A seat keeps its own vendor identity, role, billing class and measured capacity.
Identity and mobile signals cross the SaaS boundary. Code and records do not.
The Team identity service receives the identity data needed to authenticate and administer people. In Team and Enterprise, mobile push carries only an opaque gateId and the badge count — no record content and no stream slug. The app fetches the actual content from the customer gateway after authentication. Fully local identity belongs to Enterprise.
The boundary, stated honestly
Team identity boundary: Saphan operates saphan-oauth as SaaS and manages the organization’s identities.
Mobile signalling boundary: in Team and Enterprise, the notification path carries an opaque gate identifier and badge count only. Repository content, run evidence, the stream name and the operational record do not enter it.
Database: Team supports on-prem PostgreSQL.
Enterprise identity boundary: identity stays local — either customer-run saphan-oauth or any customer IdP admitted through the issuer trust list.
Read the deployment posture in Saphan Docs ↗What Enterprise adds →
Team inquiries
Talk to us about Team — hello@saphan.ai