What is a persistent sandbox environment? [2026 guide]

A persistent sandbox environment solves a problem that ephemeral execution can't: continuity. Ephemeral sandboxes are the right default for stateless, one-shot workloads. But the moment your agent needs to pick up where it left off, or your pipeline needs to accumulate state across multiple runs, ephemeral execution works against you.

This article covers how persistent sandbox environments work technically, the different persistence models available, the operational and security challenges they introduce, and what to prioritize when choosing a platform.

A persistent sandbox environment is an isolated execution context where state survives between sessions. When the connection closes and reopens, or when your agent makes a new call, the files you wrote, the packages you installed, and the working directory you built up are still there.

The isolation model is the same as any sandbox: code running inside can't affect the host system, access other tenants' data, or reach resources outside its defined scope. What changes is the lifecycle. Instead of being discarded after each run, the environment persists until you explicitly terminate it.

You'll reach for persistent sandbox environments in these situations:

• Multi-step AI agents that clone repos, install dependencies, run tests, and iterate across multiple tool calls
• Long-running data pipelines that process files continuously and accumulate output over time
• Agent-powered development tools where the environment needs to feel like a continuous workspace to the user
• Stateful background workers that maintain process state between invocations

The distinction comes down to what survives when an execution ends.

Well-designed platforms like Northflank let you configure this per workload, with ephemeral and persistent modes running on the same control plane.

Persistence is implemented differently depending on the platform and the workload's requirements. There are three main approaches, each with different tradeoffs.

The most common model. A persistent volume is attached to the sandbox at creation time. The filesystem, including installed packages, written files, and working directories, is backed by that volume and survives when the execution ends. The next session mounts the same volume and picks up exactly where the previous one left off.

This handles the majority of agent use cases. What it doesn't handle is in-memory process state. If your agent had a running server or in-memory cache, that's gone when the session ends. Storage costs also grow continuously without active lifecycle management.

Some platforms capture filesystem state at a point in time and restore from it on the next call. The environment doesn't stay running between sessions; it's recreated from the snapshot each time. This is useful for workloads that need a consistent starting point. The tradeoff is restore latency and the operational overhead of managing which snapshots to keep.

The entire execution environment, including memory, running processes, and filesystem, is checkpointed and resumed from exactly that state. When the session ends, the environment is paused rather than destroyed. This is the closest to how a developer's local machine works and the most resource-intensive model.

Persistent sandboxes introduce challenges that ephemeral environments don't have. Plan for these before you commit to an implementation.

• Storage cost accumulation: Persistent volumes grow over time. Without active cleanup policies, storage costs compound. You need per-sandbox quotas and automated lifecycle rules.
• Stale state and environment drift: Long-lived environments accumulate installed packages and configuration changes that diverge from your base image over time. What works in a fresh environment may behave differently in one that's been running for weeks.
• Security implications of surviving state: Sensitive data written during a session, credentials, intermediate outputs, user data, stays in the volume until you explicitly remove it. This is a compliance and security surface you have to manage deliberately.
• Zombie environments: Persistent sandboxes that are never terminated accumulate silently. Without lifecycle policies enforcing termination, idle environments consume storage and compute indefinitely.
• Stronger isolation requirements: Long-lived environments running untrusted code need stronger isolation than short-lived ones. Container-level isolation is not sufficient for multi-tenant persistent workloads. You need microVM-level isolation: Firecracker, Kata Containers, or gVisor.

Northflank provides secure sandboxes for running untrusted code at scale with microVM and advanced runtime isolation (Kata Containers, Firecracker, gVisor), supporting both ephemeral and persistent environments in managed cloud or your own VPC.

Northflank has been running secure sandboxes in production since 2021 across startups, public companies, and government deployments. If you need GPUs, workers, APIs, or databases running alongside your sandboxes, they run in the same platform.

Here's what Northflank provides out of the box:

Persistent environments are stateful services backed by persistent volumes. Filesystem state survives between executions. Volumes start at 4GB and scale to 64TB with multi-read-write support. You can attach S3-compatible object storage for artifacts and deploy stateful databases, including PostgreSQL, Redis, MySQL, and MongoDB, alongside your sandboxes in the same control plane. There are no forced session time limits.

Northflank supports Firecracker, gVisor, and Kata Containers, applied per workload based on your security requirements. End-to-end sandbox creation runs at 1-2 seconds, covering the full stack.

You get both modes as first-class options. Ephemeral sandboxes for stateless short-lived execution and persistent environments for stateful workloads, configured per workload and managed from the same control plane. You don't need separate vendors as your requirements grow.

Most enterprise teams deploying persistent sandboxed workloads can't accept their code or data leaving their own infrastructure. Northflank supports bring-your-own-cloud deployment inside your own VPC on AWS, GCP, Azure, Oracle Cloud, CoreWeave, Civo, bare-metal, and on-premises, available self-serve.

You can run APIs, background workers, databases, and AI agent infrastructure alongside your sandbox pool on the same platform. GPU workloads are supported with on-demand provisioning and no quota requests.

Sandboxes are accessible via API, CLI, and SSH. CPU at $0.01667/vCPU-hour, memory at $0.00833/GB-hour. Full pricing including GPUs is on the Northflank pricing page.

Work through these questions before committing to a platform:

• What needs to persist? If your agent only needs filesystem state between sessions, volume-backed persistence is sufficient. If you need running processes and in-memory state to survive, you need full pause-resume support.
• How long do environments run? Long-running workloads need platforms without session time limits. Short-session workloads with occasional persistence can tolerate snapshot-based approaches.
• What's your isolation requirement? For multi-tenant persistent environments running untrusted code, microVM-level isolation is a hard requirement. Container-level isolation leaves you exposed as environment lifespan grows.
• Where does the code run? If you have data residency or compliance requirements, BYOC deployment is a hard requirement.
• What does your full stack look like? If your agents need databases, workers, and APIs alongside sandboxes, a platform that handles all of this in one control plane reduces operational overhead significantly.

An ephemeral sandbox is destroyed after each execution with nothing carrying over between runs. A persistent sandbox retains its state, so files, installed packages, and working directories survive when the session ends. Ephemeral sandboxes are simpler operationally; persistent ones are necessary for stateful workloads.

It depends on the platform. Some impose session limits and destroy the environment when reached, requiring you to implement checkpointing to preserve state. Others, like Northflank, impose no forced time limits and let environments run until you explicitly terminate them.

A VM is a general-purpose compute resource. A persistent sandbox is an isolated execution environment with enforced security boundaries, resource limits, and a managed lifecycle specifically designed for running untrusted or AI-generated code safely. The persistence mechanism is similar, but the isolation model and operational constraints are different.

The main risks are state accumulation and environment drift. Sensitive data written to persistent volumes stays there until explicitly removed, and long-lived environments have a larger attack surface than ephemeral ones. Mitigations include microVM-level isolation, storage quotas, automated lifecycle policies, and deliberate cleanup after each session.

Yes, on platforms that support both modes. Northflank supports ephemeral and persistent environments as first-class options configured per workload, both managed from the same control plane.

• What are persistent sandboxes?
• Best persistent sandbox platforms for AI agents
• Ephemeral sandbox environments
• What is a sandbox environment?
• How to sandbox AI agents in 2026: microVMs, gVisor, and isolation strategies
• Best platforms for long-running sandbox environments