How to Deploy an App Built With an AI Coding Agent

You asked an AI coding agent to build something, it wrote the code, and it runs. Locally, in your browser, on localhost, it works. That feeling — "it works on my machine" — is exactly where a lot of vibe-coded projects quietly stall out. Deployment is a different skill from building, and it's the step most beginners haven't done before, so it's worth walking through deliberately instead of guessing.

Why deployment trips people up even when the build went fine

Writing code and shipping code are not the same job, and an AI coding agent being great at one doesn't automatically make the other one easy:

• Hosting — your laptop isn't a server. Something else needs to run your code 24/7 and be reachable from the internet.
• Domains — localhost:3000 means nothing to anyone else. You need a real address, and usually a DNS record pointing at it.
• Environment variables — API keys, database URLs, and secrets that sat quietly in a .env file on your machine now need to exist somewhere else too, without ending up in your public code.
• Build steps — what you were running locally (npm run dev, a dev server with hot reload) is often not what should run in production. Production usually wants a built, optimized version, produced by a different command.

None of this means the app is broken. It means "runs on my machine" and "runs on the internet, reliably, for anyone" are two separate problems, and the second one has its own small set of concepts worth learning once.

The common deployment paths, beginner-friendly

Most apps fall into one of two shapes, and the right hosting approach follows from which one you have.

1. Frontend-only / static sites. If your app is just HTML, CSS, and JavaScript that runs entirely in the browser — no server-side code, no database — a static host is the simplest option. You upload the built files, and the host serves them to visitors. There's no server to manage, no backend to keep running, and this category is usually free or very cheap for small projects.

2. Apps with a backend. If your app needs a server process — an API, a database, user authentication, anything that has to run continuously and respond to requests — you need a platform-as-a-service (PaaS). These platforms take your code (often straight from a git repository), run the build step for you, keep the server process alive, and give you a URL. You configure environment variables through their dashboard instead of a local .env file.

3. Connecting a custom domain. Whichever path you pick, the host gives you a default URL first (something like your-app.vercel.app or your-app.up.railway.app). Pointing your own domain at it is a separate, later step: you buy the domain from a registrar, then add a DNS record (usually a CNAME or A record) that the host tells you to add, and wait for it to propagate — this can take anywhere from minutes to a couple of hours.

The mistake beginners make most often isn't picking the "wrong" host — it's not realizing which category their app is in. A React app that calls a backend API isn't "frontend-only" just because most of the code is in the browser; the API part still needs somewhere to run.

Letting the agent help with deployment too

The same AI coding agent that wrote your app can walk you through this part — it's just a different kind of prompt than "build me a feature." A few ways to use it well:

• Ask it to prepare the app for deployment. Have it check for hardcoded localhost URLs, confirm there's a proper build command, and make sure secrets are read from environment variables rather than typed directly into the code.
• Ask it to write the config the platform needs. Most PaaS providers look for a specific file or a build command in package.json — the agent can generate that config for your specific framework instead of you hunting through docs.
• Ask it to walk through the actual steps with you, one at a time — creating the account, connecting the repository, setting environment variables — rather than dumping a wall of instructions. Ask it to explain what each step does, not just what to click, so the next deploy is one you can do yourself.
• Paste errors back to it. Deploy logs are often cryptic on a first read ("build failed," "missing environment variable," a stack trace from a platform you've never used) — the agent is good at reading those and telling you which line of config or code to fix.

This is also where having an agent that can actually run commands on your machine — not just describe them — saves real back-and-forth: it can run the build locally first and catch a broken build before you ever push it to a host, instead of you finding out from a failed deploy.

Checklist: what to verify after deploying

Deployment "succeeding" (a green checkmark from the host) isn't the same as the app actually working for a stranger. Before calling it done, check:

• Open the live URL in a fresh incognito/private window, not the tab you've been developing in. This catches issues hidden by your browser's cached files or logged-in session.
• Click through the core flow as a new user would — sign up, load the main page, submit a form — not just the homepage loading.
• Check the browser's network/console tab for failed requests. A page that "loads" but silently fails to call its API looks fine at a glance and isn't.
• Confirm secrets aren't exposed in the frontend bundle. Anything shipped to the browser is public, full stop — API keys or credentials should live only in backend environment variables, never in frontend code, even if it's "just" an internal tool.
• Test on mobile or at least a narrow browser window, if the app is meant to be used that way.
• Verify the custom domain actually resolves — and that HTTPS is working, not just HTTP. Most modern hosts handle the SSL certificate automatically once DNS is set up correctly, but it's worth confirming rather than assuming.
• Refresh on an inner page, not just the homepage. Some frameworks route entirely in the browser and will 404 on a hard refresh of /dashboard unless the host is configured to redirect all routes back to index.html.

Every item on that list has, at some point, been the difference between "I deployed it" and "I deployed it and it actually works."

Deployment is a skill, and it gets easier

The first deploy is the slow one — new vocabulary, a dashboard you've never seen, DNS that takes an hour to propagate while you refresh anxiously. The second one is faster, because you've already learned what a build command is and where environment variables live. Having an AI coding agent alongside you for this step isn't cheating; reading a deploy log, understanding what a CNAME record does, and knowing why secrets can't live in frontend code are skills worth actually picking up, and a good agent explains them as it goes rather than just doing the click-through for you.

meshcode is a native desktop app (Mac and Windows) that can run and iterate on your code locally — the same place it can help prepare it for the platform you deploy to. It's free to start, with pay-as-you-go pricing (top up from $1, no subscription) once you're using it for real work, and you can bring your own Claude Code or Codex CLI keys if you already have them.

👉 Download meshcode — Mac, Windows