E2B gives you an isolated Linux VM per sandbox, created from a custom template image, driven by Python and JS SDKs. Sandboxes can be paused at timeout with full state preserved and resumed later, and `setTimeout` can be called repeatedly to extend a live session while a user is interacting. What separates it from Vercel Sandbox or Modal is that the whole infrastructure is Apache-2.0 and E2B publishes Terraform to run it in your own AWS or GCP account, so the hosted API is not a one-way door.
| Isolation model | Firecracker microVM (hardware virtualization) |
|---|
| Cold start | Sub-second (vendor claim; not published as a number) |
|---|
| Max session lifetime | 1h (Hobby) / 24h (Pro), unlimited via pause+resume |
|---|
| Snapshot / fork | Pause/resume with full state; no documented fork |
|---|
| Preview URL | Yes — public host per exposed port |
|---|
Watch out: Free tier caps sessions at 1 hour, and the jump to 24-hour sessions costs $150/month before any usage. Self-hosting is genuinely open but means running Terraform, a Nomad/Consul-style control plane and your own capacity on AWS or GCP — it is not a docker-compose. There is no documented fork/clone primitive, only pause and resume, so fanning one prepared environment out to N parallel agents means N template boots.
Hobby: free, one-time $100 usage credit, 1h max session, 20 concurrent, 10 GiB storage. Pro: $150/mo + usage, 24h sessions, 100 concurrent (expandable to 1,100). Usage: $0.000014/s per vCPU (~$0.050/vCPU-hr) and $0.0000045/GiB/s RAM (~$0.016/GiB-hr).
· open source
Daytona sells sandboxes as "composable computers" — dedicated kernel, filesystem, network stack and allocated vCPU/RAM/disk per sandbox — with SDKs for Python, TypeScript, Ruby, Go and Java. It advertises the fastest published creation figure in the category at under 90ms, plus declarative image builders, stateful snapshots for resuming agent sessions, and automatic preview URLs without manual port config. It also sells GPU sandboxes by the hour, which E2B and Vercel Sandbox do not.
| Isolation model | OCI-based sandbox; vendor claims dedicated kernel and network stack |
|---|
| Cold start | Under 90ms (vendor claim) |
|---|
| Max session lifetime | unknown — configurable auto-stop / auto-archive |
|---|
| Snapshot / fork | Yes — stateful snapshots, declarative images |
|---|
| Preview URL | Yes — automatic, no port config |
|---|
Watch out: The daytonaio/daytona repository — 71k stars and the reason many people trusted it — states it is no longer maintained as of June 2026 because core development moved to a private codebase, so treat "open source" as a historical fact, not an exit strategy. The isolation model is described in marketing terms ("dedicated kernel") rather than a named technology like Firecracker or gVisor, which is thin for a security review. Auto-stop and auto-archive exist but no hard maximum session lifetime is published.
$200 free compute credits, no card. Per-second billing: $0.0504/vCPU-hr, $0.0162/GiB-hr memory, $0.000108/GiB-hr storage after 5 GiB free. Windows adds $0.0858/vCPU-hr. GPUs from $0.57/hr (RTX 4090) to $3.44/hr (MI355X). Enterprise adds SSO, audit logs, BYOC.
Sandboxes are Modal's primitive for running untrusted agent-generated code alongside the rest of your Modal workloads — same images, same volumes, same GPU fleet. Isolation is gVisor (runsc), the same user-space kernel Google runs under Cloud Run, rather than a hardware VM boundary. The pitch versus E2B is consolidation: if your retrieval jobs, fine-tunes and inference already run on Modal, the sandbox is one more object in the same Python SDK with tunnels and volume mounts already wired up.
| Isolation model | gVisor (runsc) user-space kernel |
|---|
| Cold start | unknown — not published for Sandboxes |
|---|
| Max session lifetime | 5 min default, 24h maximum; configurable idle timeout |
|---|
| Snapshot / fork | Filesystem snapshots (recommended to exceed 24h) |
|---|
| Preview URL | Yes — network tunnels to exposed ports |
|---|
Watch out: Sandbox CPU and memory bill at roughly 3x Modal's ordinary function rates ($0.142 vs $0.0131 per core-hour), so a high-volume interpreter workload is meaningfully more expensive here than on E2B or Daytona. gVisor is a user-space kernel, not hardware virtualization — defensible, but a stricter security review may want a microVM. The hard 24-hour lifetime means long-lived agent workspaces must be rebuilt from filesystem snapshots rather than simply left running, and the SDK is Python-centric.
Starter: free with $30/mo credits, 100 containers. Team: $250/mo + compute with $100/mo credits. Sandbox/Notebook rates are higher than standard functions: $0.00003942/core/s CPU (~$0.142/core-hr) and $0.00000667/GiB/s memory (~$0.024/GiB-hr). GPUs from $0.000164/s (T4).
Vercel Sandbox is GA and runs each sandbox in a Firecracker microVM with root access, so system-privileged workloads — Docker-in-sandbox, FUSE mounts, VPN clients — actually work, which most container-based competitors cannot do. Its distinguishing billing choice is Active CPU: time spent blocked on I/O or waiting on a model call is not charged, only provisioned memory is, which suits agents that idle between tool calls. Persistence is the default (sandboxes auto-save on stop and resume), with explicit snapshots, per-agent Linux users for multi-agent isolation, and Drives for shared persistent storage in beta.
| Isolation model | Firecracker microVM with root and system privileges |
|---|
| Cold start | Milliseconds (vendor claim; no published number) |
|---|
| Max session lifetime | 45 min (Hobby) / 24h (Pro, Ent); unbounded via persistent sandboxes |
|---|
| Snapshot / fork | Yes — auto-persist on stop plus explicit snapshots (30-day default retention) |
|---|
| Preview URL | Yes — up to 15 exposed ports |
|---|
Watch out: Only four regions (iad1, sfo1, cle1, cdg1), so latency-sensitive or data-residency-constrained deployments in APAC have no option. Hobby is capped at 45-minute sessions and 10 concurrent sandboxes — real work requires Pro. Five separate meters (Active CPU, provisioned memory, creations, egress, snapshot storage) make cost forecasting harder than a flat per-session price, and egress on exposed ports is billable in both directions. Authentication is built around Vercel OIDC/access tokens, so it is most natural inside the Vercel account model.
Hobby free allotment: 5 Active CPU hours, 420 GB-hours memory, 5,000 creations, 20 GB transfer, 15 GB lifetime snapshot storage, 45-min sessions, 10 concurrent. Pro/Enterprise (iad1): $0.128/Active CPU-hour, $0.0212/GB-hour memory, $0.60 per 1M creations, $0.15/GB egress, $0.08/GB-month snapshots. Pro includes $20/mo credit.
The Sandbox SDK (`@cloudflare/sandbox`) runs a full Linux container on Cloudflare Containers, addressed and kept alive through a Durable Object, so sandbox identity and session state map onto a DO id you already control. It includes a code interpreter for Python and Node with rich outputs (charts, tables, images) and persistent REPL state, plus automatic preview URLs for HTTP services running inside. For durable data it expects you to mount S3-compatible storage (R2, S3, GCS) rather than trusting the container filesystem.
| Isolation model | Linux container on Cloudflare Containers, fronted by a Durable Object |
|---|
| Cold start | unknown — not published |
|---|
| Max session lifetime | unknown — governed by Durable Object / container sleep settings |
|---|
| Snapshot / fork | No — persistence via mounted R2/S3 object storage |
|---|
| Preview URL | Yes — automatic preview URLs for exposed HTTP ports |
|---|
Watch out: It is a container on a shared kernel, not a microVM — a weaker boundary than E2B, Vercel Sandbox or Fly for genuinely hostile code. Sandbox SDK 1.0 is still a preview on the `@next` tag. Instance sizes top out at standard-4 (4 vCPU / 12 GiB), which is small for builds or test suites, and every sandbox costs you a Durable Object instance plus Workers requests on top of container compute. No published maximum sandbox lifetime, and no snapshot/fork primitive — persistence means mounting object storage yourself.
Requires Workers Paid ($5/mo), which includes 25 GiB-hours memory, 375 vCPU-minutes and 200 GB-hours disk per month. Beyond that: $0.000020/vCPU-second (~$0.072/vCPU-hr), $0.0000025/GiB-second memory (~$0.009/GiB-hr), $0.00000007/GB-second disk. Egress $0.025–$0.05/GB by region. Workers requests and the Durable Object bill separately.
· open source · beta
Runloop is built narrowly for software-engineering agents rather than general code execution: devboxes are the environment, blueprints are reusable environment templates you can share across a team, and snapshots let you save, suspend and resume a devbox so an agent can pick up a half-finished repo state. It also ships public SWE benchmark harnesses and custom benchmarks, which is unusual — the product assumes you are evaluating agents, not just running them. Suspended devboxes drop to storage-only billing.
| Isolation model | unknown — "secure sandboxed development environment", technology not published |
|---|
| Cold start | unknown — marketed as "instant-on" |
|---|
| Max session lifetime | unknown — suspend/resume (Pro) instead of a hard cap |
|---|
| Snapshot / fork | Yes — snapshots plus reusable blueprints |
|---|
| Preview URL | unknown — not documented on public pages |
|---|
Watch out: Suspend/resume — arguably the main reason to choose Runloop — is gated behind the $250/month Pro plan, so the free tier does not demonstrate the differentiating feature. Compute is priced above the market ($0.108/CPU-hour versus $0.050 at E2B and Daytona). The docs do not publish an isolation model, cold-start figure, or session lifetime cap, which makes it hard to clear a security review without a vendor call, and it is a smaller company than the platform vendors in this list.
Basic: $0/mo, 100 GB storage, first month free. Pro: $250/mo + usage, 1 TB storage, adds suspend/resume and repo connections. Usage: $0.108/CPU-hr, $0.0252/GB-hr memory, $0.00034236/GB-hr devbox storage, $0.000072/GB-hr snapshot storage, $0.252/hr blueprint builds. Free trial: $50 credits, no card.
CodeSandbox spent years making browser IDE VMs hibernate and wake instantly, and the SDK exposes that machinery directly: checkpoint a running microVM at any point, restore it in under a second, and duplicate a VM or snapshot in under two. That fork primitive is the real differentiator — you can boot one environment with dependencies installed and cheaply branch it per agent attempt, which pause/resume-only competitors cannot do. Sandboxes are created inside your CodeSandbox workspace and billed to it.
| Isolation model | microVM (CodeSandbox VM infrastructure) |
|---|
| Cold start | <1s restore from snapshot; <2s to clone a VM or snapshot |
|---|
| Max session lifetime | unknown — hibernation rather than a documented cap |
|---|
| Snapshot / fork | Yes — checkpoint at any point plus true VM/snapshot cloning |
|---|
| Preview URL | Yes — hosted preview hosts per port |
|---|
Watch out: Pricing is the weak point: there is no publicly fetchable rate card for SDK usage, only "billed to your workspace," which makes cost modelling a sales conversation. Session lifetime limits are not documented either. The product's centre of gravity is still the browser IDE, so the agent-infrastructure surface (egress controls, per-tenant quotas, audit logging) is thinner than at E2B or Vercel, and there is no self-hosting option. Now under Together AI ownership, so roadmap independence is worth asking about.
unknown — sandboxes are billed as workspace VM credits and no SDK-specific rate card is publicly reachable (codesandbox.io pricing pages return 403 to automated fetches)
· open source
Fly Machines are the underlying primitive — a REST API that starts and stops Firecracker microVMs in subsecond time, anywhere in Fly's region footprint, with per-second billing and a stopped-machine price that is just rootfs storage. There is no sandbox abstraction: no code-execution SDK, no interpreter, no session manager. You get a VM API and you build the agent-facing layer, which is the right trade when you need custom networking, unusual regions, or margins that a sandbox vendor's markup would eat.
| Isolation model | Firecracker microVM (hardware virtualization) |
|---|
| Cold start | Subsecond start and stop (vendor claim) |
|---|
| Max session lifetime | No cap — machines run until stopped |
|---|
| Snapshot / fork | Suspend/resume and volume snapshots; no agent-oriented fork API |
|---|
| Preview URL | Yes — via Fly Proxy and app hostname |
|---|
Watch out: This is infrastructure, not a sandbox product — you own session lifecycle, orphaned-machine cleanup, per-tenant quotas, egress firewalling and the code-execution protocol, which is realistically weeks of work plus ongoing operations. There is no snapshot/fork API shaped for agents (suspend/resume exists, cloning a prepared environment does not). Fly's reliability and support history has drawn sustained public criticism, which matters when the VMs are in your request path.
Per-second billing on CPU/RAM presets (Amsterdam example): shared-cpu-1x 256MB $2.02/mo, shared-cpu-4x 1GB $8.08/mo, performance-1x 2GB $32.19/mo, performance-4x 8GB $128.77/mo. Extra RAM ~$5 per GB per 30 days. Stopped machines: $0.15 per GB of rootfs per 30 days. Reserved blocks discount ~40%.
Northflank is a general application platform — services, jobs, databases, CI/CD, GPUs — that also markets a secure runtime for untrusted multi-tenant code, with microVM starts around 200ms and Kata-based isolation. Its differentiator in this category is BYOC: the whole platform can run inside your own cloud account or on-prem, so agent-generated code executes where your data residency rules already apply. Compute is the cheapest listed here at $0.01667/vCPU-hour.
| Isolation model | Kata-based microVM secure runtime on Kubernetes |
|---|
| Cold start | ~200ms microVM start (vendor claim) |
|---|
| Max session lifetime | No cap — long-running services and jobs |
|---|
| Snapshot / fork | No agent-oriented snapshot/fork primitive |
|---|
| Preview URL | Yes — service URLs and PR preview environments |
|---|
Watch out: There is no agent-shaped sandbox SDK: no `createSandbox()`, no interpreter, no snapshot/fork primitive, no per-session API — you deploy services and jobs and build the sandbox semantics yourself. The confusingly named free "Sandbox" tier is a hobby plan, not the secure-runtime product. The secure multi-tenancy story is sales-led rather than self-serve, and the isolation details (Kata) surface in case studies rather than a clear public spec page.
$0.01667/vCPU/hour and $0.00833/GB/hour, scaling 0.1–32 vCPU and 256 MB–256 GB. Named plans from $2.70/mo (nf-compute-10). Free "Sandbox" tier: 2 services, 1 database, 2 cron jobs, always-on compute. BYOC and enterprise pricing on request.
OpenAI's built-in `code_interpreter` tool (the model calls it the python tool) runs Python in a managed container attached to a Responses or Assistants request, with automatic upload of user files and container-file citations for anything the model produces. It handles a wide input format range — PDF, DOCX, PPTX, CSV, JSON, ZIP, images, source files — which makes it the path of least resistance for document-analysis features. Memory is configurable from 1 GB up to 64 GB, with price scaling accordingly.
| Isolation model | Managed container (isolation technology not published) |
|---|
| Cold start | unknown — not published |
|---|
| Max session lifetime | Container expires after 20 minutes of inactivity |
|---|
| Snapshot / fork | No |
|---|
| Preview URL | No |
|---|
Watch out: Python only, with no shell and no root, so it cannot stand in for a coding agent's environment. Containers expire after 20 minutes of inactivity and the data is then unrecoverable, so you must persist anything you care about yourself. It is only reachable from inside an OpenAI model call — you cannot use it as general execution infrastructure — and there are no preview URLs, snapshots or forks. Larger memory tiers get expensive fast at $1.92 per 64 GB session.
$0.03 per container session at the default 1 GB, scaling to $1.92 per session at 64 GB. Rate limit 100 requests/minute per organization across Responses, Chat Completions and Assistants. Token costs billed separately.
AgentCore's Code Interpreter is a managed sandbox that runs Python, JavaScript and TypeScript with configurable network modes — fully sandboxed, public internet, or attached to your VPC — which is the feature that lets an agent query an internal database without the code leaving your network perimeter. It handles large data by referencing S3 rather than passing bytes through the API (100 MB inline, up to 5 GB via S3 through terminal commands), and every session is CloudTrail-logged. Billing charges only genuine CPU consumption, so I/O wait and idle time while the model thinks are free.
| Isolation model | Containerized sandbox within Bedrock AgentCore; sandbox/public/VPC network modes |
|---|
| Cold start | unknown — not published |
|---|
| Max session lifetime | 15 min default execution, extendable up to 8 hours |
|---|
| Snapshot / fork | No — persist to S3 instead |
|---|
| Preview URL | No |
|---|
Watch out: AWS-only and IAM-heavy — execution roles, S3 policies and session management are real setup cost compared to a two-line E2B call. Language support is fixed to the pre-built Python/JS/TS runtimes, there is no snapshot or fork primitive, and no preview URL for a running server. Default execution is 15 minutes and extending to 8 hours is a configuration exercise. Charges stack on top of the rest of AgentCore, so the true unit cost of an agent turn is not visible from this one rate card.
$0.0895 per vCPU-hour and $0.00945 per GB-hour, billed on active consumption with a 1-second minimum and a 128 MB memory floor. I/O wait and idle time are not charged for CPU. New AWS customers get up to $200 in Free Tier credits. EC2 data transfer and CloudWatch billed separately.
Dynamic sessions give you a session pool resource with each session isolated by a Hyper-V boundary — the strongest documented isolation claim in this list — allocated from a pre-warmed pool and addressed by a session identifier you choose (a user id or conversation id). Built-in Python, Node and shell interpreters cover the common case; custom container sessions handle everything else. LangChain, LlamaIndex and Semantic Kernel all ship first-party integrations, and auth is Microsoft Entra tokens with role assignments on the pool.
| Isolation model | Hyper-V boundary per session |
|---|
| Cold start | Fast allocation from a pre-warmed pool; no published millisecond figure |
|---|
| Max session lifetime | Configurable idle timeout per pool; 220s maximum per execution call |
|---|
| Snapshot / fork | No — session reuse by identifier instead |
|---|
| Preview URL | No for built-in interpreter; custom container sessions expose HTTP |
|---|
Watch out: Each execution call is capped at 220 seconds, which rules out builds, test suites and long agent tasks in the built-in interpreter. The published pricing page shows placeholder rates rather than numbers, so you cannot model cost without the calculator or a sales conversation. Session pools are per-region resources you must provision and size in advance, Entra token plumbing adds friction versus an API key, and code interpreter sessions do not emit logs to Log Analytics — observability is limited to response headers you capture yourself. The docs also warn that session identifiers are sensitive: leak one and another tenant reaches that session.
unknown — billed per session-hour with pay-as-you-go plus 1-year and 3-year savings plans, but the Azure Container Apps pricing page currently renders the dynamic sessions rates as placeholders rather than figures
TCI executes Python in a sandboxed session that lives 60 minutes and can be called repeatedly, with variables, installed packages and memory persisting across executions against the same session id. Its target workload is unusual and explicit: reinforcement-learning training runs and agentic eval loops where you need to execute millions of code samples cheaply, which is why it is priced per session rather than per CPU-second. It is available as a plain API and as an MCD/MCP server, with 30+ scientific libraries preinstalled and pip available.
| Isolation model | unknown — described only as a sandboxed environment |
|---|
| Cold start | unknown — not published |
|---|
| Max session lifetime | 60 minutes per session, reusable within that window |
|---|
| Snapshot / fork | No |
|---|
| Preview URL | No |
|---|
Watch out: Python only, with no other language support shipped yet. The session model is the whole product: 60 minutes then gone, no snapshots, no fork, no preview URL, no persistent filesystem across sessions, and a much thinner lifecycle API than E2B or Daytona. There is no published isolation model, which is a gap for a security review, and no free tier documented — if you want an agent that keeps a workspace between conversations, this is the wrong tool.
$0.03 per session; each session lives 60 minutes and can be reused across many executions
Riza takes the opposite bet from every microVM vendor here: instead of booting a Linux machine, it executes code in a WebAssembly context with no filesystem, HTTP-only network and a 128 MB memory ceiling per invocation. The result is the tightest blast radius in the category and pricing by request rather than by second — 100,000 requests a month free. It supports custom runtimes with your own dependencies baked in, holds SOC 2 Type 1, and offers self-hosting on the enterprise tier.
| Isolation model | WebAssembly isolate (no host filesystem, HTTP-only network) |
|---|
| Cold start | unknown — no VM boot; per-request invocation model |
|---|
| Max session lifetime | Per-request: 30s (Hobby) / 15 min (Pro); no persistent sessions |
|---|
| Snapshot / fork | No — stateless invocations, state via custom runtimes |
|---|
| Preview URL | No |
|---|
Watch out: It is a WASM isolate, not a computer — no real filesystem, no subprocesses or shell, no runtime pip/npm installs, HTTP-only networking and 128 MB of memory per invocation. That makes it the wrong choice for any coding agent that needs to clone a repo, run a build, or start a dev server, which is most of them. Dependencies must be pre-baked into custom runtimes, capped at 3 on the free tier, and SOC 2 Type 1 (not Type 2) dated December 2024 is worth re-checking before a compliance review.
Hobby: free, up to 100,000 requests/month, 30-second execution limit, 3 custom runtimes. Pro: $250/month for 1,000,000 requests, 15-minute execution limit, 50 custom runtimes. Enterprise: custom quotas plus self-hosting.
microsandbox is the self-hosted answer to E2B: a microVM runtime you embed directly in your application to spawn hardware-isolated VMs, with no separate server or long-running daemon to operate. It ships official SDKs for TypeScript/Node, Python, Rust, Go and Ruby, and claims average boot times under 100ms on Apple Silicon, which makes local development against real microVMs practical rather than theoretical. Apache-2.0 with roughly 8k GitHub stars and active development.
| Isolation model | microVM, hardware-level isolation, embeddable with no daemon |
|---|
| Cold start | Under 100ms average boot (project claim, Apple Silicon) |
|---|
| Max session lifetime | No cap — you control the lifecycle |
|---|
| Snapshot / fork | unknown — not documented as a first-class primitive |
|---|
| Preview URL | No — you own networking and ingress |
|---|
Watch out: The project states plainly that it is beta software with breaking changes, missing features and rough edges — that is a hard sell for a security boundary in production. You own the host, the kernel, the patching, the capacity planning and the multi-tenant quota logic, and there is no managed control plane, billing, audit logging or SLA. Maintainer bandwidth is small relative to a funded vendor, so a critical isolation bug is your problem to fix on your timeline.
Free — Apache-2.0 software; your only cost is the hosts you run it on
· open source · beta
Firecracker is the VMM underneath AWS Lambda and most of the microVM sandbox vendors in this list, including E2B, Vercel Sandbox and Fly. It deliberately omits devices and guest-facing functionality to shrink both memory footprint and attack surface, and adds thread-specific seccomp filters plus a jailer process for production deployment. The public claims are precise: boot under 125ms, under 5 MiB overhead per microVM, and up to 150 microVMs created per second per host, backing 15 trillion+ monthly Lambda invocations.
| Isolation model | KVM-based microVM (hardware virtualization) with seccomp jailer |
|---|
| Cold start | <125ms boot; up to 150 microVMs/second/host |
|---|
| Max session lifetime | No cap — you control the lifecycle |
|---|
| Snapshot / fork | Yes — snapshot/restore is a core feature you drive yourself |
|---|
| Preview URL | No — you build networking and ingress |
|---|
Watch out: It is a virtual machine monitor, not a product: no API for your agent, no scheduler, no image build pipeline, no networking, no session or quota management, no observability — every one of those is yours to write, and that is what the sandbox vendors are actually selling. It requires Linux with KVM on x86_64 or ARM64, so no macOS hosts, and most clouds do not expose nested virtualization, meaning you likely need bare metal. Device hotplugging is still developer preview. Budget months, not weeks, before this is production-grade multi-tenant.
Free — Apache-2.0 software; you pay only for the bare-metal or nested-virtualization-capable hosts you run it on
· open source
gVisor sits between containers and a hardware VM: the Sentry process implements a Linux-like interface in user space and intercepts application syscalls, so the guest never talks to the host kernel directly, without paying for virtualized hardware. It ships runsc, an OCI-compatible runtime that drops into Docker and Kubernetes, and is what powers Google Cloud Run and Modal's Sandboxes. Because it keeps a process-like resource model, it has no large fixed per-sandbox overhead — the trade is paid per syscall instead.
| Isolation model | User-space application kernel (Sentry) intercepting syscalls; OCI runtime runsc |
|---|
| Cold start | Container-speed; no VM boot and no large fixed overhead |
|---|
| Max session lifetime | No cap — you control the lifecycle |
|---|
| Snapshot / fork | Checkpoint/restore exists but is not an agent-shaped fork API |
|---|
| Preview URL | No — you build networking and ingress |
|---|
Watch out: Syscall-heavy and I/O-heavy workloads — exactly what a coding agent doing package installs and builds looks like — run measurably slower than native containers, and gVisor's own docs acknowledge higher per-syscall overhead and reduced application compatibility. Its Linux syscall coverage is incomplete, so some binaries and language runtimes simply fail. It is a software boundary rather than a hardware one, which some security reviews will reject outright, and like Firecracker it is a runtime, not a platform: orchestration, session management and egress control are still yours to build.
Free — Apache-2.0 software; you pay only for the hosts you run it on
· open source