Managed vs Self-Hosted Code Sandboxes: Build vs Buy

Q: Should I buy a managed code sandbox or self-host my own?

For most teams, buy first. Running untrusted, AI-generated code safely requires hardware-grade isolation, autoscaling a warm pool, lifecycle management, egress control, and per-execution metering — all of which a managed platform (AWS Lambda microVMs, E2B, Modal, Daytona) operates behind an API, getting you a secure, scaling sandbox in days rather than a quarter of engineering. You should self-host only when a specific, named constraint forces it: a data-residency or air-gap requirement that the vendor's regions cannot satisfy, a sustained high volume where the per-execution premium clearly exceeds running your own infrastructure plus the engineers to operate it, or a need for a custom kernel, GPU, or runtime no vendor offers. The common failure mode is self-hosting "for control" with no such constraint, which lands you maintaining a Firecracker fleet and a kernel-CVE response rota you never needed. Wrap whichever you choose behind your own thin interface so the decision is reversible, and revisit it as volume and compliance needs evolve rather than treating it as a one-time bet.

Q: What do you actually give up by buying a managed sandbox?

You give up some control and accept a per-execution premium, in exchange for not operating the hard parts. Concretely, you are limited to the vendor's regions (which matters for data residency), to the kernel, runtimes, and hardware options they expose (which limits custom GPU or specialised runtime needs), and to their network and egress primitives. You also take on vendor-dependency risk and a cost that, at very high sustained volume, can exceed self-hosting. What you do not give up is your own security responsibilities: the vendor owns the isolation boundary, but egress policy for your workload, scoping of credentials your agent uses, and auditing what your agent actually does remain yours. The managed premium is excellent value at low and bursty volume because you pay nothing for the warm pool, autoscaling, patching, and ops you would otherwise staff, but you should model it per million executions as you grow so you can see the point — if it ever arrives — where the premium plus lock-in outweigh the engineering you would spend to self-host.

Q: When does self-hosting a sandbox actually make sense?

Self-hosting makes sense for exactly three reasons, and "we want control" is not one of them. First, compliance: if regulation requires data to stay within a jurisdiction the vendor does not serve, inside your own VPC, or fully air-gapped — common under EU GDPR and DORA, Singapore MAS, UAE rules, and defence or healthcare mandates — then self-hosting (or a vendor bring-your-own-cloud tier) is a requirement, not a preference. Second, cost at sustained scale: when volume is both high and steady, the per-execution managed premium can exceed the fixed infrastructure plus the salaried engineers needed to run your own fleet — but you must model total cost of ownership honestly, including kernel-CVE response, autoscaling, and snapshot storage, not just the raw compute. Third, customisation: when you need a custom kernel, specific GPU access, or runtimes the vendor does not offer. Absent one of these, buying is faster, safer, and usually cheaper once you price in the engineering. If you do self-host, use proven microVM technology (Firecracker, gVisor, or Kata) rather than rolling your own isolation, and keep the same security invariants the managed platform would have enforced.

Q: How should I compare the cost of managed vs self-hosted sandboxes?

Compare total cost of ownership per million executions, not the headline compute price. A managed sandbox charges a per-execution or per-second-of-runtime premium, but that price bundles the warm pool, autoscaling, kernel patching, lifecycle, and the engineers who would otherwise run all of it — so at low, bursty, or growing volume it is usually the cheaper option once you account for the staff you avoid hiring. Self-hosting trades that premium for fixed infrastructure cost plus real engineering: building and operating the broker, warm pool, egress proxy, snapshot store, and autoscaler, and running a continuous kernel-CVE response process. Self-hosting only wins when volume is high and steady enough that the per-execution premium clearly exceeds infrastructure plus those salaried people. The mistake teams make is costing self-host as "just EC2", ignoring the multi-quarter build and the permanent operations tail; when you include those, the break-even volume is far higher than intuition suggests, which is why buying is the right default until you have both the scale and the data to prove self-hosting is cheaper.

Q: Why is data residency often the deciding factor?

