Skip to main content
Use the reviewed Node controller and rendered manifests for the selected release. Existing hosted inventory and release candidates are described in operations; source defaults are not proof of production configuration.

Admission and capacity

Qualify resource limits, organization concurrency, billing admission, selected region, RuntimeClass, image pull, and actual node capacity. Runtime/region labels do not create compatible nodes. Shared/dedicated resource_class has separate deployment and billing requirements; unsupported shared capacity can be rejected before creation. Warm pools match admitted profiles and isolation. They improve specific warm paths, not unbounded cold provisioning. Persistent/durable workspaces cold-start. Budget image pulls, node scheduling, API retries, and task lifetime independently; use observed workload profiles instead of the previous docs’ universal startup or throughput estimates.

Time budgets

A client timeout does not prove a command or create request was cancelled. Stop/cancel acknowledgements need eventual outcome/cleanup verification. Retain original request identity instead of adding an outer retry loop around SDK mutations.

Persistence

Use production PostgreSQL and shared coordination where the feature requires them. Redis needs explicit persistence, eviction policy, backup/recovery, and HA design. The recorded single-primary PVC migration does not establish HA. Preserve encryption keys, migration ledger, artifact objects, runtime specs, receipts, and configuration during restore. Persistent workspace creation needs an enabled storage class and bounded volume sizes. CSI branching additionally needs snapshot CRDs/controller/driver and a compatible snapshot class. Configured-but-unavailable persistent storage gates readiness; CSI degradation can use a portable file-checkpoint fallback. Both need real restore evidence. Candidate DB tunnels require migration 069 and a coordinated transition from memory mode. Existing active tunnels and receipts cannot be silently reinterpreted against another store. See artifact/tunnel contracts.

Network, secrets, and identity

Use an enforcing NetworkPolicy implementation, verified runtime nodes, restricted workload service accounts, TLS, and explicit ingress/egress configuration. Test denied destinations and metadata/internal addresses; monitor mode is observation rather than broad enforcement. Configure organization secrets and credential/inference gateways without exposing provider credentials in sandbox environment or task logs. Email verification and route/sandbox roles apply to API keys, events, and WebSockets. Upgrade legacy keys through the documented migrations and preserve verified operator access. Check security boundaries.

Release acceptance

Bind the exact source, built artifact/image digest, migration state, rendered configuration, and executed observations. Check creation/execution/results, lost-response recovery, cancellation/termination, log rotation, worker observation, artifact integrity/expiry, private tunnels, and cleanup against the deployed release. A source tag or runtime probe does not establish publication, independent security review, production scale, regional availability, or a service-level commitment. Follow the repository’s release/rollback and component-specific runbooks; qualify a restore before live use. Start with self-host profiles, then use operations to record acceptance. Source basis: docs/SELF_HOST.md, workspace/pause/egress guides, and release records, checked October 20, 2026.
Last modified on October 20, 2026