The deploy gap

Kapten · Whitepaper WP-01 · 13 October 2026

1. The new bottleneck

For most of the history of software, writing the code was the expensive part. A feature took days. A rewrite took a quarter. Everything around the code (the servers, the pipeline, the database backups) was proportionally cheap, because it moved at the same pace as the thing it was supporting.

That proportion has changed. A single developer with a capable coding agent can produce a working application in an afternoon: a web frontend, an API, a background worker, a database schema and a test suite. The application runs. It answers requests on localhost:3000. It might even be good.

And then it stops. Not because the code is wrong, but because the next step is a different kind of work. The question changes from does it work? to where does it run, who can reach it, what happens when it crashes at two in the morning, and who pays for it? Those questions do not have answers in the repository, and the agent that wrote the repository usually cannot answer them either, because it has no access to anything outside it.

We call the distance between those two states the deploy gap. It is not new. What is new is how wide it has become relative to everything else. When writing the application took three months, spending two weeks on deployment was a rounding error. When writing it takes an afternoon, two weeks of infrastructure work is the entire project.

What the gap looks like from the inside

The symptoms are familiar to anyone who has built something with an agent recently:

• A repository full of working code and no clear way to run it anywhere but the laptop that produced it.
• A docker-compose.yml that was perfect for development and is now being asked to be production.
• An .env file with real credentials in it, and a vague intention to “move those somewhere safe later”.
• A database that has never been backed up because it has never been anywhere that could lose it.
• A free tier on a hosting platform that is about to stop being free, or about to stop being enough.

None of these is a bug. Each is a decision that has not been made yet, because nothing so far has forced it.

2. What production adds

It is worth being precise about what changes between localhost and production, because “deployment” is usually spoken of as one step when it is really eight distinct concerns. Each of them is invisible on a laptop, and each of them eventually becomes the reason something breaks.

Build reproducibility

On a laptop, the application runs with whatever is installed: a particular Node version, a system library, a globally installed CLI. Production needs the same application built the same way every time, from the source alone. In practice that means a container image per service, built from a pinned base, with nothing smuggled in from the machine that happened to build it.

Configuration and secrets

Locally, configuration lives in one file and secrets live next to it. Production needs configuration per environment, secrets that are never committed, never baked into an image and never printed in a log, and a way to rotate them without redeploying everything by hand.

Data durability

A local database is disposable. A production database is the one thing that cannot be recreated from the repository. It needs backups, a tested restore, a migration process that does not lock the table your users are writing to, and a decision about where it physically lives.

Network exposure

On a laptop, everything can reach everything. In production, almost nothing should. The public endpoint needs TLS and a domain; the database should not be reachable from the internet; internal services should talk only to the services that need them.

Health

A process that is running is not the same as a process that is working. Production needs health checks that reflect whether a service can actually do its job, so that the platform can stop sending it traffic, restart it, or refuse to roll it out in the first place.

Rollback

On a laptop, a bad change is fixed by editing the file. In production, a bad change is serving errors to people while you edit the file. A rollback needs to be a single, fast, boring step, ideally one that re-points traffic to an image that already exists rather than rebuilding an old commit and hoping.

Cost

Localhost is free. Production has a bill, and the bill grows in ways that are hard to see from the code: idle environments, oversized instances, storage nobody remembers creating, traffic between zones. Someone needs to know what the application costs and to notice when that changes.

Ownership

Finally, production needs a person. Someone who is allowed to approve a release, who is told when something breaks, and who decides what happens to the data. On a laptop, that is obviously you. In production it should still be obvious, and it often is not.

What localhost hides

None of this is exotic. Every one of these concerns has a well-understood answer. The difficulty is that there are eight of them, they interact, and each one is easy to get almost right.

3. Why the usual answers fall short

There are two standard ways to cross the gap today, and both work. They simply ask for a trade-off that fits some teams well and others badly.

The platform-as-a-service answer

