Data handling
What data lives where — sandbox disks, volumes, database backups, snapshots — what happens on delete, and how credentials and TLS are handled.
A short, factual map of where customer data lives on PandaStack, how long it persists, and how it is protected in transit and at rest.
Where data lives
| Data | Where it lives | Durability |
|---|---|---|
| Sandbox rootfs | Copy-on-write clone on the host's local NVMe | Ephemeral — removed when the sandbox is deleted |
| Sandbox snapshots / hibernation state | Host disk, replicated to Google Cloud Storage for cross-host restore and wake | Persists while the owning sandbox exists |
| Volumes | Named ext4 image on one agent host | Durable until you delete the volume |
| Managed database data | Dedicated durable volume on the database's host | Durable; plus off-host backups (below) |
| Database backups | Daily pg_basebackup + continuous WAL archive in Google Cloud Storage | Retained for your plan's PITR window (7/30/90 days) |
| App source | Cloned from your git provider into the app's VM at deploy time | Re-fetched per deploy; not a system of record |
| Control-plane metadata | PostgreSQL (org, member, sandbox, app, and deployment records, including app environment variables and build logs) | Durable |
| Metrics and lifecycle events | ClickHouse | Operational telemetry, not file contents |
Object storage (GCS) encrypts all stored data at rest with provider-managed keys; host disks are cloud provider block storage with the provider's at-rest encryption.
Retention on delete
- Sandbox delete tears down the VM and removes its rootfs clone from the host. Attached volumes are detached, not deleted.
- Volume delete unlinks the image immediately and irreversibly — there is no undelete and no soft-delete window. See volumes for the semantics around deleting a volume that is still attached.
- Database delete deletes the database VM, its durable volume, and all of its backups, including the WAL archive. This is irreversible; there is no grace-period copy retained. See backups & restore.
- App delete deletes the app record and its runtime sandbox.
Within the retention window, deleted databases' backups do not linger: deletion removes the archive, not just the pointer.
Credentials
- Database credentials are generated per database at provision time. The password is returned in the create response and is only otherwise readable from the single authenticated
GET /v1/databases/{id}endpoint while the database is running — store it in your secret manager. Compromised credentials can be rotated in one call withreset-credentials, which rotates both the PostgreSQL password and the REST broker token and returns verified new values. A per-database IP allow list is available as defense-in-depth on top of TLS and the password. - App environment variables are stored in the control plane and injected into the app's VM at deploy time. Treat them as secrets-capable configuration; they are visible to workspace members with access to the app.
- GitHub access for private-repo deploys uses short-lived GitHub App installation tokens minted on demand for each clone. They are never persisted.
- API keys authenticate every control-plane request; the sandbox UUID additionally acts as the bearer credential for preview URLs.
TLS everywhere
- The API (
api.pandastack.ai), the dashboard, and all preview and app URLs are served exclusively over HTTPS. - Managed database connections are routed by SNI on
<id>.db.pandastack.aiand require TLS (sslmode=require); plaintext PostgreSQL connections are not accepted. - Internal replication of snapshots, seeds, and backups to object storage goes over TLS to GCS.
What we do not have
There is no shared multi-tenant database cluster, no shared container kernel, and no plaintext database listener. Sandbox file contents are not scanned or indexed by the platform; operational telemetry (boot timings, lifecycle events, resource usage) is what we collect. For the isolation boundary around all of the above, see the isolation model.
Isolation model
Every sandbox, app, and database runs in its own Firecracker microVM with its own kernel — hardware virtualization, not a shared container kernel.
Egress controls
How outbound traffic leaves a VM, what is blocked between tenants and to cloud metadata, and the abuse controls applied to egress.