Best persistent sandbox platforms for AI agents in 2026

A comparison of the best persistent sandbox platforms for AI agents in 2026, covering how persistence works on each platform, GPU support, bring your own cloud (BYOC), and which use cases each fits.

Persistent sandboxes have moved from a niche requirement to something a lot of production AI agent teams are actively evaluating. The reasons are practical: agents that build up a working environment incrementally, maintain a filesystem between executions, or run long-horizon tasks need somewhere to keep state. Ephemeral-only platforms force you to engineer around that.

The platforms covered here approach persistence differently. Some keep filesystem state via volumes. Some offer full pause/resume including memory. Startup speed, concurrency, and support for custom agent environments also vary. This article covers what each platform actually does so you can evaluate them against your specific requirements.

If you're new to the concept, what are persistent sandboxes covers the fundamentals before you get into platform comparisons.

Not all persistent sandboxes work the same way under the hood, and the differences matter when you're building production agent workflows.

• What actually persists? Some platforms persist only the filesystem. Others persist filesystem and memory including running processes. Others use snapshots to create new environments from a saved state. These are meaningfully different capabilities.
• Is there a session time cap? Some platforms impose a continuous runtime limit before you have to pause. Others impose no fixed session time limit. File retention and uninterrupted process execution are separate considerations.
• What's the isolation model? MicroVM-based isolation (Firecracker, Kata Containers) and user-space kernel sandboxing (gVisor) offer different tradeoffs between security, performance, and compatibility.
• Do you need GPU access? Not all sandbox platforms support GPU workloads. If your agents run inference or training, this narrows the list.
• Can you deploy in your own infrastructure? If your organisation requires execution inside infrastructure it controls, check bring your own cloud (BYOC) support and the provider’s responsibilities.
• How quickly can it run your agent workload at scale? Check sandbox startup time, concurrency limits, and custom environment support for coding agents, APIs, scripts, and GPU tasks.

The platforms below cover the main options for teams evaluating persistent sandbox infrastructure today. Each takes a different approach to persistence, isolation, and deployment.

Northflank provides isolated sandbox environments for AI agents and code execution, with fast startup and support for thousands of concurrent sessions. Run coding agents, scripts, generated APIs, repository builds, and GPU tasks in custom environments, with persistent files for work that continues across sessions.

How persistence works: Attach persistent volumes to retain repositories, generated files, and task artifacts across restarts and pauses. Save files that must survive to the mounted volume: ephemeral files are lost when a sandbox pauses. Pausing stops running processes and terminal sessions; it does not save RAM. Sandboxes have no fixed session time limit.

Key Northflank offerings:

• Environments: Persistent and ephemeral sandboxes, configured per workload.
• Storage: Persistent volumes up to 64 TB, multi-read-write support, and S3-compatible object storage for artifacts and generated files.
• Isolation: Northflank Cloud uses microVMs for CPU sandboxes and gVisor for GPU sandboxes.
• Deployment: Self-serve bring your own cloud (BYOC), where Northflank acts as the control plane to run coding agents and their sandboxes in your virtual private cloud (VPC). Sandbox isolation requires a supported runtime on your infrastructure.
• GPU: On-demand GPU execution for agent tasks that need accelerated compute.
• Access: APIs, SDKs, and CLI tools for creating environments, executing commands, and managing files.
• Compliance: SOC 2 Type II and HIPAA compliant, with Business Associate Agreements (BAAs) supported under Enterprise contracts.
• Startup and concurrency: Sub-second sandbox boot times on Northflank Cloud, with support for thousands of concurrent sessions.
• Custom workloads: Run coding agents, generated APIs, scripts, test suites, and GPU tasks using your own container images.

Pricing: $0.01667/vCPU-hour, $0.00833/GB-hour, with H100 GPU plans at $2.74/hour all-inclusive (CPU and RAM included). The free developer Sandbox tier includes always-on compute with no sleeping, two free services, one database, and two cron jobs for development and testing. Pay-as-you-go offers self-service CPU and GPU workloads, per-second billing, no seat-based fees, and autoscaling. Enterprise plans offer custom pricing, volume discounts, 24/7 support, service-level agreements (SLAs), single sign-on (SSO), and audit logs. See the full pricing details for additional GPU options and compute plans.

Fly.io Sprites are persistent Linux microVMs built by Fly.io that hibernate when idle and wake on demand.