A traditional PaaS hides the eight concerns behind a single command. You push code; it builds, runs, gets a domain and a certificate. For a first deployment this is genuinely excellent, and for many applications it is all they will ever need.

The trade-off arrives later, and usually all at once:

• The infrastructure is theirs, not yours. Your data lives in their account, in their chosen regions. When a customer or a regulator asks where it is, the answer is a vendor’s page rather than your own architecture.
• The bill is a markup on someone else’s cloud. Your existing credits, commitments and discounts with a cloud provider do not apply. As usage grows, the gap between what you pay and what the underlying resources cost grows with it.
• The abstraction has edges. A worker that needs a specific instance type, a private connection to a customer’s network, a database extension the platform does not support: each of these is a reason to leave, and leaving means rebuilding everything the platform was doing for you.

The PaaS answer does not close the deploy gap so much as postpone it. That is often the right call. It is worth knowing that it is the call being made.

The do-it-yourself answer

The other route is to build the platform yourself: infrastructure-as-code for the cloud account, a Kubernetes cluster or a set of managed services, a CI pipeline, a secrets manager, monitoring, alerting, backups. Everything lives in your account, on your bill, under your control.

This is the right destination for many teams. The trouble is the journey:

• It is a second project. The time spent writing Terraform modules and pipeline configuration is time not spent on the product. For a small team, that can be most of the time.
• It is specialist work. Getting the eight concerns right requires judgement that comes from operating systems in production. That is what an SRE or platform engineer is for, and most early teams do not have one.
• It keeps costing. Infrastructure that you build, you also maintain: version upgrades, certificate renewals, security patches, the slow drift between what the code says and what is actually running.

And here is the irony of the moment: a coding agent can write the Terraform. It can write the pipeline, the Dockerfile and the Kubernetes manifests. What it cannot do, sitting in a repository with no access to anything else, is know whether any of it is correct for your account, apply it safely, watch what happens, and roll it back when it goes wrong. It produces infrastructure code with no one to operate it.

4. A different shape: operations from the agent you build with

If the bottleneck is no longer writing code but operating it, then the natural place to close the gap is the same place the code came from. The developer is already working with an agent. The agent already understands the application, because it helped write it. What it lacks is a safe, structured connection to the environment the application will run in.

That connection is what the Model Context Protocol (MCP) provides. MCP is an open protocol that lets an assistant call tools exposed by a server, with typed inputs and outputs. A Kapten MCP server gives a compatible client (Claude Code, Claude Desktop, Cursor, VS Code and others) a vocabulary for production: list the environments, describe the topology, plan a release, estimate a cost, tail the logs of a service, roll it back.

With that connection in place, the conversation that wrote the application can continue past localhost:

“Deploy this to production on our AWS account in eu-west-3. Postgres for the data, the worker on its own service, the API behind our domain.”

What happens next matters more than the request itself.

Not one agent: a crew

A single general-purpose agent asked to “deploy this” will try to do everything at once, and will be as confident about the IAM policy as about the CSS. Production work is better served by specialists with narrow mandates and explicit boundaries, for the same reason human teams split these responsibilities.

Kapten organises the work as a crew:

• Kapten turns the request into a plan and hands each part to a specialist.
• Navigator reads the repository and maps the services, ports and dependencies.
• Shipwright makes each service buildable as a reproducible image.
• Bosun plans the cluster, network, databases and secrets in your account.
• Warden reviews what will be exposed and who will be able to reach it.
• Purser estimates what it will cost each month.
• Helmsman ships it behind health checks, with a rollback ready.
• Lookout watches it afterwards, and starts from what changed when something breaks.

The specialists work in parallel where they can and in sequence where they must. Their findings come back to Kapten, which merges them into a single plan.

The plan is the product

The most important property of this model is that nothing changes until a human approves a plan. The plan is a readable document: the resources that will be created, the configuration that will be applied, the services that will be released, the estimated monthly cost, and the security findings that came up along the way. It is the same kind of artefact an experienced SRE would put in front of a team lead before touching production, produced in minutes instead of days.

