You built it with an AI. Here is how to ship it.

The deploy gap

You described an application to Claude, Cursor or another coding assistant, and an afternoon later it works. The pages load, the API answers, the database fills up. Then you try to put it somewhere other people can use it, and the progress stops.

That is not a failure of the code. A coding assistant is very good at the part of the work that lives in the repository. Production is mostly the part that does not: the cloud account, the network, the database that has to survive a restart, the secret that cannot be pasted into a chat, the domain, the health check, the plan for when the deploy goes wrong. None of that is in localhost:3000, and most of it is invisible until it is missing.

This guide walks through what a working prototype is missing, in the order you will run into it, and shows where the Kapten agent crew takes over each step. You can read it as a checklist even if you never connect an agent.

1. A build that does not depend on your laptop

On your machine the app runs because your machine has the right Node version, a node_modules folder from three weeks ago and an environment variable you set once and forgot. Production has none of that.

The first thing to produce is a reproducible build: a container image per service, built from the repository alone, the same way every time.

• One image per service. A frontend, an API and a background worker are three images, even if they live in one repository.
• A pinned runtime and base image, so next month’s build does not quietly change.
• A start command and a listening port that come from configuration, not from code.
• No secrets baked into the image.

Who does it: the Navigator reads your repository and identifies the services, runtimes, build commands and ports. The Shipwright writes or reviews a Dockerfile for each one and opens a pull request instead of pushing to your branch. If you want to do it by hand, the Dockerfile checklist covers the same ground.

2. Configuration that lives outside the code

AI-written code often has configuration inlined: a database URL in a module, an API base URL in the frontend, a feature toggled by editing a constant. That works for one environment. It breaks the moment you have two.

Move every value that differs between environments into environment variables, and give each environment its own set. A good test: could you run the same image in staging and production without rebuilding it? If not, something environment-specific is still in the code.

3. Secrets that never touch the chat

The prototype probably has an .env file with a payment key, an email provider key and a database password in it. Three rules before anything ships:

• Secrets are never committed, and never pasted into a prompt. A conversation is not a vault.
• Each environment has its own credentials. A staging deploy should not be able to charge a real card.
• Anything that was ever committed should be treated as leaked and rotated.

Who does it: the Warden scans the repository, the image and the environment variables for secrets, and reports each finding with a fix. Values are set through set_secret, which stores them without echoing them back into the conversation. The secrets guide explains the pattern in more depth.

4. Data that survives

Locally, the database is a file or a container you can delete and recreate. In production it is the one thing you cannot recreate.

Decide where persistent data lives (usually a managed database in your cloud account) and agree the basics before the first real user signs up: automated backups, point-in-time recovery, a restore you have actually tested, and a private network path so the database is not reachable from the internet. Migrations should run as an explicit step, not as a side effect of the app starting.

Who does it: the Bosun plans the managed database, its network and its backups inside your account. The Postgres checklist lists the decisions it will ask you to confirm.

5. An environment with a shape

A deployment is not a single box. It is a set of services, the data stores they use, the routes between them and the endpoints that are public. Writing that shape down is the difference between “it is on a server” and “we know what is running”.

Who does it: the Bosun turns the Navigator’s map into an environment plan (cluster, network, managed services, storage, secrets) and shows it as a readable dry-run before anything is created. The plan includes a monthly estimate from the Purser, so the first bill is not a surprise.

6. A domain, TLS and a public edge

Decide which services are public and which stay internal. Usually only the frontend and the public API need an endpoint. Each public endpoint needs a domain, a certificate and a sensible timeout. Everything else should be reachable only from inside the environment.

The Warden reviews this before release: unexpected public ports, endpoints without TLS and databases with public addresses are exactly the kind of finding it exists to catch.

7. A definition of healthy

A container that started is not an application that works. Give each service a health endpoint that reflects whether it can do its job. For an API, that usually means it can reach its database. Rollouts are gated on that check, so “deployed” and “serving” mean the same thing.

Who does it: the Helmsman releases images behind health checks and stops the rollout when health fails. The Lookout watches errors, latency and restarts afterwards. The observability starter kit explains which three alerts to start with.

8. A way back

Every release needs an exit. Keep previous images addressable so a rollback re-points traffic to something that already exists rather than rebuilding it. Remember that an image rollback does not undo a schema migration. The rollbacks guide explains how to make the two compatible.

9. A cost boundary

AI-built apps are often side projects that become real overnight, and cloud bills follow the same curve. Set a budget for each environment before you provision it. Know which line items grow quietly: load balancers, NAT gateways, log retention, idle preview environments. The cost guide lists the usual suspects.

The Purser estimates a plan before you apply it and enforces the caps you set.

Putting it together

You do not have to run these steps one by one. With Kapten connected to your coding assistant through MCP, you can ask for the whole thing:

Ship this repository to a new production environment on AWS in eu-west-3.
Use a managed Postgres. Only the web app should be public, on app.example.com.
Keep it under my budget and show me the plan before you change anything.

The Kapten turns that request into the Ship your first app workflow: the Navigator maps the repository, the Shipwright and the Bosun prepare the build and the infrastructure in parallel, the Warden and the Purser review the result, and you get one plan to approve: a diff, a cost and a risk note. Nothing is provisioned until you do.

After approval, the Bosun provisions, the Helmsman releases, and the Lookout starts watching. The infrastructure lives in your cloud account, on your bill.

What stays with you

Agents can do the platform work. Some decisions remain yours, and they should:

• Which data you collect, where it is stored and who can see it.
• Whether the application is ready for real users.
• Who owns production and approves changes to it.
• What happens when something breaks at night.

Kapten is in early access. The available clouds, connection methods and agent actions are confirmed during onboarding. Request early access and tell us what you built. The more concrete, the more useful the first conversation.