Overnight vs. Cloudflare Workers & Sandboxes: Edge Execution vs. a Governed Runtime
Cloudflare runs code closer to your users than almost anyone, and now gives AI agents isolated sandboxes to execute in. Proving to an auditor that AI-built software touched real data safely is a different job. Here is an honest look at where each one fits.
The Overnight vs Cloudflare comparison is easy to frame badly, because the two are competing for different slots. Cloudflare is one of the best places on earth to execute code: a global edge network, V8 isolates that start in milliseconds, and now container-backed Sandboxes purpose-built for running AI- and agent-generated code. Overnight is a governed production runtime, the compliance boundary you put around AI-built software before it runs on regulated data. One is about where code runs and how fast. The other is about who approved it, what it touched, and whether you can prove it. Confusing the two leaves you either paying for governance you don't need or shipping ungoverned software into a SOC 2 scope.
What Cloudflare offers, fairly
Cloudflare's core compute primitive is Workers, which run code inside V8 isolates rather than containers or VMs. An isolate prevents code from accessing memory outside itself, even within the same process, which lets Cloudflare pack thousands of tenants into a single process and switch between them thousands of times a second. As Cloudflare puts it, an isolate takes a few milliseconds to start and uses a few megabytes of memory, and the company markets this as up to 100x faster than spinning up containers. For consumer-scale AI where every end user might have an agent, that density and latency are genuinely hard to beat.
For workloads that need a real operating system, Cloudflare added Sandboxes, which reached general availability in 2026. Each sandbox runs in its own isolated container with a full Linux environment, built on Cloudflare Workers and Containers. The docs name the target use cases directly: AI code execution, untrusted code, data-analysis platforms, and cloud IDEs. Sandboxes give an agent a persistent computer with a shell, a filesystem, and background processes that starts on demand, plus PTY access over WebSocket, code interpreter contexts, preview URLs, and a programmable egress proxy that injects credentials at the network layer so the sandbox never holds live keys. Standard plans support many thousands of concurrent lightweight instances with usage-based, active-CPU pricing. This is a strong, well-designed platform, and nothing below is a teardown of it.
An isolate or a container answers "can this code run without escaping onto the host or a neighbor?" A compliant runtime answers "can this code run on real customer data, and can I hand an auditor a signed record of what it did and who approved it?" Different questions, different architectures.
Where edge execution stops
Start with isolation, because it is the axis where Cloudflare's engineering is genuinely excellent and also where the marketing word "isolated" quietly changes meaning. A V8 isolate is a memory boundary inside a shared process, which is a weaker guarantee than a microVM. Cloudflare is candid about this in its own security model: V8 itself cannot defend against Spectre, so Workers layers on mitigations including restricted timers, no multi-threading, and dynamic rescheduling of suspicious code into separate processes. Sandboxes raise the wall by giving each workload a full container, a stronger boundary than an isolate. Whichever tier you use, the boundary is drawn around the execution. A tenant's compliance obligations have a different shape, and nothing draws a boundary around those for you.
A security or compliance team evaluating AI-generated software on real data needs three things that neither an isolate nor a container was built to hand you:
- A per-tenant compliance boundary, beyond a per-execution one. Container isolation keeps workloads apart at runtime. On its own it stops short of giving you one governed boundary that owns identity, data access, and egress for a tenant across every app they run, which is the unit a security review actually signs off on.
- A per-execution audit trail that stands up as compliance evidence. Logs of container activity are operational telemetry. An auditor wants a durable, attributable record of what ran, what data it touched, under which identity, and who approved it. Assembling that from platform primitives is a project you own.
- Subprocessor responsibility for AI-built software. Cloudflare's own compliance posture is strong. It publishes SOC 2 Type II, ISO 27001, 27018 and 27701 attestations covering its platform. That posture covers Cloudflare's infrastructure, which is a different thing from covering the software a model wrote and you deployed onto it. Cloudflare is your infrastructure provider; it stops short of signing on as the party accountable for how generated code touches your customers' data, and that responsibility stays with you.
The credential-injection egress proxy is a good example of how close the platform gets and where the line still sits. It stops a sandbox from holding raw keys, which is a real security win. "The sandbox never sees the key" is a narrower claim than "every call the app made was mediated against an approved policy and logged as evidence." Mediation, audit, and compliance posture on Cloudflare are yours to assemble. The primitives are excellent, and the governance layer is out of scope.
Overnight vs Cloudflare, side by side
| Dimension | Cloudflare Workers / Sandboxes | Overnight |
|---|---|---|
| Primary job | Edge execution + isolated sandboxes for code | Compliant runtime for AI-built software on real data |
| Isolation model | V8 isolate (shared process) or per-sandbox Linux container | Fully isolated per-tenant compliance boundary |
| Optimized for | Latency, density, global scale | Governed production against sensitive data |
| Per-execution audit trail as evidence | Operational logs; assemble it yourself | Automatic, attributable, signed |
| Runtime-enforced policy | Egress proxy / isolation-level | Deny-by-default, mediated per call |
| Subprocessor of record | No | Yes |
| The controls SOC 2 / HIPAA / GDPR ask about | Build it yourself | Carried by the boundary |
How to choose
Reach for Cloudflare when the problem is execution: you want AI-generated or untrusted code to run fast, close to users, and at scale, with strong container isolation and consolidated billing inside a platform you already use. Workers and Sandboxes are an excellent answer to "where does this code run, cheaply and globally." Reach for a compliant runtime when the problem has moved past execution to "AI-built software is about to run on our regulated data, and security, GRC, and our auditors all have to sign off." These are layers rather than rivals. You can run inside Cloudflare and still need a governed boundary around what touches customer data. The honest wedge has nothing to do with edge performance, where Cloudflare wins outright. It is per-tenant compliance governance, audit-grade evidence, and someone willing to be the subprocessor of record.
Sources
- Cloudflare Workers, Security model (V8 isolates, shared-process isolation, Spectre mitigations) · developers.cloudflare.com/workers/reference/security-model
- Cloudflare Sandbox SDK, Overview docs (per-sandbox isolated Linux container, AI/untrusted-code use cases) · developers.cloudflare.com/sandbox
- "Agents have their own computers with Sandboxes GA," Cloudflare Blog (persistent isolated env, credential-injection egress proxy, scale & active-CPU pricing) · blog.cloudflare.com/sandbox-ga
- "Sandboxing AI agents, 100x faster," Cloudflare Blog (isolate start time / memory, isolate-vs-container tradeoffs) · blog.cloudflare.com/dynamic-workers
- Cloudflare Trust Hub, Certifications and compliance resources (SOC 2 Type II, ISO 27001 / 27018 / 27701) · cloudflare.com/trust-hub/compliance-resources