Claude Code built your app. Here is how to put it online

Can Claude Code deploy apps? It can do most of the work: write the Dockerfile, the Compose file and the CI workflow, and run deploy commands in your terminal when you approve them. What it cannot do is host the app: Claude Code is a coding tool that runs on your computer (or in a cloud session), so the app still needs a hosting platform or a server you control, and how much of the deploy you let the agent run is your decision. This article is part of the guide to deploying an AI-built app to your own server.

The Claude Code facts come from Anthropic (opens in a new tab)'s documentation at code.claude.com, checked on 11 November 2026.

What Claude Code does, and what it does not

Anthropic describes Claude Code as "an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools". It runs in the terminal, as an extension in VS Code, Cursor (opens in a new tab) and JetBrains IDEs, as a desktop app, and on the web.

What that means for deploying:

• It writes code and configuration, such as a Dockerfile, a compose.yaml, a Caddyfile, a GitHub Actions workflow or a health check route.
• It works with Git. It stages changes, writes commit messages, creates branches and opens pull requests.
• It runs commands. Through its shell tool it can run docker build, ssh, rsync or a platform's CLI, with whatever access your shell has.
• It connects to other tools through MCP, the Model Context Protocol, and can be extended with skills and plugins. Anthropic's docs even use a /deploy-staging skill as an example of a workflow you might package.

What it does not do:

• It is not a host. It gives your app no server, domain, certificate or database. Claude Code on the web runs sessions in the cloud to work on code; it does not serve your app to visitors.
• It does not keep your app running. A development server it starts is for trying the app, not for visitors; production needs a container or a process manager on a real server.
• It does not decide what it may touch. You do, through its permission settings.

In Claude Code's Manual permission mode, every shell command needs your approval, except a built-in set of read-only commands, and every file edit asks too. Other permission modes ask less; in auto mode a classifier reviews actions instead of you. Which mode a session starts in depends on your plan and your settings, so check yours. When the command is ssh into a production server or a CLI that is logged in to your hosting account, that prompt is your only brake.

The safer way to let an agent deploy

The two ways to use Claude Code for a deploy carry very different risk:

1. The agent runs the deploy. You give the session SSH access to the server or a logged-in platform CLI, and approve its commands one by one. Fast, but every mistake is made directly on production, and the credentials are available to the session.
2. The agent writes the deploy; CI runs it. Claude Code writes the Dockerfile, the Compose file and a GitHub Actions workflow and opens a pull request. You review it, merge it, and GitHub Actions deploys with credentials stored as repository secrets. The agent never holds the production key, and every change to the deployment is a reviewed commit you can revert.

Use the second for anything with users. Either way, never paste API keys, database passwords or tokens into the chat; set them in your terminal's environment or in GitHub (opens in a new tab)'s secrets, and have the code read them from there.

From Claude Code's output to a live URL

The path is the same as for any other app, except that you can ask the agent to do each step and review what it produces.

1. Find out what it built

Look at package.json (or requirements.txt, pyproject.toml, go.mod). The stack decides the hosting:

• a static site or single-page app (a Vite build, an Astro site) is files, served by any web server with a fallback to index.html for client-side routes;
• a Next.js (opens in a new tab), TanStack Start or Node.js (opens in a new tab) server needs Node.js running all the time;
• a Python or Go API needs its own runtime;
• a database next to it (PostgreSQL (opens in a new tab), SQLite (opens in a new tab)) needs a place for its data that survives deploys.

2. Push it to GitHub

Ask Claude Code to commit and open a pull request, or push yourself. Check that .env files are in .gitignore before the first push: a secret in Git history stays there after you delete the file.

3. Choose where it runs

A hosting platform (Vercel (opens in a new tab), Netlify, Cloudflare (opens in a new tab), Render (opens in a new tab) and others) is the least work: connect the repository and set the environment variables. A server you control costs a fixed amount, holds the database and anything else next to the app, and keeps the app independent of one vendor. Own server vs Vercel compares the two. The rest of this article takes the server route.

