Dora NodaYour designer spots a typo on the pricing page. Instead of filing a ticket, she opens the hosting dashboard, types "fix the typo in the hero subhead," and an agent rewrites the code, opens a pull request, and produces a live preview URL. No clone, no local toolchain, no developer in the loop until review time. That is Netlify's Agent Runners pitch, generally available since October 2025: Claude Code, Codex, and Gemini CLI executing inside Netlify's own infrastructure, with first-party access to your codebase, logs, and deploy pipeline.
There are exactly two shapes for "an AI agent deploys your app." Either the agent runs inside the platform, the way Netlify does it, or the agent runs anywhere and calls into the platform through tools, which is the MCP-server pattern the self-hosted world (Coolify, Dokploy, AppCrane) has converged on. Embedded wins on context depth. MCP wins on agent freedom. And if you operate a self-hosted platform on machines you own, the right sequence is MCP first, embedded runner second — because an embedded runner is just an MCP client that happens to live in your own sandbox.
This post substantiates every clause of that verdict: what Netlify's inside position concretely buys, what it costs, what the MCP alternative looks like in production today, and the one architectural insight that makes the sequencing decision obvious.
What Agent Runners concretely is
Agent Runners launched on October 1, 2025, positioned as the fastest way to put coding agents to work on live applications. The mechanics, per Netlify's docs and launch materials:
- Trigger: open the Netlify dashboard (or CLI), pick an agent — Claude Code, Google Gemini, OpenAI Codex, later joined by OpenCode — describe the task, and choose Run task. Linear issues can launch runs directly, with synced Slack context folded into the prompt.
- Execution: the agent runs in an isolated sandbox with the live project's codebase, production logs, and build configuration mounted in. No local setup for whoever prompted it.
- Output: every run that changes files produces a shareable deploy preview plus a pull request with full diffs. Nothing touches production until a human merges. Each run logs who initiated it, what was prompted, what changed, and who approved it.
- Metering: inference is credit-metered on top of hosting. One user report put a first from-scratch build at 149 credits, visible upfront before the run starts.
- Skills: Netlify's agent skills (from the open
netlify/context-and-toolsrepo) are applied automatically inside Agent Runners — no invocation needed. Thefrontend-designskill, which steers agents away from generic-looking output, is simply on when the agent builds UI. - Models: the AI Gateway lets functions and agents call major LLMs without managing API keys, expanded through 2026 with OpenRouter support and same-day availability of new models like Claude Opus 4.6/4.8 and Gemini 3.8 Flash.
Note the shape of the whole thing: the agent is a tenant of Netlify's infrastructure, and the platform hands it context the way an OS hands a process file descriptors — silently, completely, and without the agent having to ask over a network.
What "inside" concretely buys: five capabilities and their mechanisms
Each row names the capability and the mechanism that makes it possible — or dramatically easier — only from inside.
| Capability | Why it needs the inside position |
|---|---|
| Production context without copy-paste | The sandbox mounts codebase, deploy logs, and build config directly. The failure loop that normally costs a developer twenty minutes of copying error text into a chat window collapses to zero: the agent already sees why the last deploy failed, because it lives where the failure happened. |
| Secrets stay secret | The platform scopes and redacts credentials before the agent ever sees them. An external agent CLI needs your API keys in its own environment to call your deploy API; an embedded runner never holds keys at all — the platform performs privileged actions on its behalf. |
| Preview-per-run safety | Netlify's atomic deploys make every agent output a reviewable URL plus a PR. The human-in-the-loop isn't a policy document, it's the default path: unreviewed agent output physically cannot become production. |
| Full audit trail | Who prompted, what changed, who approved — logged per run by the party that also runs the infrastructure, so the log is hard to tamper with or lose. Compliance teams get provenance without anyone building a second system. |
| Zero-setup teammates | A PM or designer triggers a capable agent from a browser tab. No repo clone, no Node version, no API tokens on a laptop. "Anyone can turn a prompt into a deploy" is only true when prompting requires nothing but access to the dashboard. |
That table is the honest core of Netlify's bet: the scarcest resource in agent-driven development isn't model quality, it's context assembly — getting the codebase, the logs, the config, the credentials, and the review surface into the same room as the agent. Running the agent inside your infrastructure solves context assembly by construction.
What "inside" costs: four bills that arrive later
- Agent choice is the platform's choice. Your team gets the runners Netlify supports. When the next standout coding agent ships, you wait for a platform integration instead of downloading a CLI. For teams standardizing on one lab's models, that lag is a real tax.
- Inference is metered twice. You pay the hosting bill and the credit meter. A backlog-clearing spree — exactly the use case Netlify advertises — burns credits per run, and "prompt into production" starts to feel like a taxi meter next to a flat-rate deploy pipeline.
- Your code executes on vendor infrastructure. The sandbox that makes context assembly free is a computer you don't own. Data-residency reviews, source-code handling policies, and export questions that never arise when agents run on your laptop or your servers now need answers.
- Non-developers deploying widens the review burden. "Anyone can ship" cuts both ways: every prompt-from-a-teammate still needs a qualified reviewer before merge, or the preview-per-run safety net becomes a rubber stamp. The human-in-the-loop scales with reviewer discipline, not with agent speed.
None of these is disqualifying for a hosted SaaS audience. But every one of them flips sign for a team whose starting premise is "we own the machines" — which is where the second shape comes in.
The MCP alternative: what self-hosters actually ship today
The outside-in pattern inverts Netlify's choice: the agent executes wherever the user wants (laptop, CI, another cloud), and the platform exposes its deploy surface as tools over the Model Context Protocol. Three live examples:
- Coolify MCP servers (community projects, ~35–38 tools): manage a self-hosted Coolify instance — apps, databases, services — from any MCP-compatible client like Claude or Cursor. The agent never runs on platform infra; it calls in.
- Dokploy API skills: deploy and manage apps on a self-hosted Dokploy instance (Docker plus Traefik) through tool calls, with docs search baked in so the agent can look up platform behavior itself.
- AppCrane: an explicitly agent-first, self-hosted deploy platform — "vibe-code with Claude Code or Cursor, then have your agent deploy over MCP to a server you own," with per-app Docker isolation, SSO, and per-user audit on the platform side.
What outside-in buys is the mirror image of Netlify's cost list: any agent or CLI works on day one with no platform integration, code and secrets never leave machines you control, and there is no per-run inference markup — you bring whatever model subscription you already have.
What it costs is also the mirror image: context assembly is your problem. Logs, build config, and deploy state must be fetched tool-by-tool across a trust boundary; secrets cross over to wherever the agent process runs; and nobody hands you preview-per-run for free. Your platform has to build the "every agent action yields a reviewable artifact" path itself, or agents will act directly on production with only a prompt standing between intention and incident.
The decision for a platform on owned machines: MCP first, runner second
Here is the sequencing answer, with the reasoning attached. Ship the MCP server first — then, if you want Netlify-style embedded runs, build the runner as a client of that same MCP surface, executing in a sandbox on your own fleet.
Three reasons, in decreasing order of irreversibility:
- The MCP surface is the contract both shapes need. An embedded runner still has to list apps, stream logs, trigger deploys, and gate promotions — the exact verbs an MCP server exposes. Build the tools once and both agent positions (outside laptop agents today, inside sandboxed runners tomorrow) consume them. Build the runner first and you will extract the tool API from it later under pressure, which is how platforms end up with two divergent deploy paths.
- Credential flow favors outside-in on owned hardware. On machines you own, the trust boundary already sits where you want it: the agent brings its own model credentials, the platform enforces its own authz on every tool call, and your source code never has to leave your network to reach an agent. Embedded execution adds sandbox-isolation work (per-run environments, secret scoping, egress policy) that only pays off once outside-in agents are already deploying daily.
- Agent velocity beats platform polish. The coding-agent landscape turns over quarterly — new CLIs, new skills, new harnesses. An MCP server rides all of them for free because it meets agents where they already are. An embedded runner must be re-integrated with each wave, which is sustainable for Netlify's platform team and a treadmill for a smaller one.
The one architectural insight that dissolves the apparent dilemma: both shapes share the same tool surface and differ only in where the agent process runs and which way credentials flow. Inside means the platform holds both the tools and the agent's execution, so context is free and agent choice is gated. Outside means the user holds execution and the platform holds only the tools, so agent choice is free and context assembly is manual. Once you see the two designs as one API with two deployment positions, "MCP first, runner second" stops being a compromise and becomes the only order that doesn't build the same contract twice.
Agents are the new deploy dashboard
Step back and the trend line is unmistakable. Netlify turned its dashboard into an agent runtime. Coolify and Dokploy grew MCP servers from the community up. New platforms like AppCrane lead with "deployable by your agent" as a headline feature rather than an integration. The deploy target that can't be driven by an agent — that has no machine-readable state, no tool-callable verbs, no previewable output — is heading the way of the deploy target with no API: technically usable, practically invisible to how teams actually ship.
The question was never whether agents belong in the deploy pipeline. They are already there, pasting logs into chat windows and waiting for someone to give them keys. The question is whether your platform hands them context deliberately, through a designed surface, or lets them assemble it by accident. Netlify answered with a sandbox. The self-hosted world is answering with a protocol. Build the protocol first — the sandbox can move in later, and it will find the rooms already furnished.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Machine-readable infrastructure state and agent-operable deploys are core to the roadmap, starting with an MCP surface agents can call from anywhere. Star the repo on GitHub or deploy your first app today.
