Ephemeral Infrastructure: The Case for Servers That Don't Exist Until Needed

A traditional server runs for months or years. It accumulates state: log files, temporary data, cached credentials, session artifacts, and the forensic residue of every operation it has ever performed. This accumulated state is a liability. It is discoverable in legal proceedings. It is extractable by attackers. It is a detailed record of everything that happened on that machine — a record that persists long after the operations it describes were meant to be forgotten.

Ephemeral infrastructure inverts this model. Compute exists only for the duration of a task. When the task completes, the execution environment is destroyed — not archived, not suspended, not checkpointed. Destroyed. The memory is zeroed. The container is deleted. The microVM is terminated. The V8 isolate is garbage-collected. What remains is cryptographic nothing.

This is not a theoretical construct. AWS Lambda processes over 10 trillion invocations per year on Firecracker microVMs that boot in 125 milliseconds and are destroyed after execution. Cloudflare Workers handles 57 million requests per second across 310+ cities using V8 isolates that spin up in under 5 milliseconds. The technology for disposable compute at global scale is not emerging — it is mature and operating at extraordinary volume.

The privacy implications are profound. Infrastructure that does not persist cannot be subpoenaed, cannot be forensically analyzed, and cannot leak historical data. Zero-persistence architecture is not an abstraction — it is an engineering specification, and the engineering to achieve it already exists.

The Ephemeral Stack: Three Isolation Models

Ephemeral compute exists at three isolation levels, each with different security properties, performance characteristics, and use cases.

MicroVMs: Firecracker

Firecracker is an open-source Virtual Machine Monitor (VMM) developed by Amazon for AWS Lambda and AWS Fargate. Written in Rust (eliminating memory safety vulnerabilities that plague C-based VMMs), Firecracker creates lightweight virtual machines — microVMs — that provide the hardware-level isolation of traditional VMs with the speed and density of containers.

Architecture. Firecracker runs as a user-space process, using KVM (Kernel-based Virtual Machine) for hardware virtualization. Each microVM has its own Linux kernel, its own memory space, and its own virtualized devices. The Firecracker VMM exposes a minimal virtual device model: a virtio network device, a virtio block device, a serial console, and a minimal keyboard controller. No USB, no GPU passthrough, no PCI devices. This minimal attack surface — approximately 50,000 lines of Rust code — is a deliberate security decision.

Performance. Firecracker boots a microVM in 125 milliseconds on standard hardware. Memory overhead per microVM is approximately 5 MB. A single host can run thousands of concurrent microVMs. These numbers make Firecracker suitable for per-request compute: create a microVM, process one request, destroy the microVM.

Security model. Each microVM is isolated by hardware virtualization (KVM) and by the Firecracker VMM’s minimal device model. A compromised workload inside a microVM cannot escape to the host or to other microVMs without exploiting a vulnerability in the Linux kernel’s KVM implementation — a well-audited, heavily scrutinized code path. Firecracker additionally applies seccomp-BPF filters and cgroups to restrict the VMM process itself, creating defense in depth.

Privacy properties. When a Firecracker microVM is terminated, its memory is reclaimed by the host kernel. Firecracker’s memory model uses demand-paged allocation, and memory is zeroed by the kernel on deallocation (via CONFIG_PAGE_POISONING or init_on_free=1). The guest kernel’s data, the application’s state, and any temporary files exist only for the microVM’s lifetime.

For Stealth Cloud workloads, Firecracker provides the strongest isolation model for ephemeral compute. Each request can run in its own microVM with hardware-level isolation, and the microVM’s complete destruction after execution provides a measurable privacy guarantee: the data existed in RAM for N milliseconds and then ceased to exist.

Container Sandboxes: gVisor

gVisor, developed by Google and used in Google Cloud Run and GKE Sandbox, takes a different approach to ephemeral isolation. Rather than virtualizing hardware, gVisor intercepts system calls from containerized applications and services them in a user-space kernel written in Go.

Architecture. gVisor’s Sentry component implements a substantial portion of the Linux system call interface (approximately 240 of 350+ syscalls). When a container makes a system call, Sentry handles it without passing it to the host kernel. This means that even if the containerized application exploits a Linux kernel vulnerability, the exploit targets gVisor’s Sentry (a Go application with memory safety) rather than the host kernel.

