GitHub Actions went down for three hours in May 2026. Every team that depended on it for continuous deployment watched their release queues pile up, helpless. A month earlier, the Trivy supply chain attack compromised CI/CD runners at scale; 59% of machines hit were pipeline infrastructure, not developer workstations. The centralized deployment server, once a symbol of engineering maturity, has become a single point of failure and a high-value attack target.
Meanwhile, David Heinemeier Hansson has been quietly building the opposite model for a decade. First Capistrano, then Kamal: deployment orchestrated from the developer's machine, containerized for consistency, pushed directly to production over SSH. No intermediate build service. No queued runners. No shared credential store sitting in someone else's cloud. When 37signals completed their full migration to Kamal in early 2025, every application they maintain deploys from a local workstation in under 20 seconds.
The industry dismissed this as a small-team luxury. It's not. It's an architectural decision that's becoming more defensible by the month, especially as AI agents reshape how code gets written and shipped.
The Fragility of Centralized Pipelines
CI/CD pipelines were the right answer to the coordination problem of the 2010s: how do you enforce quality gates when dozens of humans push code to the same repository? You centralize the checks. You make the pipeline the gatekeeper.
But centralization creates brittleness. When GitHub Actions goes down, everyone goes down. When a supply chain attack poisons a shared runner image, every team using that image is compromised simultaneously. The blast radius of a centralized pipeline failure is the entire organization.
Distributed systems theory taught us this decades ago. You don't put all your eggs in one basket; not because each egg is fragile, but because the basket is. A deployment architecture that runs from individual developer environments distributes risk across many independent nodes. One machine having a bad day doesn't ground the fleet.
Agents Deploy From Where They Work
Here's where the AI-accelerated era makes this particularly relevant. Agentic tooling lives on the developer's machine. Claude, Codex, Gemini: they operate in your terminal, edit your files, run your tests locally. DHH described it well in January: agents now control the terminal, run tests to validate their work, and use tools autonomously. They're producing production-grade contributions to real codebases.
If your agent can write the code, run the tests, and verify the build on the local machine, why would you then push to a remote service and wait for a separate system to do the same checks again before deploying? The CI/CD pipeline becomes a redundant serialization point. It adds latency without adding safety, because the safety checks already ran where the work happened.
A deploy script that runs from the development environment is a natural extension of the agentic workflow. The agent writes the code, validates it, and ships it, all within the same context. No handoff. No waiting for a queue. No context switch. The deployment becomes the final step of the development loop, not a separate bureaucratic process managed by different infrastructure.
Containers Solve the Consistency Problem
The historical argument against deploying from developer machines was environmental drift. Your machine has different dependencies, different configurations, different state than the production target. Fair enough in 2012.
Docker eliminated that argument. When you deploy a container, the artifact is immutable. It doesn't matter whether the image was built on a MacBook, a Linux workstation, or a CI runner; the container that reaches production is identical regardless of origin. Kamal understood this from the start: sit on top of basic Docker, harvest the benefits of isolated containers, skip the orchestration complexity.
The consistency guarantee comes from the container, not from the pipeline. Once you internalize that, the pipeline's role in ensuring "it works the same in production" evaporates. The container already guarantees it.
Controlled Release Is Not a Step Backward
There's a philosophical objection here that needs addressing head-on. Continuous deployment — deploy on every merge to main — was supposed to be the apex of engineering maturity. Suggesting we pull back from that feels heretical. But consider what automated CD actually enabled in 2026.
The Trivy compromise worked because pipelines deployed automatically. Poisoned tooling entered CI runners, and because those runners were configured to ship on every green build, the malicious artifacts reached production without a human ever deciding "yes, this version should go live." The Megalodon attack hit 5,500 repositories for the same reason: automated pipelines faithfully deployed whatever passed through them, and the attackers exploited that faithfulness. Automated CD didn't just fail to prevent these attacks. It was the delivery mechanism.
This is the uncomfortable truth: deploy-on-push assumes that your pipeline is trustworthy. When the pipeline itself is compromised, automation becomes the adversary's best friend. Every merge triggers a deployment, and every deployment carries the payload.
Controlled release — a human deciding when to ship — introduces a circuit breaker that automated CD removed. You deploy because you inspected the output and chose to release it, not because a YAML file told the system to ship whatever landed on main. That decision point is a security boundary, not a bottleneck.
The standard counterargument: controlled release is slower, and every unpatched vulnerability sits in production longer while you wait for a human to pull the trigger. Valid concern. But look at what actually happened. The Trivy compromise had a relatively small window of impact — days, not months — yet it propagated through automated pipelines fast enough to hit thousands of organizations before anyone noticed. The Megalodon attack compromised 5,500 repositories in a single coordinated burst. These attacks succeed not because the vulnerability window is large, but because automation eliminates the friction that would otherwise slow propagation.
A human in the loop doesn't need to be slow. A developer deploying from their workstation via Kamal takes 20 seconds. The "delay" isn't the deployment itself; it's the moment of inspection before the deployment. And that moment of inspection is precisely what supply chain attacks are designed to bypass. They rely on automation faithfully executing whatever clears the pipeline. A human glancing at a build output, noticing an unfamiliar dependency resolution, or questioning why a scan produced slightly different output — that's the kind of friction these attacks cannot tolerate.
The vulnerability window argument assumes that the primary risk is known vulnerabilities sitting unpatched. That's a real risk, and for critical security patches you absolutely deploy immediately. But the supply chain risk is the opposite: unknown compromises being shipped because nothing in the automated chain questioned them. Controlled release is the defense against the second category, and 2026 demonstrated that the second category is where the catastrophic damage lives.
This matters doubly in an AI-accelerated environment where code velocity is increasing dramatically. When agents can produce features in minutes instead of days, the rate-limiter shouldn't be a pipeline queue. It should be a human making a judgment call about readiness. That judgment happens at the workstation, not in a YAML file. The combination of high velocity and automated deployment without human checkpoints is precisely the scenario that supply chain attackers are designed to exploit.
The Security Inversion
The security argument used to favor centralized pipelines: control the credentials in one place, audit one system, restrict access at one chokepoint. The logic was sound in a world where the threats came from the edges. But supply chain attacks reversed the threat model. Now the threats come from inside the pipeline itself.
TeamPCP spent March through May 2026 running sustained campaigns against CI/CD infrastructure specifically. They compromised Trivy's official releases so that malicious code ran silently before the legitimate scan, producing normal-looking output while exfiltrating credentials. The Shai-Hulud worm propagated through CI/CD runners because those runners held the credentials to package registries, production environments, and downstream dependencies. The attackers didn't need to compromise individual developers. They compromised the shared infrastructure once and got everything.
Deploying from a developer machine inverts this. Credentials live on individual machines, encrypted at rest, never shared across a networked build service. Compromise one machine and you compromise one deployment path, not the entire organization's. There's no single credential store that unlocks everything. No shared runner image that, once poisoned, infects every team simultaneously.
This isn't a claim that local deployment is inherently more secure. It's a claim that the 2026 threat landscape punishes centralized trust. Distributed credential management reduces blast radius, and blast radius is the security metric that matters most when your adversaries have learned to aim at the center.
The Practical Model
None of this requires exotic tooling. The pattern is straightforward:
- Containerize your application. If you haven't already, this is table stakes regardless of deployment strategy.
- Write a deploy script. Kamal, a shell script wrapping Docker commands over SSH, or any tool that pushes a built image to your target hosts.
- Run your quality gates locally. Linting, tests, security scans. Your machine is powerful enough. DHH's team runs 5,000 test cases on a developer workstation in under three minutes.
- Deploy when ready. Not when the pipeline decides. When you decide.
The agentic workflow integrates naturally: the agent runs the tests, confirms the build, and the deploy command is one more tool invocation in the same session.
The Bridge, Not the Destination
CI/CD pipelines served us well for a decade. They solved real coordination and quality problems. But the assumptions that justified them are eroding: that developer machines couldn't run full test suites, that environmental consistency required a dedicated build server, that centralized control was the only path to security. And the thing we never anticipated — that automated deployment would become the delivery mechanism for supply chain attacks — has made the strongest argument for pulling the deploy trigger back to where a human can see what's in the chamber.
Modern hardware is powerful enough. Containers are consistent enough. The agentic development model benefits from deployment being local and immediate. And controlled release, far from being a regression, may be the most responsible architectural choice available when your pipeline infrastructure is simultaneously a single point of failure, a high-value attack target, and an automated delivery system for whatever an adversary manages to slip into the build.
The centralized pipeline was the right bridge for its era. We're on the other side now.