Because residency is a hard constraint that overrides cost and convenience: if a regulation says certain data must remain in a specific jurisdiction, inside your own environment, or fully air-gapped, then no amount of managed-platform convenience helps if the vendor cannot run in that boundary. Code sandboxes are especially exposed here because the agent's code often processes the very data under regulation, and the sandbox's memory and any snapshots hold that data in full. Under EU GDPR and DORA, Singapore MAS guidance, UAE rules, and defence or healthcare mandates, this can mean data may not leave the region or the customer's own cloud at all. When that applies, your options narrow to self-hosting the sandbox in the compliant environment or using a managed vendor's bring-your-own-cloud or in-region tier if one exists that satisfies the auditor. This is why residency is usually the first question in the decision flow: it can force self-hosting regardless of how favourable the managed cost and speed would otherwise be, and it connects the sandbox choice directly to your broader data-residency and sovereignty architecture.

Q: Does buying a managed sandbox remove my security responsibilities?

No. A managed sandbox removes the burden of building and operating the isolation boundary — the vendor runs the microVM, patches the kernel, and enforces the hardware-level separation — but a meaningful share of security remains yours. You still own the egress policy for your workload (what hosts the sandboxed code may reach), the scoping of any credentials your agent uses (the sandbox should hold no ambient long-lived secrets; you broker short-lived, narrowly-scoped tokens), and the auditing of what your agent actually does inside the sandbox. You also remain responsible for verifying the vendor's security posture through their attestations and for designing the surrounding controls — human gates on irreversible actions, budgets, and monitoring. The right mental model is that buying outsources the isolation primitive, not the security architecture: you build your egress, identity, audit, and governance on top of the managed sandbox exactly as you would on a self-hosted one, and you evidence them for your own compliance. Teams that assume "managed means secure" ship agents with open egress or baked-in credentials and learn the hard way that the vendor only owned one layer.

Q: What are the main anti-patterns in choosing how to host a sandbox?

The recurring mistakes split across both choices. On the self-host side: building a Firecracker fleet "for control" with no named constraint, which saddles you with a kernel-CVE rota you did not need; costing self-host as "just EC2" while ignoring the engineers, autoscaling, snapshot storage, and patch response; self-hosting prematurely before you have product-market fit or the volume to justify it; and rolling your own isolation from scratch instead of using proven microVM technology. On the buy side: adopting a managed vendor without first checking that its regions satisfy your data-residency rule, only to hit a compliance blocker after integration; and assuming managed removes your security duties when egress, credential scoping, and audit remain yours. Cutting across both: building deeply against one vendor's proprietary API with no abstraction, creating lock-in with no exit plan. The unifying remedy is to abstract the sandbox behind your own interface early, default to buying until a named constraint forces self-hosting, and treat the hosting decision as reversible and revisited at scale rather than a permanent commitment made on preference.

Q: What is a sensible maturity path for sandbox hosting?

Stage 0 is running agent code in-process or in a plain container, which is not a real sandbox and is a security incident waiting to happen. Stage 1 is adopting a managed microVM sandbox — AWS Lambda microVMs, E2B, Modal, or Daytona — behind your own thin abstraction, which gives you secure code execution in days while the vendor owns isolation, autoscaling, and lifecycle. Stage 2 layers your own egress policy, credential scoping, and audit on top of the managed sandbox, and begins modelling cost per million executions as volume grows so you can see where the economics lead. Stage 3 arrives only if a named constraint appears — residency, air-gap, cost-at-scale, or a custom kernel or GPU — at which point you stand up self-hosted Firecracker, gVisor, or Kata behind the same abstraction so the switch does not ripple through your application. Stage 4 treats the sandbox tier as a clean internal interface with managed and/or self-hosted backends chosen per workload and region, full audit and compliance evidence, and cost continuously modelled, so build-vs-buy becomes a per-workload decision rather than a one-time bet. Most teams err by self-hosting too early or under-securing a managed sandbox; the ones who ship safely abstract the sandbox early and let the constraint, not the preference, drive the decision.