Performance. gVisor’s overhead is higher than Firecracker for system call-intensive workloads. File system operations show 30-100% overhead due to Sentry’s mediation. Network operations show 10-30% overhead. Compute-bound workloads with minimal system call activity show less than 5% overhead. Cold start time is approximately 50-100 milliseconds.

Privacy properties. gVisor provides strong process isolation and system call filtering but shares the host kernel for hardware access. Memory isolation depends on the host kernel’s process isolation rather than hardware virtualization. For ephemeral workloads, gVisor containers are destroyed when the workload completes, with memory reclaimed by the host — but the isolation guarantee is software-based rather than hardware-based.

gVisor is well-suited for ephemeral web services and API handlers where the performance overhead is acceptable and the simpler deployment model (no VM management) is preferred. For workloads requiring the strongest isolation — processing encrypted data from untrusted sources — Firecracker’s hardware-level isolation is preferable.

V8 Isolates: Cloudflare Workers

Cloudflare Workers represents the most radical approach to ephemeral compute: no VMs, no containers, no operating system. Workloads run as JavaScript/WebAssembly functions inside V8 isolates — the same isolation model that Chrome uses to separate browser tabs.

Architecture. A single Cloudflare Workers runtime process hosts thousands of V8 isolates. Each isolate has its own JavaScript heap, its own global scope, and its own execution context. Isolates share the V8 engine and the host process’s memory space, but V8’s isolation guarantees prevent cross-isolate memory access.

Performance. V8 isolates start in under 5 milliseconds — often under 1 millisecond for cached isolates. This cold start time is 25-125x faster than Firecracker microVMs and 10-50x faster than container-based solutions. The per-isolate memory overhead is approximately 1-3 MB, enabling a single host to run tens of thousands of concurrent workloads.

Deployment model. Cloudflare Workers runs on Cloudflare’s network of 310+ Points of Presence across 120+ countries. A Worker deployed globally is available at every PoP within seconds. There is no region selection — the Worker runs wherever the request arrives, providing sub-50ms latency for users worldwide.

Security model. V8 isolate security depends on the V8 engine’s sandboxing — the same sandboxing that protects Chrome users from malicious websites. V8 has been tested by billions of users loading untrusted code daily, making it one of the most audited security boundaries in computing. However, V8 isolation is weaker than hardware virtualization: a V8 exploit (and they do occur — Google’s Project Zero regularly finds them) compromises the entire Workers runtime process.

Privacy properties. Workers isolates are destroyed after execution (or after a configurable idle timeout). The V8 garbage collector reclaims heap memory. No filesystem is available — Workers cannot write to disk. The globalThis scope is fresh per request (in the default configuration). This creates a strong ephemeral model: request data exists only in V8 heap memory for the duration of execution.

For Stealth Cloud architecture, Cloudflare Workers provides the optimal combination of global edge deployment, sub-millisecond cold starts, and zero-disk-access ephemeral execution. The trade-off is weaker isolation compared to microVMs — acceptable for request routing, API handling, and PII stripping, but insufficient for processing highly sensitive data where hardware isolation is required.

Cold Starts: The Performance Tax on Privacy

Ephemeral infrastructure’s primary performance challenge is the cold start: the time to create a new execution environment from nothing. The cold start is the price of ephemerality — a warm environment reuses state, a cold environment starts clean.

The cold start penalty creates an architectural choice: accept the latency of true ephemerality (every request in a new environment) or accept the privacy trade-off of warm environments (reusing state across requests for the same user).

The practical resolution depends on the sensitivity of the workload:

• Maximum privacy: Every request in a new Firecracker microVM. 125ms cold start. Suitable for processing encrypted prompts, handling authentication, or any operation where no request should share state with any other.
• Balanced: V8 isolates with per-request globalThis reset. <5ms cold start. Suitable for API routing, metadata stripping, and edge processing where performance requirements are tight.
• Minimum viable ephemerality: Containers with session-scoped lifecycle. Environment persists for the duration of a user session, then is destroyed. Suitable for stateful operations (multi-turn conversations) where intra-session state reuse is acceptable but inter-session state leakage is not.

Crypto Shredding: Destroying What Cannot Be Deleted

Ephemeral infrastructure’s destruction guarantee depends on the execution environment being truly destroyed. For compute state (CPU registers, V8 heap), this is straightforward — process termination clears these resources. For any data that touches storage — even temporary storage — destruction is more complex.

Crypto shredding is the technique of encrypting all data with a key that is itself ephemeral, and then destroying the key when the data should be destroyed. The encrypted data may persist on storage media, but without the key, it is computationally indistinguishable from random noise.

