Ephemeral environments

Apps and managed databases share one lifecycle — create, serve, scale-to-zero on idle, wake on demand, delete. What's guaranteed at each step, and when to reach for an ephemeral environment versus an always-on one.

PandaStack apps and managed databases are designed to be ephemeral — spun up for a pull request, an agent run, or a preview, then scaled to zero when idle and torn down when the work is done. This page explains the shared lifecycle, the guarantees PandaStack makes at each step, and how to decide when an ephemeral environment is the right tool.

Both apps and databases are persistent sandboxes (they opt into persistent: true), which means the TTL reaper that recycles ordinary sandboxes never deletes them. "Ephemeral" here means cheap to stand up and tear down, not deleted behind your back — only an explicit delete (or a PR closing, for previews) destroys data.

The lifecycle

An app and a database move through the same five states:

create ──► running ──► (idle) ──► hibernated ──► (request) ──► running ──► delete
                ▲                                      │
                └──────────────────────────────────────┘
                         wake-on-demand cycle

State	App	Database
create	`POST /v1/apps` stores config; the first deploy builds it	`POST /v1/databases` provisions a Postgres VM and waits for it to publish credentials
running	serving on its stable URL	accepting connections on `<id>.db.pandastack.ai:5432`
hibernated	snapshot + stop after `idle_timeout_seconds` of no traffic (default 15 min)	snapshot + stop after the agent idle window with no live connection
wake	the next request to the URL transparently restores it (typically sub-second)	the next connection through the proxy transparently restores it
delete	tears down the sandbox; previews are torn down automatically on PR merge/close	destroys the VM and durable volume; purges GCS backups

Scale-to-zero (hibernate → wake)

Idle environments are hibernated, not destroyed: the running VM's memory and disk state are snapshotted to local disk and the VM is stopped, which frees CPU/RAM and stops active-compute billing. The next request (an app URL hit, or a database connection) transparently wakes the environment from that snapshot and proceeds — concurrent requests during a wake are coalesced so only one wake happens.

Apps hibernate via the API-side idle sweep, keyed on last_request_at and the per-app idle_timeout_seconds. See Scale to zero.
Databases hibernate via the agent idle sweeper. A database with a live connection is never hibernated — a pooled client can hold a quiet connection for a long time, and the countdown only starts once the last connection closes.

Wake adds a one-time latency to the first request after an idle period (sub-second for apps; ~1–2s for a database, which then accepts connections normally). Pooled clients and ORMs that retry transparently absorb this; a single bare psql may need one reconnect.

Guarantees

What you can rely on, by resource:

Apps

Zero-downtime deploys. Every deploy builds on a fresh sandbox and only flips traffic after a health check passes (blue-green). The previous sandbox is kept for one-click rollback.
A stable URL across deploys and wakes. The app's URL always forwards to its current sandbox — it survives every deploy and every hibernate/wake cycle.
Never-fail wake. If a hibernated app's snapshot can't be restored (e.g. its host was replaced), the next request redeploys it from Git rather than serving an error. The source of truth for an app is the repo, so an app is always reconstructable.
Self-healing. A 30-second health monitor restarts an app whose port stops responding; a crash-looping app is parked in error rather than restarted forever.

Databases

Durable data across hibernate, wake, and host reboot. Data lives on a dedicated volume separate from the ephemeral rootfs. A memory-snapshot failure or a hibernate/wake cycle never touches that volume — your data is safe.
Continuous, automatic backups (on managed deployments). Every WAL segment is shipped to object storage as Postgres fills it, plus a daily base backup — so a database can be rebuilt on another host. See Backups and recovery.
Failover to the latest backup on a multi-node deployment if the host is lost, keeping the same ID and connection URL.
Delete is final and clean. An explicit DELETE destroys the VM, the data volume, and all GCS backup archives (no orphaned data).

In beta, a database's durable volume is host-local — it survives hibernate/wake and host reboot, but a full host replacement relies on the GCS backup (failover, multi-node only). Don't treat a single beta database as the only copy of irreplaceable data; cross-host durability (GCP Persistent Disk + affinity) is on the roadmap.

When to use an ephemeral environment

Ephemeral apps and databases shine when the environment's lifetime is tied to a task rather than to your org:

Use it for	Why it fits
PR previews	One preview app + a throwaway database per pull request. Reviewers get a live URL; everything is torn down on merge.
On-the-go databases for code sandboxes	An agent or a code session needs a real Postgres for one run — create it in seconds, connect over TLS, throw it away. Idle cost is zero.
Demos, evals, and experiments	Stand up an isolated app + DB with real data, share it, and let scale-to-zero handle the idle bill until you delete it.
Per-branch staging	Each feature branch gets its own app + database, isolated from `main` and from other branches.

Reach for an always-on configuration instead when:

The environment is user-facing production that must answer the very first request with no wake latency → set auto_hibernate: false on the app, and keep a connection-pooled (so never-idle) database, or pin it always-on.
You need a database as the single source of truth for irreplaceable production data → wait for cross-host durability (GA), or keep external backups, rather than relying on a single beta instance.

To keep an app always-on, set auto_hibernate: false (or raise idle_timeout_seconds) — see Scale to zero. Databases stay awake as long as a connection (e.g. a pooler) is held open.

Cost model

Ephemeral environments are cheap precisely because of scale-to-zero:

You pay for compute only while running. A hibernated app or database stops metering CPU/RAM — you pay only for the snapshot/volume storage while it sleeps.
Storage is metered separately and counts against your workspace's plan quota (see volumes). A hibernated environment keeps its storage; deleting it frees the storage and purges backups.
This is what makes a per-PR or on-the-go environment economical: it costs compute for the minutes it's actually used, not 24/7.