Sandboxes
A short-lived copy of the whole application, with its own built-ins, credentials, network and lifetime.
A sandbox runs everything parity.yaml describes: every service, every built-in and every job, from the same images staging and production run. It exists for one task, one branch or one agent, and is deleted with all its data when its time is up.
What each sandbox gets
| Namespace | Its own Kubernetes namespace, default-deny network policy and resource quota. |
| Built-ins | Its own Postgres, Redis, S3 buckets, inbox, OIDC issuer and certificate authority, with generated credentials. |
| Secrets | Generated per sandbox. A sandbox never reads staging or production secrets. |
| Hostnames | <host>--<sandbox>--<account>.env.parity.ninja, with TLS. |
| Egress | Only the externals hosts its services list that the promoted manifest also allows. |
| Token | A sandbox token, printed once at creation, that reaches this sandbox only. |
| Lifetime | 2 hours by default, extendable up to sandbox.max_ttl (24 hours by default). |
Inside a sandbox, services and built-ins reach each other by name: db:5432, cache:6379, http://web:8080.
Lifecycle
starting ⇄ ready → expiring
↘ failed- Create.
parity upuploads the source, builds what changed, and creates the namespace and built-ins. - Set up. Jobs run by phase:
deploy, thenseed, thenstart. Within a phase they run in parallel unlessdepends_onorders them. A failed job fails the sandbox and its log tail is in the response. - Ready. Services start once setup is done and pass their health checks.
- Update.
parity upagain rolls the sandbox onto new code or a changed manifest. Data and generated secrets stay;deployjobs run again. - Delete.
parity down, or the end of its lifetime, runsdestroyjobs and deletes everything.
Fast starts
An image built for the same files and build args is reused across all of a project's sandboxes, so a second sandbox on the same commit starts without building. With a develop block, an edit copies files into the running service instead of rebuilding: about 1 to 2 seconds for a synced change.
Sizes and limits
| Limit | Default |
|---|---|
| Sandbox ID | Lowercase letters, digits and single -, at most 26 characters |
| Lifetime | ttl: 2h, max_ttl: 24h (set in sandbox) |
| Replicas | 1 per service; parity scale web 3 for one sandbox, at most 10 |
| Resources per service | 100m CPU and 256Mi requested, 2 CPU and 2Gi limit, unless resources says otherwise |
| Proof bundles | 20 per sandbox |
A manifest can make its sandboxes stricter than these, never looser.