The implementation for ephemeral infrastructure:

1. At session creation, generate a session encryption key using crypto.subtle.generateKey() (Web Crypto API) or equivalent hardware-backed key generation.
2. All session data — messages, metadata, temporary state — is encrypted with this key before any storage operation.
3. At session end, destroy the key: crypto.subtle.destroyKey() (where supported) or overwrite the key material in memory.
4. Any encrypted session data remaining in storage is now permanently inaccessible.

Crypto shredding is stronger than deletion because it is immune to storage-level data recovery. Deleted data can often be recovered from SSDs (due to wear-leveling), from memory (due to remanence), or from backups. Crypto-shredded data cannot be recovered without the key — and the key no longer exists.

For Stealth Cloud sessions, crypto shredding is the final guarantee: even if infrastructure fails to fully destroy (a container is checkpointed, a memory page is not zeroed, a log file captures a fragment), the encrypted data is useless without the session key that was destroyed when the session ended.

Security Benefits of Ephemerality

Ephemeral infrastructure provides security advantages beyond privacy:

Reduced attack surface persistence. A vulnerability in a long-running server can be exploited repeatedly over months. A vulnerability in an ephemeral microVM can be exploited once — the microVM is destroyed before the attacker can establish persistence, exfiltrate bulk data, or pivot to other systems.

Immutable infrastructure. Ephemeral environments are created from immutable images. There is no configuration drift, no unauthorized modifications, no accumulated patches. Every instance is identical to every other instance of the same image.

Forced rotation. Ephemeral infrastructure forces credential rotation by design. A microVM that exists for 200 milliseconds cannot use long-lived credentials — it must obtain short-lived tokens for each operation. This aligns with zero-trust principles that mandate short-lived, narrowly scoped credentials.

Forensic resistance. For privacy use cases, the inability to forensically analyze destroyed infrastructure is a feature, not a bug. A subpoena for server logs is moot when the servers no longer exist and never wrote logs in the first place.

Blast radius containment. A compromised ephemeral environment can affect only the single request it is processing. There is no lateral movement to other workloads, no access to historical data, and no ability to persist malicious modifications for future requests.

Architectural Patterns for Ephemeral Privacy

Three architectural patterns combine ephemeral infrastructure with privacy requirements:

Pattern 1: Per-Request Isolation

Each incoming request creates a new execution environment, processes the request, and destroys the environment. No state carries between requests. This is the maximum privacy model, suitable for stateless operations.

Implementation: Cloudflare Workers (V8 isolates, <5ms overhead per request) or Firecracker microVMs (125ms overhead, stronger isolation).

Trade-off: No session state. Multi-turn conversations require an external encrypted session store (Cloudflare KV with TTL, client-side encryption).

Pattern 2: Session-Scoped Environments

An execution environment persists for the duration of a user session. Intra-session state (conversation history, context window) is maintained in memory. When the session ends — by user action, timeout, or burn command — the environment is destroyed and crypto-shredded.

Implementation: Cloudflare Durable Objects (WebSocket + in-memory state) or Firecracker microVMs with session affinity.

Trade-off: State exists for session duration (minutes to hours). A compromise during the session exposes session data. Crypto shredding at session end ensures post-session privacy.

Pattern 3: Layered Ephemerality

Different components operate at different ephemeral timescales. The edge layer (V8 isolates) handles request routing and metadata stripping with per-request ephemerality. The processing layer (Firecracker microVMs) handles sensitive computation with per-session ephemerality. The storage layer (encrypted KV with TTL) provides time-limited persistence with crypto shredding at expiration.

Implementation: Cloudflare Workers → Firecracker → Cloudflare KV with TTL + crypto shredding.

Trade-off: Architectural complexity. Multiple isolation boundaries to manage. But the layered model provides the best combination of performance (fast edge layer), security (isolated processing layer), and privacy (time-bounded storage layer).

The Stealth Cloud Perspective

Ephemeral infrastructure is not a deployment optimization. It is a privacy primitive — as fundamental to Stealth Cloud architecture as encryption. A server that exists for 200 milliseconds and leaves no trace is not merely more secure than a persistent server. It is categorically different: it provides a mathematical guarantee (via crypto shredding) and a physical guarantee (via memory destruction) that the data it processed no longer exists anywhere in the infrastructure. Persistent servers can be hardened. Ephemeral servers can be provably empty.