• Filesystem: Persists across hibernation (files, installed packages, git repos, and databases on disk all survive)
• Memory: A warm pause freezes RAM and processes, which resume on a warm wake. A later cold transition discards memory and restarts processes. The platform controls that transition, so memory is not durable across all idle periods.
• Network config: Open ports and URL settings persist across hibernation
• Storage: 100 GB filesystem per Sprite, with a local cache backed by durable object storage
• Wake time: Fly.io describes normal wakes of 100–500 ms and cold starts of 1–2 seconds; requests to a Sprite’s HTTPS URL can wake it automatically
• Checkpoints: Save filesystem state without interrupting the running environment; process memory is not included
• Services: Defined processes that restart after a cold wake, allowing servers to return when the environment resumes
• Isolation: Firecracker microVMs
• GPU: Not supported on Sprites
• Bring your own cloud (BYOC): Not available (runs on Fly.io's managed infrastructure)

E2B provides sandboxed code execution with a pause/resume model that preserves filesystem and memory state.

• Filesystem: Persists on pause/resume
• Memory: Normal pause preserves memory and running processes. Filesystem-only pause saves files but reboots on resume, losing memory state.
• Paused sandbox retention: Kept indefinitely, no automatic deletion
• Continuous runtime cap: 24 hours on Pro and 1 hour on Hobby, with longer Enterprise options
• Snapshots: Available as a separate feature. Saves filesystem and memory state and can be used to create new sandboxes from a saved state.
• Isolation: Firecracker microVMs
• GPU: Not supported in sandboxes
• Bring your own cloud (BYOC): AWS, GCP, and Azure on Enterprise

Modal supports persistent agent environments through filesystem snapshots, directory snapshots, memory snapshots, and mounted volumes.

• Filesystem Snapshots: Save the root filesystem as an image for new sandboxes. Default retention is 30 days; expiry can be changed or disabled.
• Directory Snapshots: Save a selected directory for use in another sandbox. Default retention is 30 days; expiry can be changed or disabled.
• Memory Snapshots: Alpha. Save filesystem and memory state for up to seven days. Snapshotting terminates the sandbox, excludes GPU support, and does not properly restore background processes launched through command execution.
• Volumes: Network filesystems (Modal Volumes) can be mounted into sandboxes for persistent storage
• Isolation: gVisor for standard sandboxes; CPU-only VM Sandboxes are also available in beta
• GPU: Supported across the platform, but not available when memory snapshots are enabled
• Bring your own cloud (BYOC): Not available
• SDK model: Python, JavaScript, and Go clients, with support for custom container images
• Session limit: Up to 24 hours per sandbox; saved files can be used in another sandbox

Pricing checked in September 2026. Hourly equivalents are rounded where needed. Billing models differ across platforms (some bill based on active CPU usage only, others bill for the entire duration the sandbox is running). Verify current rates on each platform's pricing page before making cost decisions.

Modal charges per physical core (two vCPUs).

Fly.io Sprites pricing update: From October 1, 2026, CPU costs $0.03825/CPU-hour and memory costs $0.021875/GB-hour. Storage rates remain unchanged.

The table below shows how each platform handles bring your own cloud (BYOC) deployment, which clouds are supported, and whether it requires a sales process.

Here's a quick reference for matching your use case to the right platform.

Northflank is a strong fit for enterprise teams that need persistent AI agent sandboxes, high concurrency, custom environments, and GPU execution. It is SOC 2 Type II and HIPAA compliant, with Business Associate Agreements (BAAs) supported under Enterprise contracts. With bring your own cloud (BYOC), Northflank acts as the control plane to run coding agents and their sandboxes in your virtual private cloud (VPC).

Northflank supports GPU workloads in both persistent and ephemeral environments. Modal supports GPUs but sandboxes with memory snapshot support enabled cannot run with GPUs. Fly.io Sprites are CPU-only. E2B does not support GPU sandboxes.

Yes. Northflank supports both, configured per workload: attach a volume for files you need to retain, or use an ephemeral sandbox for a disposable task. E2B and Modal also support disposable execution and persistence through their pause or snapshot features.

Northflank has no fixed session time limit, and attached-volume files survive pauses and restarts. Fly.io Sprites retains its filesystem when compute idles; warm pauses preserve memory and processes, but cold transitions discard them. E2B retains paused sandboxes indefinitely, with active session limits depending on the plan. Modal sandboxes run for up to 24 hours; filesystem and directory snapshots default to 30-day retention with configurable expiry, while memory snapshots expire after seven days.

• What are persistent sandboxes?: The foundational explainer on what persistent sandboxes are, how they differ from ephemeral environments, and when you need them.
• Ephemeral sandbox environments: Covers how ephemeral sandboxes work and when they're the right choice over persistent ones.
• E2B vs Modal vs Fly.io Sprites: A deeper comparison of three of the platforms covered in this article, with more detail on isolation models and use case fit.
• E2B vs Sprites dev: A head-to-head comparison of E2B and Fly.io Sprites, covering persistence approach, isolation, and use case differences.
• Self-hosted AI sandboxes: Covers the self-hosted and bring your own cloud (BYOC) route for teams with compliance or data residency requirements.
• Top AI sandbox platforms for code execution: A broader overview of sandbox platforms for code execution beyond the persistence-focused platforms covered here.
• Best code execution sandbox for AI agents: A platform comparison for agent builders evaluating code execution sandbox options.