You read it. You ask questions about it, in the same conversation. You approve it, or you change it. Only then does the crew act, through a scoped role in your own cloud account, with every call recorded.

5. Your infrastructure, not ours

Closing the deploy gap with agents would be a poor trade if it reopened the ownership problem that a PaaS creates. The infrastructure the crew provisions lives in your cloud account.

• Your account, your region. You choose where the application runs, and the answer to “where is our data?” is your own architecture.
• Your bill. Cloud usage appears on your provider’s invoice, where your existing credits, commitments and discounts apply. Kapten’s fee is separate.
• Standard building blocks. Kubernetes, managed databases, standard networking. Nothing in the account requires Kapten to keep running.
• A clean exit. If you stop using Kapten, you revoke the role. The cluster keeps serving traffic, because it was always your cluster. Your team, or the SRE you eventually hire, takes over operations from a known starting point.

That last point is worth dwelling on. The agent-delivered operations model is meant to carry you to the point where you would hire a platform engineer, and then to hand that person a foundation built from conventional parts rather than a black box they have to reverse-engineer.

6. What changes for the builder

Concretely, here is what the path from repository to production looks like with an agent crew in the loop. This is an illustrative sequence, not a benchmark.

1. You ask. In the client you already use, you describe what you want running and where.
2. Navigator maps. It reads the repository, finds three services and a Postgres dependency, and notes that the worker expects a Redis queue that is not declared anywhere. It asks you whether that is intended rather than guessing.
3. Specialists plan in parallel. Shipwright prepares image builds. Bosun plans a cluster, a managed Postgres instance and a Redis cache. Warden notices that the API reads a secret from a committed file and proposes moving it to the secret store. Purser estimates the monthly cost.
4. Kapten presents one plan. Resources, configuration, releases, cost, findings. One document.
5. You approve. Perhaps after asking for a smaller database instance for now.
6. The crew acts. Bosun provisions through the scoped role. Helmsman releases each service behind its health check.
7. Lookout stays. When the next release raises the error rate, it correlates the spike with that deployment, shows the relevant log lines, and proposes the rollback. You approve that too.

The eight concerns from chapter two have all been addressed, and none of them required you to become an infrastructure specialist first. They did require you to read a plan and make decisions, which is exactly the part that should stay with you.

What you still need to bring

The crew can infer a great deal from a repository, but some facts only you have. Coming to the first conversation with them makes the first plan far better:

• The account and region the application should run in, and who owns that account.
• The domain it should answer on, and who controls its DNS.
• The data: whether there is existing data to migrate, and what its owner expects for backups and retention.
• The third parties: payment providers, email services, model APIs, and which credentials belong to which environment.
• The people: who approves production releases, and who should hear about it when something breaks.

None of these require infrastructure expertise. They require knowing your product, which you already do.

7. Limits worth stating

An honest account of this model includes what it does not do.

• It does not remove responsibility. You still own the application’s behaviour, the data decisions and the approval of every change to production. The crew makes those decisions easier to make well; it does not make them for you.
• It does not replace judgement about your product. Whether a feature should ship on a Friday, whether a customer’s data may leave a region, whether an outage warrants a status page: those are business decisions.
• It is early. Kapten is in early access. Supported clouds, clients, workflows and the exact set of actions available to agents are confirmed for each setup during onboarding. Treat the descriptions in this paper as the direction of the product, not a specification of what is available on any given day.
• Agents can be wrong. That is why the model is built around plans, approval and scoped permissions rather than around trust. The guardrails are not an afterthought; they are the design.

Where to start

If you have a repository that works and nowhere to put it, the deploy gap is probably the most expensive thing in your project right now. A few ways to begin:

• Read how the Kapten MCP server connects your agent to production on the MCP overview.
• Browse the multi-agent workflows, starting with shipping a first app from a repository.
• Work through the production readiness guide before your first release.
• Read the companion paper, The agentic SRE, for the operating model behind the crew.
• When you have a real application in mind, request early access and tell us what you want to deploy.