Skip to main content
Temporary services are first-class sandbox resources backed by dedicated encrypted sidecar volumes. StackShift currently supports PostgreSQL, MySQL, and Redis. Each service has its own desired state, observed state, durable operation, runtime identity, resource limits, safe connection metadata, and failure details.
Services are temporary dependencies, not production databases. Deployment handoff excludes their data and credentials.

​
Create a service

The sandbox must exist and its capability policy must allow the engine and capacity. Names are DNS-safe lowercase identifiers; capacity is between the account/platform minimum and maximum.
Equivalent engine values are mysql and redis. Creation allocates the service resource and encrypted sidecar volume, then returns a mutation containing both the service and its operation. List or inspect services without exposing credentials:

​
Connect from the sandbox

connection_metadata contains only safe fields: host, port, database, username, the environment key (DATABASE_URL, MYSQL_URL, or REDIS_URL), and credential delivery mode. The generated connection URL is written to the sandbox’s volatile sidecar environment file and is not returned by list/get APIs or rendered in the dashboard. Read the environment from a newly started execution rather than copying a credential into source:
The explicit shell is required because $DATABASE_URL expansion is shell behavior. Do not print the variable, include it in errors, or write it to .env. Existing processes do not automatically gain newly created or rotated service credentials; restart them.

​
Lifecycle

Service states are queued, provisioning, starting, ready, sleeping, stopping, deleting, deleted, or failed. desired_state is separate and may be running, sleeping, or deleted.
Starting is idempotent when the service is already converging to or in the requested state. If an operation fails, inspect both its failure and the service’s failure_code/failure_message; do not create a duplicate service to hide an unresolved failure.

​
Snapshot database state

Use a group snapshot when the sandbox workspace and declared sidecars must form one recovery point:
The platform quiesces the workload, snapshots the workspace and sidecar members, records the quiesce result and member checksums, and resumes the workload. Check that the snapshot reaches ready before relying on it. Snapshot manifests exclude volatile service credentials; restored services receive fresh credential material. Restore replaces data in a sleeping target. Keep the default safety snapshot unless you have a deliberate reason not to:

​
Delete a service

Deletion permanently removes the service and its owned sidecar volume. Snapshot or export required data, inspect the service ID, then confirm explicitly:
Deleting a sandbox also revokes service access and schedules owned resources for cleanup. An independently retained snapshot is not deleted merely because its source sandbox is destroyed.

Security and persistence

Understand encryption, sleep, snapshots, and deletion.

Troubleshooting

Resolve readiness, capacity, snapshot, and recovery failures.