Hosting a website costs pocket change (or even nothing at all). Hosting a web app is where the fun begins — and this series is about understanding that difference before your first invoice does it for you.
This series is written for developers who want to run their own website, launch a small product, or simply understand what happens between git push and a user seeing a page. I'll go from concepts anyone can follow to the production details I've learned configuring these things for real.
Domain — why do you need one?
Imagine you have a small frontend project you've spun up to learn a new framework. The local development server won't let you show this website to your friend, because it's running only on your machine.
So how do you put up a sign on the internet, so your friend can find the files your computer is hosting?
This is where the concept of a domain comes into play. A domain is your "place" on the internet — one you build and maintain. Just like in real life — you get a piece of land (the domain) and you build your house (the website) on it.
The domain is actually just one piece of the full address your friend will type. Take the whole thing apart and every part has its own job:
How to talk once you arrive. HTTP is the language of the conversation between browser and server; the extra S means the conversation is encrypted, so nobody along the way can read it.
Where to go — the human-readable name of your place on the internet. Browsers can't use it directly: DNS first translates it into an IP address.
Which door to knock on. One machine can run many listening programs, each behind its own numbered door. You rarely see this part — browsers silently assume 80 for http and 443 for https.
What to ask for once someone opens the door — which file or resource you want. Leaving it empty means 'whatever lives at the root', which is usually index.html anyway.
💡 Tap a part of the address to see the job it does.
Don't worry if the port and path parts feel abstract for now — both will come back in a moment.
OK, now we have our land/domain (let's assume it is my-internet-land.com), but when anyone — your friend included — types this address in the browser, how does the browser know where to go?
DNS — the Domain Name System
To solve this problem, we need DNS (the Domain Name System). DNS is a system of servers that translates human-readable domain names (like my-internet-land.com) into IP addresses that computers use to identify each other on the network.
When someone types my-internet-land.com into their browser, the browser — on their behalf — asks a DNS server to translate this name into an IP address.
An old neighbor calls: apparently you left a box of your stuff at his place years ago, and he would like his garage back. Instead of a proper address, he gives you the name his family has always used —
my beloved home on oak street— and says that in your town there is this guy (the DNS server) who knows where everyone lives, so you can just ask him. You do, and the answer comes:my beloved home on oak streetis actuallyNew York, Oak Street 12(note: you haven't visited the neighbor yet — you only know where to go!).
With the actual IP address, the browser knows where to go, but how does it know what to do when it gets there? How does it know what files to ask for?
Who picks up at that IP address? The web server
Let's start with a simplified example. How does your local development server work? It all begins with the concept of the sender and receiver.
A local development server is a special type of program that listens (the receiver) for anyone who wants something from one of your computer's ports.
NOTE
It needs to be configured to listen on a specific port. This port is reserved (while your server is running) for the development server. No other programs should be able to use it. You can also think of it as a "door" to your computer that is open for the development server to receive requests.
When you type localhost:3000 in your browser, it (the sender) sends a special message (request) to your local development server, which responds with the appropriate files (HTML, CSS, JavaScript, etc.) that make up your website.
TIP
localhost is just an alias for the IP address 127.0.0.1 for IPv4 (or ::1 for IPv6). It is a loopback address that allows your computer to communicate directly with itself without sending traffic over a physical network.
Here's the whole round trip in one picture:
The browser asks a DNS server to translate the human-readable name into an IP address. This lookup usually happens once and gets cached — next visits skip straight to asking the server.
The answer is an IP address (plus a port, if it's not the default 80/443). Note that the browser still hasn't visited the site — it only knows where to knock.
Now the real visit: an HTTP request to the program listening at that address and port. GET / means 'hand me whatever lives at the root path' — usually the index.html file.
The server answers with a status code and content. The browser reads the HTML, discovers it needs CSS, JavaScript, and images, and fires a separate GET for each one.
With all files in hand, the browser builds the page you actually see. The whole chain — DNS, requests, rendering — usually fits well under a second.
💡 Tap a step to see what really happens there.
Now that you understand local development, it would be natural to think that the same process happens when you type a domain name in your browser. The difference is that instead of your local development server, the request is sent to a web server that is running on a remote computer somewhere on the internet. Note that running a web server open to the public is a different thing — it requires configuration and security considerations (about that later in the series).
Back to the neighbor story: you finally arrive at Oak Street 12 — and it turns out to be a whole apartment building. Fortunately, the address you got had one more detail: the apartment number, 3000 (that's the port from the URL, coming back as promised). At the door, about to ring the doorbell, you remember that the neighbor's household has always spoken its own special language (HTTP) — and you'll need it to get anything from him.
Do you remember how to start?
GET /index.html — how browsers ask for files
HTTP is a surprisingly simple language. Every sentence has the same shape: a verb, a path, and some details. The browser says GET /index.html — which translates to "please hand me the file that lives at this path" — and the server answers with a status code and, if all goes well, the file itself.
In the story: you knock and say
GET /the-box-of-stuff-i-left-here(the path!). The neighbor disappears for a moment and comes back either with the box (200 OK) or with an apologetic shrug (404 Not Found— "never seen it, are you sure you left it at my place?").
One request is rarely the end of the conversation. The browser opens index.html, discovers it references a stylesheet, some JavaScript, and a few images — and politely fires a separate GET for each one. A single page visit is really a burst of small requests, and the server answers each one:
The first request of the visit. The browser reads this HTML file and discovers everything else the page needs — which triggers the requests below.
Referenced by the HTML: how the page should look. Without it you'd get honest-but-ugly 1995 vibes.
Also referenced by the HTML: the interactive parts. Every script is its own request.
Images too — each one a separate request. A picture-heavy page can easily mean dozens of these.
The apologetic shrug: the server is alive and listening, but nothing lives at that path. Every broken link on the internet ends with this exact answer.
💡 Tap a line for the story behind it.
NOTE
GET is just one of the HTTP verbs. There is also POST (here, take this data), PUT, DELETE, and a few others. For a website built of files, GET does almost all the work — the other verbs become important the moment your project starts accepting data instead of only serving it. Remember this detail; it will come back when we talk about web apps.
And with that, the whole chain finally works end to end: domain → DNS → IP address and port → a server that speaks HTTP → files fetched to the visitor's browser → the browser renders them as a webpage. Congratulations, you technically know how the web works.
There is just one small problem: every link of that chain ends at your computer. What happens when you close the lid?
Your laptop would hate this job
Nothing stops you from serving your website straight from your own machine. People genuinely do this: a bit of router configuration (port forwarding), a service that keeps your domain pointed at your home connection (dynamic DNS), and your laptop is a real, public web server. For an afternoon, it even feels great.
But, the more you think about it, the more you realize that your laptop is not built for this job:
- The server must never sleep. No lid closing, no reboots, no "Windows decided to update at 3 AM". Your laptop uptime is your site uptime.
- Your home IP address is not really yours. Providers own a limited pool of addresses and shuffle them between customers as needed, so the one you have today may belong to your neighbor tomorrow. Every time it changes, your domain silently starts pointing at the wrong machine — and nobody will tell you.
- The whole internet knows your door exists. Within hours of opening a port, automated bots will start rattling the handle, trying default passwords and known exploits. Not personal — just the weather out there.
- Your upload bandwidth becomes the product. Home connections are built for downloading; a few visitors streaming your images can saturate the direction you never think about.
None of this is impossible to manage. It is just a full-time janitorial job that has nothing to do with the website you wanted to show your friend.
The moment you decide you don't want that job — and you shouldn't — is the moment hosting is born.
What does "hosting" actually mean?
Hosting is renting a place on the internet where your code and files live — on someone else's computers, the kind that never sleep, keep their IP addresses, and have a team watching them — wired up so that anyone typing your address gets an answer. For a simple website, that's genuinely all there is to it.
The complexity doesn't come from hosting itself. It comes from what you are hosting.
Static sites vs web apps: the first fork in the road
Everything we've traced so far — the files, the GETs, the server handing things over — describes a static site: a folder of files that a server hands to your browser, and the browser displays them. A web app is a running system that computes answers, remembers users and the data they've uploaded, and maybe even takes payments. The difference is subtle in words, but enormous in practice.
This single distinction decides most of your hosting choices: price, providers, failure modes, and how much of this series you actually need. If your project is a portfolio or a blog, you can host it for free and be done. The moment users log in or pay, you've crossed into app territory — and app territory has layers.
The layers of a web app
A standard web app splits into three layers, and each one can be hosted separately, with its own tools and its own pricing model:
What the user sees and clicks.
The presentation layer: HTML, CSS, and JavaScript delivered to the browser. It can be plain files generated ahead of time (the static-site case) or rendered per request on a server.
The business logic answering requests.
The layer that computes answers: validates input, applies rules, talks to the database, calls other services. It is also the layer with the most hosting options — which is a problem, not a luxury.
Data that must survive restarts and deploys.
Databases, file storage, caches. The only layer you cannot redeploy your way out of: code is replaceable, your users' data is not. Backups belong here from day one.
UI — What the user sees and clicks.
Backend / API — The business logic answering requests.
Persistence — Data that must survive restarts and deploys.
💡 Hover over/tap a layer to see extra deatils.
Each layer gets its own dedicated part in this series, with concrete options and honest trade-offs.
Everything around the layers
The layers are the app. What makes it a product is the operational work around them — and in today's world that's not optional homework. I group it into four pillars:
Getting code from your laptop to production, repeatably.
- CI/CD pipelines — every merge builds, tests, and deploys itself — no 'deploy guy'
- Automated tests — the gate that keeps broken code out of the pipeline
- Infrastructure as code — Terraform and friends: your servers described in files, not in memory
💡 Learn more about the pillars by clicking on them.
CI/CD, automated tests, infrastructure as code (Terraform), secrets, auth, payment gateways, AI agents, domains, certificates, HTTP quirks, logs, tracing, monitoring — every one of these lives in exactly one pillar, and every pillar gets a deep-dive part later in the series.
What this series covers
The plan, from general to specific:
- Where to host a website or web app — the hosting options by budget, what each one costs, and why an app is never just one thing to host.
- Hosting the UI layer — static hosting, CDNs, SSG/SSR/edge, and when "static" stops being enough.
- Hosting the backend/API layer — PaaS vs serverless vs containers vs VPS.
- Hosting the persistence layer — managed databases, object storage, and backup discipline.
- The pillars — shipping, securing, running, and watching your app in production.
Alongside the series I'm planning standalone step-by-step walkthroughs — hosting a real static site and a real app on AWS — so you can see every concept done for real, screenshots and invoices included.