What is hosting?

Status: 🟩 COMPLETE Last updated: 2026-06-19 Plain-English tagline: Renting a computer somewhere in the world that is always on, always connected to the internet, and configured to run your app for visitors.

In plain English

When you build a webapp on your laptop, you can visit it at an address like localhost:3000. That address means “the program running on my own computer.” Only your laptop can see it. The moment you close the laptop, the app stops.

To make the app visible to anyone else, the code needs to run on a different kind of computer — one that:

Is always on (24/7, never sleeps)
Has a constant connection to the public internet
Has a public address other computers can reach
Has enough power to handle real traffic
Is kept patched and secure, because anything on the public internet is constantly attacked

That always-on, always-connected, properly-configured computer is called a server. Hosting is the service of renting access to one of those servers from a company that owns thousands of them in big air-conditioned warehouses called data centers.

You don’t usually rent a whole physical machine. You rent a slice of one — sometimes a virtual machine, sometimes just “the right to run this code, we’ll figure out where” (that’s the modern serverless style). Either way, when someone types your URL into a browser, they reach the hosting company’s computers, which run your code and send back the page.

Why it matters

Hosting is the single thing that turns “code I wrote” into “a thing on the internet.” Everything else in the deploy pipeline — domains, SSL, CDNs, environment variables, regions — exists to make hosting work better.

It also represents one of the biggest shifts in software over the last 20 years. In 2005, “hosting” meant a few hundred dollars a month, a long-term contract, and a whole job title (sysadmin) to keep it running. In 2026, you can host a real production webapp for $0 (Vercel Hobby, Cloudflare Pages, Netlify free tier) and deploy it in under five minutes. That collapse in cost and friction is what makes “one person ships a product” possible.

Picking the right kind of hosting — and the right provider — sets the ceiling on how easy life gets later. The wrong choice doesn’t always block you, but it can add weeks of friction. The right choice fades into the background.

The four main hosting models

Modern hosting comes in four flavors, ordered from “you do everything” to “you do almost nothing”:

1. Bare metal / dedicated servers

You rent a whole physical machine. You install the operating system, the web server, the runtime, security patches — everything. Used for huge workloads with very specific performance needs. Almost no solo developers use this in 2026.

2. Virtual private servers (VPS) / IaaS

You rent a virtual computer running on a shared physical machine. Examples: AWS EC2, Google Compute Engine, DigitalOcean Droplets, Linode. You still install and configure everything, but you don’t have to deal with hardware. Cheap, flexible, full control — but also full responsibility for security, scaling, and reliability.

3. Platform as a Service (PaaS)

You give the provider your code; they run it. You don’t choose the operating system or manage the server. Examples: Heroku (the original PaaS), Render, Railway, Fly.io. You pick a runtime (Node.js, Python, etc.) and a size; the platform handles the rest.

4. Serverless / function hosting / managed platforms

You give the provider your code and it runs in response to specific events (web requests, queue messages, scheduled jobs). You don’t think about servers at all — not even sizes. Examples: Vercel, Netlify, Cloudflare Pages/Workers, AWS Lambda. Modern webapp hosting is mostly this.

Most solo developers and small teams in 2026 use option 4 (serverless platforms) for almost everything. Drop to option 3 when you need a long-running process (a websocket server, a queue worker). Drop to option 2 only for specific workloads (big batch jobs, GPU work, things with weird system dependencies). Option 1 is for specialists.

What “running” actually means

When someone visits your site, a real sequence of events happens on the hosting company’s hardware:

User types "example.com" in browser
        ↓
DNS converts "example.com" into an IP address
        ↓
Browser opens an HTTPS connection to that IP
        ↓
The hosting company's edge / load balancer receives it
        ↓
It routes to the right server (or wakes up a serverless function)
        ↓
Your code runs, builds an HTML response (or returns a cached one)
        ↓
The response travels back to the browser
        ↓
Browser renders the page

Everything in the middle is what hosting does for you. The more you go up the abstraction ladder (1 → 4), the more steps the platform handles automatically.

Static vs dynamic hosting

A separate axis from the four models above is whether your site is static or dynamic:

Type	What it means	Hosting demands
Static	Pure HTML/CSS/JS files. No server-side code at runtime. (Pre-built at build time, served as-is.)	Trivial. Any web server can do it. CDNs love it. Free tiers are generous.
Dynamic	Generates pages or responses per request, based on user, time, data. Needs a runtime.	Real CPU/memory. Cold starts, regions, scaling all matter.

A pure documentation site can be 100% static. A webapp like Bible Quest is dynamic (user-specific data, server-rendered pages, real authentication). Modern frameworks like Next.js blend the two — some pages static, some dynamic, the platform sorts it out.

Why this matters for hosting: Static hosting is closer to free, faster, and less likely to break. If a page doesn’t need to be dynamic, don’t make it dynamic.

A concrete example: hosting a Bible Quest

Here’s how the Bible Quest project’s hosting actually works:

