Hosting, renting a computer on the internet

AI asks: Serverless, container, or VM?

This is, in caricature, the question that broke our neighbor the scientist. It is also the question every PM, marketer, and ops lead I have ever taught has frozen on, because the three answers all sound like they are the same thing, but technically slightly different, and you can sense from the AI's tone that it really does want a specific answer.

Here it is, in 90 seconds, and then we go deeper.

• Serverless is best for most of what people in this course will build.
• Container is best if you have something more complex or you want more control.
• VM (virtual machine) is best if you have specific software that needs a specific environment and the convenience of a serverless or container provider would get in the way.

If you do not know which you have, pick serverless. Worst case, you change later. Day 18 will revisit this in the context of your own build.

OK, the long version.

What "hosting" actually means

Hosting means renting a computer connected to the internet to run your backend on.

You are, in a real sense, renting a small fraction of a physical building full of computers in Virginia or Oregon or Frankfurt or Tokyo. The differences between hosting options are mostly differences in how much of the renting and the maintenance you have to think about.

The four shapes, in order from least to most you have to think about

Serverless. You write your code, you upload it, you pay only when someone calls it. You do not think about which computer it runs on, how many computers it runs on, or whether the computer is on right now. Examples: Vercel, AWS Lambda, Cloudflare Workers. The name is misleading; there are servers, you just do not see them.

Managed service (Platform-as-a-Service). You write your code, you upload it, the provider runs it on always-on computers and gives you a URL. Examples: Heroku (historically), Render, Fly.io, Railway. You pay a steady monthly amount and you do not have to think about scaling much until you grow a lot.

Container. You package your code with everything it needs (operating system level), and you hand the package to a provider who runs it on computers they manage. Examples: AWS ECS, Google Cloud Run, Kubernetes (which is overkill for almost everything). You think about more, you pay differently, you have more control.

VM (virtual machine). You rent a slice of a physical computer, with a full operating system you control. You install your stuff. You manage updates and security. Examples: AWS EC2, DigitalOcean Droplets, Linode. You think about everything. You pay either way.

The further down this list, the more flexibility you have, and the more responsibility comes with it. For almost everything you will build in Week 3, serverless or managed are the right answers.

How to answer "serverless, container, or VM"

Three tests, in order.

Does my code need a specific operating system or low-level setup? If yes, container or VM.

Will I be running steady traffic 24/7, or bursty traffic with quiet periods? Steady: managed. Bursty or unpredictable: serverless.

Am I more worried about hitting the limits of a managed service later, or about over-engineering today? If over-engineering, managed or serverless. If limits, container, but plan to start simple anyway.

For most builds: serverless if your traffic will be small or unpredictable, managed if you want a steady, predictable bill, and you can graduate to containers later if you actually need to. Almost nobody starts with a VM in 2026 unless they have a specific reason.

A small vocabulary sweep

• Deploy. Push a copy of your code from your laptop (or your CI system) to the hosting provider, so it starts serving real users.
• Cold start. The delay when a serverless function has not run in a while and the provider has to start it up. Usually a few hundred milliseconds, occasionally annoying.
• Scale. How well the system handles more traffic. "Scales horizontally" means adding more copies of the server. "Scales vertically" means making the existing server bigger.
• Region. Which physical data center your code runs in. Useful to pick a region close to your users.
• CDN (content delivery network). A layer in front of your hosting that caches static content (images, CSS) close to users around the world. Most hosting providers include one.

Forward references

Day 13 covers who is allowed to access this hosted code. Day 14 covers how you find out when it is broken. Day 19 returns to the billing alert and four other guardrails experienced builders learned the hard way.

Day 12 wrap

The thing you can now say plainly. Hosting means renting a computer on the internet to run your backend on, and the four shapes (serverless, managed, container, VM) trade flexibility for responsibility in that order.

The thing you can now do. When AI asks "serverless, container, or VM," apply the three tests and pick a defensible default. Then set a billing alert before you click deploy.

The guardrail to remember. The 60-second billing alert setup is the difference between a $0 hobby and a $4,000 surprise. Do it before anything else.

See you on Day 13, where we figure out who is allowed in the door.