PATTERN Cited by 1 source

Per-Boot Ephemeral Key

Per-boot ephemeral key is the pattern of generating a unique encryption key inside an ephemeral compute instance on every boot, using it to encrypt all instance-local state (OS scratch, DB caches, temp files, WAL artifacts, swap), and letting it die with the instance. The key is never persisted; terminating the VM cryptographically shreds the local disk and memory.

It is the compute-tier complement to a persistent envelope-encryption hierarchy: storage is protected by KEK/DEKs chained to a CMK; compute is protected by a per-boot key plus VM-lifetime termination.

Shape

1. On boot, the compute node generates a fresh random key in memory (or, in some designs, derives one from the KMS under the CMK — the key point is per-boot uniqueness, not its origin).
2. The key encrypts every write to local disk and every sensitive in-memory structure that touches scratch state — Postgres caches, WAL artifacts, temp files, page cache, query scratch, swap.
3. The key is never written to disk or to a network-reachable store.
4. On instance termination — planned scale-to-zero, CMK revocation, crash, forced-kill — the key dies with memory.
5. Local disk, if the underlying medium outlives the VM (cloud block storage returned to the pool), is cryptographically unrecoverable without the key.

Databricks' Lakebase launch describes this exact shape for Postgres compute VMs: "Every time a Lakebase compute instance starts, it generates a unique ephemeral key," and on CMK revocation "Lakebase Manager terminates the instance, destroying ephemeral in-memory keys and rendering local disk data inaccessible." (Source: sources/2026-04-20-databricks-take-control-customer-managed-keys-for-lakebase-postgres)

Why it exists

A serverless / concepts/stateless-compute tier still has scratch state even if it has no durable state. Postgres compute holds buffer pool, WAL buffers, temp relations, plan caches, pg_stat. These contain user data. An encryption story that only covers the durable store (concepts/envelope-encryption over Pageserver + Safekeeper) leaves this attack surface exposed: a compromised host, a recycled EBS volume, a core-dump could expose plaintext.

Per-boot ephemeral keys close the gap with two properties:

• Bounded lifetime for plaintext. The key exists only while the VM does; a VM that is recycled for scale-to-zero or killed for revocation takes its scratch plaintext with it.
• concepts/cryptographic-shredding reaches compute. Killing the VM is equivalent to destroying a key — local disk becomes unreadable even if the storage medium is not immediately wiped.

Why it fits scale-to-zero

In a concepts/stateless-compute tier that scales to zero, compute instances are already expected to start and stop frequently. Per-boot keys cost nothing extra operationally: the boot path was already generating unique instance identity; adding a key generation is an O(1) operation at startup.

Conversely: a long-lived compute node makes the per-boot-key pattern less useful — one key, protecting years of scratch state, is closer to a persistent-key design. The pattern pairs naturally with short instance lifetimes.

Implementation notes

• Key material must not leave memory. No /tmp/bootkey. No env var. Ideally kernel-protected memory (keyring, mlock, secrets API).
• Pair with VM-lifetime-bound KEK unwrap. The compute VM unwraps storage-tier DEKs using the CMK for the storage it needs access to. The per-boot key is an additional, orthogonal key for the VM's own local state — it does not replace the envelope hierarchy, it supplements it.
• Revocation path must actually kill the VM. The guarantee rests on the management plane's ability to reliably terminate instances on revocation. A VM that survives revocation because the manager couldn't reach it is a leak.
• Disk wipe is a belt-and-braces. Cloud providers typically cryptographically erase returned block storage too. Per-boot keys defend against the window where physical media outlives the VM's API-visible lifetime.
• Attestation. For compliance, some designs also prove (via TPM / Nitro attestation / SGX) that the per-boot key was generated in a trustworthy boot path.

Seen in

• sources/2026-04-20-databricks-take-control-customer-managed-keys-for-lakebase-postgres — Lakebase Postgres compute VMs generate a unique ephemeral key per boot; protects OS / Postgres scratch (performance caches, WAL artifacts, temp files); on CMK revocation Lakebase Manager terminates the instance, destroying the in-memory key and making local disk data inaccessible.

Related

• concepts/envelope-encryption — the complementary persistent-tier story (CMK → KEK → DEK).
• concepts/cmk-customer-managed-keys — the root-of-trust model that triggers compute revocation.
• concepts/cryptographic-shredding — the revocation semantics per-boot keys extend to compute-local data.
• concepts/stateless-compute — the compute model this pattern natural pairs with; scale-to-zero boots are cheap, so per-boot keys are cheap.
• concepts/compute-storage-separation — the architectural split that forces two encryption tiers in the first place.
• concepts/ephemeral-credentials — the broader credential- lifetime family this pattern sits in (server-side compute- identity flavour).
• patterns/sso-with-ephemeral-ssh-keys — client-side sibling: instead of minting a fresh key per VM boot, mint a fresh SSH key per SSO login. Both rely on short-lived keys + easy re-mint to avoid credential accumulation.