4. Have Claude Code write the deployment as code

For most apps, three files are the whole deployment: a Dockerfile for the stack, a compose.yaml that runs the app next to Caddy (opens in a new tab), and a Caddyfile that tells Caddy which domain to serve:

app.example.com {
	reverse_proxy app:3000
}

Caddy gets and renews the HTTPS certificate for that domain by itself, once the domain's DNS points at the server and ports 80 and 443 are open. Ask Claude Code for the Dockerfile with specific constraints, so you can check them in review, for example: "Write a multi-stage Dockerfile for this app on Node.js 22 that runs as a non-root user, listens on the port in PORT and 0.0.0.0, and keeps .env out of the image."

Then compare what it wrote with a tested version for the same stack from the builder guides, built and run on Node.js 22 on 11 November 2026:

• a standalone Next.js image, in deploy a v0 app without Vercel;
• a static Vite app served by Caddy, and a TanStack Start server, in deploy a Lovable app to your own server;
• a Node.js server with PostgreSQL, including moving existing data, in move a Replit app to a VPS.

Two things to check in whatever an agent writes: public build-time variables (VITE_, NEXT_PUBLIC_) must be passed as build arguments, not only set at run time; and the server must listen on 0.0.0.0, or the proxy cannot reach it inside its container.

5. Deploy from CI

Ask for a GitHub Actions workflow that builds the image and deploys it to the server on every merge to main, with the server's SSH key and the app's secrets as repository secrets. Deploy a Docker Compose app to Hetzner with GitHub Actions shows a complete workflow, and how to deploy a web app to a VPS covers preparing the server itself: SSH keys, the firewall, Docker (opens in a new tab). Once that runs, zero-downtime deployments with Docker Compose stops each deploy from dropping visitors.

Cursor and other coding agents

Cursor describes itself as "a coding agent for building ambitious software". Like Claude Code, it writes and runs code on your machine and connects to GitHub, and the overview of its documentation describes no hosting for your app. Everything above applies unchanged. Claude Code also runs inside Cursor through its extension, so you can use both in the same editor.

Deploying from Claude Code with OpsCrew

OpsCrew is an open-source tool that does the server route for you, and it has a Claude Code plugin. Install it inside a Claude Code session:

/plugin marketplace add softzer0/opscrew
/plugin install opscrew@opscrew

The plugin adds skills such as /opscrew:opscrew-deploy (scan, analyse, interview, design, prepare the code, provision and verify), /opscrew:opscrew-scan (a free security scan with guided fixes) and /opscrew:opscrew-troubleshoot (read-only status, logs and advice). It needs Node.js 22 or newer with npm (opens in a new tab), and no API key beyond your Claude Code plan, because OpsCrew's MCP server runs on your computer and never calls a model itself.

It is built around the safety problem above:

• Only you approve. A tool that changes something shows its plan, its hash and its cost in a dialog that Claude (opens in a new tab) cannot answer for you, and Claude Code asks your permission before every such tool call, even in its auto modes. Destroying plans need you to type the resource's name.
• Secrets never pass through the chat. Tokens are read from the environment you start Claude Code in, and the app's secrets are entered in your own terminal; tool results never contain them.
• The deploy runs in CI. OpsCrew opens pull requests with the Dockerfile and the deploy workflow, and your app deploys from GitHub Actions on each merge.

It deploys to a new server on Hetzner Cloud (opens in a new tab) or DigitalOcean (opens in a new tab), to a server you already have, or to Cloudflare's or GitHub's hosting for sites that need no server. The plugin's guide has the details, and the setup page lists the accounts and keys to create first. From Cursor or any other editor, the same steps run in a terminal with npx opscrew.

For everything else about moving an AI-built app to a server, start from the guide to deploying an AI-built app to your own server.