One deployment is one workspace, one identity-provider organization, and one
managed Postgres project with private object storage. Another customer means
another deployment. There is no in-process tenant partitioning.
Production topology
- One application image (Cloud Run).
- One managed Postgres project providing SQL plus private Storage.
- One private temporal node (XTDB 2.2) with a persistent local log and remote
object storage.
- Secret Manager for exact process bindings.
Local development uses PostgreSQL, MinIO, and a persistent single-node temporal
engine.
What a deployment loads
A deployment loads one exact model revision and the immutable secret-version lock
that revision was built against. Products with locked secrets use workload
identity in production; local development uses the developer’s own explicit
application-default credentials.
A deployment does not accept ambient connector bindings. A released product
already owns every connector literal and every exact locked secret version.
Rebuilding
The deployment’s disposable state — the local development database, object
store, and captured source plane — is rebuildable from the model revision and a
fresh capture. The two things that are not rebuildable are the operational
ledger and the immutable file catalogue, which is why the serving role cannot
write to either.
Health
The workspace’s Assurance page is the operator surface: one dated,
credential-free readiness summary covering identity, product release,
connectors, source capture, model qualification, backup and restore, audit
export, and promotion evidence. Every unproved control stays visible with the
exact remediation next to it.
Deployment-internal verification runs beside it:
