Skip to content
AI-Native PM
7 min · 0 of 7 in The Technology Stack

Hosting, renting a computer on the internet

Previous chapterNext chapter

This morning your phone backed up its photos to the cloud, a word that sounds like nowhere in particular. They went somewhere specific: a warehouse computer in northern Virginia or Frankfurt or Singapore, owned by a company that rents it by the slice with the meter running. The cloud is just someone else's computer that you pay to use, and once you see it that way the mystery is gone.

Your build will need a slice of its own. On your laptop it answers at localhost, an address nobody else can reach, and a product that goes offline when you close the lid is only a demo. The fix is renting a computer that never sleeps, that renting is called hosting, and this chapter teaches you how to compare your options.

The four hosting options, from least work to most control

Hosting is renting a computer connected to the internet so your product keeps running whether your laptop is open or not.

Every option you will be offered is the same rental with one thing changing: how much of the machine you have to manage yourself.

Serverless is the convenient end. You bring code, the platform runs it on demand when a request arrives, and you pay per call. You never pick a machine, size it, or wonder whether it is on. The name misleads in a friendly direction; the servers exist, and you never meet them.

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 patch an operating system, and the computer is continuously yours, which suits constant traffic and long-running work.

Containers package your app together with its environment into a sealed unit a provider runs for you. You control the setup that environments showed can make or break a run, and you take on the job of describing it.

Virtual machines are the whole box: a slice of a physical computer with a full operating system, where everything above the hardware is your job, installing, updating, securing, restarting at 3am. You get the most control, and in exchange you take on every chore of running the machine short of owning it.

The hosting spectrum, from least work to most controlFour tiles in a row. Serverless, pay per call. Managed, always-on with a steady bill. Container, you package it. Virtual machine, the whole box. A sage fill deepens left to right as you take on more of the machine. An arrow above reads more control of the machine; an arrow below reads more of it is your job. The first two tiles sit inside a start here band.MORE CONTROL OF THE MACHINESERVERLESSpay per callMANAGEDalways-on, steady billCONTAINERyou package itVMthe whole boxMORE OF IT IS YOUR JOBSTART HEREFurther right is more control and more upkeep. Most builds start on the left.Starting on a VM in 2026 takes a specific reason.

At this level your builds will be happiest on the left: serverless when traffic is small or comes in bursts, managed when you want an always-on machine and a predictable bill. Moving right later is routine, so starting on the left does not lock you into anything.

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 from the makers of Next.js, so tools that scaffold the default stack often propose both in the same breath. Render is a managed platform in the spectrum's middle, an always-on app with a URL and a steady bill. Cloudflare runs your code across a worldwide network of machines, close to whichever user asked. This site deploys there, and the free tier was the first page we read.

Underneath sit the general-purpose clouds from Amazon, Google, and Microsoft, which rent every kind on the spectrum; several friendlier platforms are themselves tenants selling convenience on top. You do not need a dashboard tour yet, only to recognize the names when a proposal arrives with one inside.

An AI product pays two separate bills

An AI feature adds a second rental, because the model does not run on your host. It runs on racks of machines built around GPUs, the specialized processors AI work requires, operated by the model's provider. You rent it indirectly, through an API, paying for tokens, the small pieces of text a model takes in and produces. Your backend, where the real work happens, holds the key, makes the call, and pays per request.

Your user, your app on a rented host, and the model behind an APIThree nodes from left to right: your user, your app on a rented computer called the host, and the model behind an API, which is rented intelligence. Solid arrows labeled request run from user to app and from app to model. Dashed arrows labeled response run back. Caption: two rentals, one product.YOUR USERRENTEDYOUR APPon a rented computer(the host)RENTEDTHE MODELbehind an API(rented intelligence)requestresponserequestresponseTwo rentals, one product.

The host bills for compute and traffic, the model provider bills for tokens, and the two add up on their own. Most confusion about what an AI product costs goes away once you can say, for any feature, which bill it lands on.

Running the model on hardware you rent yourself is technically possible, and nobody at this level should run their own GPU. Those machines are the most expensive line on any cloud's price list, and operating them well is a full-time job. Renting intelligence through an API is not a beginner compromise; it is how nearly every AI product you use is built.

A deploy moves your code onto the rental

A deploy puts your code on the rented computer. The save points you learned to make in Git: the undo that makes AI edits safe flow from your laptop to the platform, which builds the project, swaps the new version in, and from that moment serves your latest code. In practice it is one terminal command, or a platform shipping whatever lands in your shared repository. The first deploy feels like a ceremony; every later one takes less attention than sending an email, which is what makes shipping small changes routine.

Approve the hosting pick

This is the same move you ran for languages and frameworks, aimed at a new question. A tool that scaffolds your build usually proposes a host along with the framework, since the two travel together. Ask the tool to defend its proposal: the platform's name, where it sits on the spectrum, what the free tier covers, and what the first paid dollar buys. Then approve, 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 operates it, can outweigh the convenience of starting fresh.

If you cannot name your constraint in one sentence, go with the left edge.

Try it now

No setup: Open the pricing page of one platform named in this chapter and read it like rental terms: find the free tier and what it covers, then the first thing that costs money. Notice what gets metered, requests, bandwidth, or hours of compute, because the meter tells you which kind of rental this is. Finish the sentence "my build would start paying the month that ___ happens" and you have read the terms most first-time builders skip.

With your tools: In Claude Code, with your project open or your idea described in a sentence, ask where the build should live, requiring a specific platform, its spectrum tier, and a two-sentence defense. Push back once, asking what would have to be true for a different tier to win, and watch whether the defense holds. Then approve; you are rehearsing the approval, not deploying. In Codex or Cursor the move is the same: ask the sidebar chat where the build should live and make it defend the pick before you agree. If your machine has none of these tools yet, the Setup Clinic gets you running.

Chapter Summary

  • Hosting is renting a computer on the internet so your product keeps running when your laptop is closed.
  • The options differ only in how much of the machine you manage yourself: serverless runs your code on demand, managed platforms keep an always-on app with a steady bill, and containers and virtual machines trade more setup and upkeep for more control.
  • Start on the convenient left end, since moving right later is routine and the left locks you into nothing. Go further right only when you can name a specific reason to.
  • The names you will hear most are Vercel, Render, and Cloudflare, with the big general-purpose clouds underneath them.
  • An AI product pays two separate bills: one to the host that runs your app, and one to the model provider you reach through an API and pay for in tokens.
  • You almost never run the model yourself. Renting it through an API is how nearly every AI product is built.
  • A deploy moves your saved code from your laptop onto the rented computer. The first one feels like an event, and every later one is about as routine as sending an email.
  • Set a billing alert and a usage limit in the same sitting as your first deploy, so a runaway loop or a stray bot cannot run up a big bill while you sleep.
  • Next is Auth, who you are vs. what you can do, because once the rented computer answers anyone who finds it, you have to decide who it recognizes and what each person may do.

Sources

  • Vercel, Cloudflare, and Render public product and pricing documentation (2026).
Marks this chapter complete on your course map. Reaching the end does this for you.