AI NewsInfrastructureReported
DoorDash's Flux platform ran 130,000 engineering tasks with agents in a month
DoorDash's Flux platform automated 130,000 engineering tasks in one month, including more than 25,000 automated code reviews a week, using Firecracker microVMs with a 95th percentile sandbox setup under five seconds.

Image: InfoQ
Why it mattersAn agent running on a laptop has whatever access that developer has. Moving it to a sandbox with scoped permissions is the difference between an agent and an audited one.
DoorDash moved its engineering agent workloads off developer laptops onto a platform called Flux. InfoQ's Leela Kumili reported the numbers on 31 August: 130,000 engineering tasks automated in a single month, more than 25,000 automated code reviews a week, more than 300 playbooks and more than 10,000 weekly invocations.
These are DoorDash's own figures, published on its engineering blog. They are the kind of numbers a company reports about itself, so read them as a description of scale rather than an audited result.
Why they moved
The reasons given for abandoning local execution are worth listing, because most teams still run their agents on laptops.
A laptop limits the CPU and memory available. The work depends on the machine staying connected. And an agent running there can use every credential and internal system that developer can already reach.
DoorDash also says local execution makes it harder to see where agents are running, what they access, and on whose behalf. Radoslav Krehlik, a security architect, summarised it as being built after laptop-based agents ran into limits on power, uptime and security.
The four pieces
Cloud sandboxes, on Firecracker micro virtual machines, each provisioned with the repositories, tools, secrets and runtime a task needs. DoorDash reports a 95th percentile objective of under five seconds for end-to-end setup, including starting the microVM, cloning repositories, installing build tools and configuring the agent harness.
An MCP gateway, called Agent Gateway, giving scoped permissions and logging agent activity for audit and policy.
Playbooks, defined in YAML, specifying the task, the tools, the permissions, the validation and the safety boundaries. They can mix agent-driven steps with plain deterministic code where predictable execution matters.
Ways to start a task: Slack, GitHub, cron, the command line, or a conversation.
The main point
Duy Nguyễn, co-founder of TOP GROUP Vietnam, put it well in a comment quoted by InfoQ: once agents handle background work, code review, internal tools and concurrent execution, the hard problem shifts from model choice to control. Identity, permissions, sandboxing, audit logs, quotas, and a real way to stop an agent at once.
That is the whole change in one line. Every debate about which model to use assumes the agent runs somewhere with sensible boundaries, and on a laptop it does not.
What other teams can copy
Under five seconds to a working sandbox is the number that makes the rest possible. If provisioning takes two minutes, nobody uses the sandbox and the agent goes back to the laptop.
The playbook idea is the other part other teams can copy: a YAML file naming the task, the permitted tools and the validation step, with deterministic code where the answer must be predictable. That is a smaller thing to build than a platform, and it is where the safety checks actually are.
The direction is general rather than specific to DoorDash. GitHub supports cloud sandbox environments for Copilot with controls over filesystem, network and system access.
Source
- DoorDash's Flux Runs 130,000 Engineering Tasks Through Cloud-Based Agents, InfoQ, 31 August 2026
This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.
Get AI News in your inbox
New developer tools, model and agent releases, and how teams are actually using them to release software. Short, and only when there is something worth reading.


