Your build works end to end, and the sales lead wants to walk through it before she shows a customer, so you copy the address out of your browser bar, http://localhost:3000, and message it to her. Her reply is a screenshot of a browser error, "This site can't be reached," with one line under it: "wrong link?" The link is not wrong, it is local. localhost is an address that always means "this machine right here," so on her laptop it pointed at her own laptop, which is not running your build. There is no better link to send: your product exists on one computer in the world and goes dark when you close the lid.
A product that lives only on your laptop is a demo. The fix is renting a computer that never sleeps, with an address anyone can reach. The renting is called hosting, and this chapter teaches you to compare the options and read the terms.
The obvious objection: why not leave your own computer on?
Leaving your own computer on costs nothing new, but it has no way to be found: a home connection has no stable public address (the one your provider assigns changes without notice), and your router turns away unexpected visitors by default. It is also one machine, so every crash, update, and power blip is an outage, and you are the one getting up at 3am. Hosting providers sell those missing pieces: a permanent public address, machines in numbers, and automation that restarts what breaks.
Hosting is renting a computer connected to the internet: a permanent address anyone can reach, running whether your laptop is open or not.
The options, from least work to most control
Every option is the same rental with one variable: how much of the machine you manage.
Serverless is the convenient end: you bring code, the platform runs it whenever a request arrives, and you pay per call; the servers exist, you just never meet one.
Managed platforms keep your whole app on an always-on computer the provider operates, give it a URL, and charge a steady monthly amount. You never install updates.
Containers pack your app and everything it needs to run, the language, the installed software, the settings, into one sealed box; the name is literal: the same box runs identically on any machine that can open it. You write a short recipe file listing what goes inside, and because the environment ships in the box, the surprises from why it works on your machine and breaks online mostly disappear.
Virtual machines behave like a whole computer of your own, carved by software out of a larger physical one, running a full operating system. You get the most control, and with it every chore of running a machine: installing, updating, securing, restarting.
Your builds will be happiest at the left end: serverless for small or bursty traffic, managed for an always-on machine and a predictable bill. Moving right later is routine.
The platform names you will hear
Ask any tool where to put a build and the same names come back. Vercel is a serverless platform, and the tools that generate your starting code often propose it first. Render is a managed platform in the spectrum's middle. Cloudflare runs your code across a worldwide network of machines, near whichever user asked; this site runs there. The general-purpose clouds from Amazon, Google, and Microsoft sit underneath. If you built inside an AI app builder, its Publish button is the same rental, bundled in.
A pricing page, printed and dissected
Every platform spells out its rent on a pricing page, and the pages share one structure. Here is a condensed tier table; the numbers belong to no single platform, but the layout matches nearly all of them:
HOBBY PRO ENTERPRISE
No charge Flat monthly amount, Custom contract,
plus overage charges talk to sales
Included every month Included every month Included every month
100 GB bandwidth 1 TB bandwidth Custom limits
1 million requests 10 million requests
6,000 build minutes 25,000 build minutes
If you go over If you go over
Project paused until Billed per extra GB and
the month resets per extra million requests
Read it like rental terms.
The columns differ by limits, not by kind. Every tier meters the same things; only the amounts, and what happens past them, change as you move right.
The rows under "included" are the meters. Bandwidth is the data your app sends out: every page, image, and reply that visitors' browsers download. Requests count how many times anyone asks your app for anything, and one page load can fire dozens. Build minutes are the time the platform spends turning your saved code into the runnable version it serves; engineers also call that runnable result a build, giving the word a second meaning.
Find the "if you go over" line first. On the free tier the project pauses until the month resets; on the paid tier the charges follow. It tells you whether a surprise month costs you availability or money.
An AI product pays two separate bills
Read the meters again and notice what is missing: nothing in that table buys a model reply. The model runs elsewhere: racks of machines built around GPUs, the specialized processors AI models require, operated by its provider. You rent it through an API, paying in tokens, the small pieces of text a model takes in and produces, and your backend, where the real work happens, holds the key and makes the call.
An AI product pays two separate bills: the host's, metered in requests and bandwidth, and the model provider's, metered in tokens.
For any feature, ask which bill it lands on: a redesigned results screen moves the host's meters, a longer prompt moves the token meter, and a feature calling the model on every keystroke moves both. Renting GPU machines to run the model yourself is possible, but decline it at this level: they are the most expensive line on any cloud's price list, and nearly every AI product reaches its model through an API.
A deploy moves your code onto the rental
A deploy puts your code on the rented computer. Your save points from Git: the undo that makes AI edits safe travel to the platform, which spends a few build minutes turning them into the new runnable version and swaps it in for every visitor. In practice it is one terminal command, or automatic once the platform watches your repository.
Approve the hosting pick
This is the same move you ran for Languages and frameworks: approve the pick. The tool that generates your starting code usually proposes a host along with the framework, so ask it to defend the proposal: the platform, where it sits on the spectrum, what the free tier includes, and what happens when you go over. Approve it, unless you can name a specific constraint that points elsewhere:
- Traffic will be steady and heavy. Once the calls never stop, an always-on machine with a flat bill beats paying per call.
- The code needs a setup the friendly platforms do not offer. A specific operating system, unusual installed software, or work that runs for hours points toward containers.
- Somebody already pays for a cloud. A company contract and a team that runs it can outweigh starting fresh.
If you cannot state your constraint in one sentence, go with the left edge.
Try it now
This drill takes about fifteen minutes and spends nothing; real pricing pages run longer and busier than our composite. You leave with one finished sentence about your build's costs, kept for Monitoring, how you know it broke (and what it costs) to pick up.
No setup: Open the pricing page of one platform from this chapter and find the anatomy you just read, the tiers, the meters, and the "if you go over" line. Then finish the sentence "my build would start paying the month that ___ happens," using a meter you found.
With your tools: In Claude Code, with your project open or your idea described in one sentence, ask where the build should live and require a defense: a specific platform, its tier, what its free tier includes, and which meter your build would hit first. Push back once, asking what would make a different tier win; then approve. You are rehearsing the approval, not deploying. Same move in Codex or Cursor, from the sidebar chat. If nothing is installed yet, the Setup Clinic gets you running.
Chapter Summary
- Hosting is renting a computer connected to the internet, so your product holds an address anyone can reach and keeps running when your laptop is closed.
- Your own computer cannot do the job: home internet has no stable public address, one machine means every crash is an outage, and you would be the one restarting it at 3am.
- The options differ only in how much of the machine you manage: serverless runs code on demand, managed platforms keep an always-on app with a steady bill, containers seal your app and its environment into a portable box, and virtual machines trade every chore of the machine for the most control.
- Start at the convenient left end of the spectrum; moving right later is routine, and only a constraint you can state in one sentence justifies starting further right.
- The names to recognize are Vercel, Render, and Cloudflare, with the Amazon, Google, and Microsoft clouds underneath; an AI app builder's Publish button is the same rental, bundled.
- A pricing page is a tier table: the meters are bandwidth, requests, and build minutes, and the first line to find says whether going over pauses the project or starts charging.
- An AI product pays two separate bills, one to the host that runs the app and one to the model's provider, paid in tokens through an API; for any feature, ask which bill it moves.
- A deploy moves your saved code onto the rented computer, as one terminal command or automatically once the platform watches your repository.
- Billing alerts and spending caps guard the metered edge, and you will set them in the pre-flight chapter before you ship.
- Next is Auth, who you are vs. what you can do, because once the rented computer answers anyone who finds it, you decide who it recognizes and what each person may do.
Sources
- Vercel public product and pricing documentation (last verified July 2026).
- Render public product and pricing documentation (last verified July 2026).
- Cloudflare public product and pricing documentation (last verified July 2026).
- The tier table above is a composite for teaching: it reproduces the structure these pages share, not any single platform's terms.