Vercel hosts the Next.js code. When you push to main, Vercel builds it and serves it from data centers around the world. Functions run in syd1 (Sydney) so they’re close to the database.
Supabase hosts the database (Postgres). Supabase is its own hosting service — they manage the database server, backups, and authentication.
Vercel Domains hosts the DNS records for stmarkbible.com. So when someone types the URL, DNS sends them to Vercel’s edge, which serves the page.
Vercel’s built-in CDN caches static assets (images, JS bundles) at edge locations worldwide.

George doesn’t run a single server. He pushes code to GitHub; the rest is rented services that talk to each other.

How pricing usually works

Hosting prices are usually a mix of:

A fixed monthly base fee (or $0 for free tiers)
Bandwidth — how much data you send to users (per GB)
Compute — how much CPU time your functions burn (per GB-second, or per request)
Storage — how much data sits on disk (per GB-month)
Extras — custom domains, password protection, team seats, advanced features

For small projects, the free tier is often genuinely enough. Bible Quest runs on Vercel’s free tier and Supabase’s free tier — zero monthly cost. The trap is the day traffic spikes (you go viral, or get attacked) and bandwidth charges arrive unexpectedly. Set spending caps where the provider supports them.

Common gotchas

Free tiers often forbid commercial use. Vercel Hobby is non-commercial only. Cloudflare’s free Workers tier has no such restriction but has its own limits. Read the terms before you take a single dollar.
Cold starts can ruin perceived speed. Serverless functions that haven’t been used in a while need to “warm up,” which can add 200–2000ms to the first request. Modern platforms (Vercel Fluid Compute, AWS Lambda SnapStart, Cloudflare Workers) have largely solved this for typical workloads, but it can still bite you if your code has heavy initialization.
“Region” matters more than you think. If your hosting is in Virginia and your database is in Sydney, every database call crosses the Pacific. Latency adds up fast. Co-locate your compute and your database.
Bandwidth costs are the silent budget killer. A single viral moment, an image embed that goes wild, or a poorly-configured cron job can rack up serious bandwidth bills. Use a CDN, set caching headers, and consider providers (like Cloudflare) that don’t charge for bandwidth.
“Always on” doesn’t mean “never down.” Even AWS goes down. Your hosting provider’s uptime SLA is typically 99.9% (about 8.7 hours of downtime per year). Status pages exist for a reason — bookmark your provider’s.
Domain renewals are easy to miss. A domain and the hosting that lives behind it are usually separate billing entities. If your domain auto-renew fails (expired card), your site goes dark even though the hosting is fine.
Free tier soft limits often turn into hard limits silently. A Hobby project hitting bandwidth limits might just start serving errors with no warning email. Know where your dashboard’s usage page lives.
DDoS and abuse can rack up huge bills. Without protection, an attacker can hit your serverless function a million times and you pay for every invocation. Use providers with built-in DDoS protection (Cloudflare, Vercel) or set request-rate caps.
“It works on localhost” is not proof. Your local environment has different env vars, different file paths (case sensitivity!), different network conditions. Always test against the deployed environment before relying on a feature.
Vendor lock-in is real even on “standard” platforms. Vercel-specific features (image optimization, server actions, ISR) are deeply integrated with Next.js but won’t move cleanly to another host. Migration is rarely impossible, but it’s never free.
Hosting and the database are separate concerns. Many people conflate them — “I’m hosted on Vercel” — but Vercel doesn’t host your database. Supabase does. Knowing what runs where is essential for debugging.
A static site is dramatically cheaper, faster, and more reliable than a dynamic one. If your site doesn’t need to be dynamic, don’t make it dynamic. The serverless function you don’t write is the one that never breaks.
Auto-scaling is not magic. It scales by spinning up more copies of your function — which all hit your database simultaneously. The bottleneck moves; it doesn’t disappear. Database pooling and rate limits matter.
Don’t host secrets in your repo. Even private repos. Use environment variables. (See environment-variables.md.)
The cheapest hosting that meets your needs is the right hosting. Don’t over-engineer for scale you don’t have. Start on a free tier. Move up when you actually hit a wall.

When you might NOT want managed hosting

Most of the time, “use Vercel” or “use Cloudflare” is the right answer. But there are real cases where you want to drop down to a VPS or run your own:

Long-running processes. A websocket server that holds connections open. A queue worker that processes jobs continuously. Serverless functions time out (10–800s); these don’t fit.
GPU-heavy work. Training models, running diffusion, real-time AI inference at scale. Need specialized hardware.
Unusual system dependencies. A binary that needs custom system libraries, FFmpeg with specific codecs, ImageMagick with specific delegates.
Compliance / data residency. Some regulations require data never to leave a specific country, on hardware you control.
Cost at scale. At certain traffic volumes, raw VPS hosting becomes dramatically cheaper than serverless billing. (Mostly relevant above tens of millions of requests/month.)

For the kinds of projects George builds — webapps, content sites, AI-assisted tools — managed serverless hosting is the right default forever.

Sources

Cloudflare — What is web hosting? — clear vendor-neutral primer
Vercel docs — Deployments overview
AWS — Types of hosting — the full spectrum from IaaS to SaaS
DigitalOcean — Hosting basics

Tech & AI, Explained

Explorer

what-is-hosting