PandaStack
Security

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

DataWhere it livesDurability
Sandbox rootfsCopy-on-write clone on the host's local NVMeEphemeral — removed when the sandbox is deleted
Sandbox snapshots / hibernation stateHost disk, replicated to Google Cloud Storage for cross-host restore and wakePersists while the owning sandbox exists
VolumesNamed ext4 image on one agent hostDurable until you delete the volume
Managed database dataDedicated durable volume on the database's hostDurable; plus off-host backups (below)
Database backupsDaily pg_basebackup + continuous WAL archive in Google Cloud StorageRetained for your plan's PITR window (7/30/90 days)
App sourceCloned from your git provider into the app's VM at deploy timeRe-fetched per deploy; not a system of record
Control-plane metadataPostgreSQL (org, member, sandbox, app, and deployment records, including app environment variables and build logs)Durable
Metrics and lifecycle eventsClickHouseOperational 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 with reset-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.ai and 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.

On this page