DoorDash has migrated its engineering agent workloads from developer laptops to the cloud platform Flux. This is significant because such a transition typically reveals real limitations in capacity, access control, and observability.
DoorDash encountered the limits of local execution of agent tasks. When agents run on a developer’s laptop, they are constrained by the CPU and memory of that specific device, depend on its availability, and have overly broad access to resources already open on the machine. For autonomous scenarios, this creates both operational and security risks. At the same time, control becomes more complicated: it becomes harder to understand where exactly the agent is running, which systems it is accessing, and on whose behalf it is acting.
DoorDash’s solution is to move these workloads to Flux, a cloud platform for executing engineering tasks. The architecture is built around four primitives: cloud sandboxes, MCP gateway, reusable playbooks, and invocation surfaces. This is a pragmatic choice because it separates responsibilities: the sandbox is responsible for isolation, the gateway for access to internal systems, the playbook for describing the work and boundaries, and the invocation interfaces for how tasks are initiated by engineers or automation.
Inside Flux, isolation is implemented through Firecracker microVMs. Each environment receives repositories, development tools, secrets, and runtime dependencies needed for a specific task. DoorDash reports that the 95th percentile SLO for full sandbox preparation is less than five seconds, including starting the microVM, cloning repositories, installing build tools, and setting up the coding agent harness. This is an important detail: for a platform of this type, initialization latency directly affects whether the system will be used for background work or will start to interfere with the engineering flow.
Access to internal systems goes through the Agent Gateway, DoorDash’s proprietary MCP gateway. It issues scoped permissions, logs agent actions, and helps enforce policies and audits. Playbooks are described in YAML and capture the task, necessary tools, permissions, checks, and safety boundaries. If necessary, they can combine agent-driven steps with deterministic code. This is a useful compromise: the agent is given the variable part of the work, while predictable checks and critical actions remain within a deterministic framework.
Task execution is also moved to separate surfaces. Agents can start from Slack, GitHub, cron, command line, or conversational interfaces. This model makes Flux not just an execution environment but a layer for managing engineering work. Essentially, DoorDash is trying to eliminate background manual switches without sacrificing control. This is also evident in the company’s change to Slack integration: instead of private channels, it uses public threads so that engineers can see the execution, results, and ways in which other teams delegate work.
According to DoorDash, the platform has already automated 130,000 engineering tasks in one month in 2026. It also supports over 25,000 automated code reviews per week, more than 300 playbooks, and over 10,000 weekly invocations. The original material does not provide detailed comparative metrics before and after, so it is not possible to speak of performance or savings in percentage terms. However, the direction of the effect is clear: Flux has transitioned agent scenarios from a local experiment to a managed platform with isolation, auditing, and scaling in the background.
At the architectural level, this is a typical shift from developer convenience to a controlled platform. Local execution is simpler but does not scale well and is less controlled. The cloud model is more complex to build but is better suited for parallel execution, secure access, and observable automation. This is why such approaches are increasingly being discussed in the industry around coding agents and platform engineering.