I built an app with Claude Code. Where should I host it?

You have a repository that works on the machine that built it. This page is about the gap between that and a deployment you can stop worrying about, and it starts one step before the hosting comparison: diagnosing what your app actually needs a host to do. Get the category right and the brand choice gets smaller, cheaper to reverse and much less stressful.

Short answer

The category of hosting is decided by what your app does when a request arrives, and you can read that off the repository in about ten minutes. Most AI-built web apps, a Next.js or Node service with a database, land in the managed platform shape: a host that builds from your Git repository, runs the web process supervised, provisions and backs up the database, and lets you set environment variables without a shell. The brand is a smaller decision than it looks once the category is right; the checks below do most of the separating, and the comparisons on this site cover the managed platform candidates stack by stack for when you get there.

Who this page is for

You, probably, holding a repository that works: an app built with Claude Code, Cursor, Copilot or any of the coding agents, which runs on the machine that built it and nowhere else. A Next.js dashboard, a Node API, an internal tool over Postgres, a SaaS starter with Stripe already wired. You do not need hosting explained. You need the gap between this working repository and a running production deployment named precisely, and a way to choose the platform that closes it without turning the choice into a research project.

Who should choose something else

• Your output is a static site, docs or a landing page with no server code: static hosting ends the discussion, and none of this page's frame applies.
• You already ship a container and have opinions about registries: the container shape below is your row of the table, and the platform debate mostly shrinks to "runs images, has logs".
• Your constraint is compliance rather than capability, regulated data or contractual region requirements: the decision is compliance-led and no capability checklist outranks it.

What an AI-built app actually arrives as

Before any platform is compared, read the repository honestly. These are the traits an AI-built app arrives with, close to always, and each one is a hosting requirement in disguise.

• Only the dev command has ever been verified. npm run dev works. The production start command has possibly never been executed by anyone. Whatever breaks in npm run build && npm start breaks on the platform, where you pay by the minute to discover it. Run it locally first; this is the cheapest test in the entire deployment and the most skipped.
• Real secrets are already in .env. Often nearly committed, often pasted into a chat transcript on the way. The platform's environment-variable handling is not a convenience feature here; it is the thing standing between your keys and the public. Rotate every key that touched a transcript or a screenshot before the first deploy, not after.
• The database is assumed local. A SQLite file, or a Postgres on localhost, migrations never replayed in order against a fresh copy. The host has to provision the real one, and the first run of migrations against it is a deployment step, not a formality.
• State sits on the filesystem. Uploads in public/, generated files, that SQLite file growing quietly. A rebuild or a second server orphans all of it. Where state lives is a hosting decision you make before the first deploy or relearn during an outage.
• Background work the UI assumes. A queue, a cron, a scheduler in the code that nobody has started. It needs supervised processes that are not the web server, and a platform that treats them as first-class.
• Nobody has ever killed it. The app has not been restarted, unsupervised, and watched. Whatever notices the process died and brings it back has to be the platform, because nothing in the repo will.

These are not bugs. They are the hosting decision expressed as repository facts, and they map straight onto the shapes below.

The five deployment shapes

Diagnose the app into exactly one shape. The shape, not a brand preference, picks the category of hosting.

Shapes stack: a real SaaS app is usually 2 plus 3 plus 4. The rows are not rivals; they are the requirements list that any candidate platform has to clear in full.

Shape 1, static export. If the build emits a directory and nothing needs a live process, the answer is static hosting and this page is nearly over. The check that matters: open the built app with the dev server stopped. Everything that still works is static. Everything that stops working tells you which shape you actually have.

Shape 2, one web process. The common case. The app needs a platform that pulls from the repository, runs the build itself, starts the production process under supervision and puts TLS in front of it. The trade is invisible until the app grows a cron job and discovers the process model only has room for one thing.

Shape 3, web plus workers. The queue worker is not an afterthought behind the web tier. It is a second process that must be deployed, supervised, restarted and given its own environment and connection budget. Platforms that only really model one process per app turn this shape into cron-driven hacks, and cron-driven hacks are where background work goes to die quietly.

Shape 4, state externalised. The filesystem is not a database. When uploads and data move to a managed database and object storage, the compute box becomes disposable, which is the property that makes rebuilds, rollbacks and scaling survivable. The cost is a second thing to provision, bill and back up, and it is almost always worth it.

Shape 5, container. If you ship an image, the platform question reduces to running images with logs and a restart policy. You bought back control of the runtime and paid for it in maintenance: base image patching is now on you. For a first production deploy of an AI-built app, treat this shape as a destination, not a starting point, unless operating it is the point of the exercise.

What to verify on any host before you pay

These are the expectations to hold any candidate platform to, whichever category you landed in.

• It builds from the repository at deploy time, against the runtime version the app declares, or it consumes a CI artefact. Anything modelled on uploading a zip re-introduces the machine that built the app as a dependency, which is the dependency you are trying to leave.
• Environment variables are set per environment, without a shell, and secrets do not appear in build logs. Test this with a canary value before real keys ever arrive.
• A crashed process restarts and a failed build does not touch the running version. Ask what happens to production when the next deploy breaks, and do not accept an answer you have not seen demonstrated.
• Rollback to the previous release exists and takes minutes. A rollback that has never been rehearsed is a hope, not a capability.
• Logs survive restarts and can be searched without SSH. The first production incident should not begin with "where do the logs go".
• The database is provisioned, backed up on a stated schedule, and the restore has been run by you, because the platform's backup is only a rumour until you have restored from it once.
• The connection budget accounts for the workers, the web tier and any pooler together, not the web tier alone.
• The cost shape is readable in advance: what bills when the app is idle, overnight, during a failed build. If you cannot say what a quiet month costs before you deploy, the answer will eventually arrive as an invoice.

The cost frame

Three cost shapes cover most of the market. Prices move often enough that any number printed here would be stale by the time you read it; the shapes hold.

Per-request billing, the serverless shape, prices a quiet app at nearly zero and a busy one unpredictably, and it quietly assumes the app is stateless between requests. Always-on hourly instances price a fixed ceiling and hand you the floor: an idle app pays full price, a scaling event is a decision, and the cron job that keeps a serverless app awake is instead just part of what the instance does anyway. Per-app platform seats simplify the bill and cap the ceiling, at a unit price that favours small counts of serious apps over many small ones.

The traps specific to this audience: free tiers that meter build minutes rather than runtime, which an iterative AI-assisted workflow burns faster than anyone expects; vertical scaling that pays for the daytime peak around the clock; and the worker process from shape 3 doubling the always-on bill the day it ships. None of these are hidden; all of them are easier to read before the first deploy than after.

Recommendation

Conditional, because the right answer depends on the shape you diagnosed:

• Static export: static hosting; stop reading hosting comparisons and ship.
• One web process plus a database: the managed platform shape. For a first production deployment, a raw VPS you also learn to operate is a second project stacked on the first, unless operating it is the point.
• Background workers: a platform that models workers as first-class processes, or the workers will end up as cron entries, and cron entries do not restart themselves.
• State that matters: externalise it on day one. Every platform decision gets easier when the compute box is disposable.
• Container: any competent image runtime; the platform debate shrinks to logs and restart policy, and the maintenance you signed up for is the price.

If you land in the managed platform shape, start with the provider this site covers in most depth: the Cloudways review covers what it is like to run real production sites on it, and the head-to-head comparisons pit it against the usual alternatives for your stack. Once you have picked a platform, the production checklist walks the deploy step by step, and the TCO calculator settles what your setup actually costs at your numbers.