Hosting & Serving

What a Server Actually Is (Just a Computer Waiting)

A server is just a computer running code, waiting for someone to ask it for something. It sits there, listening. When a request arrives (someone types a URL, clicks a link, or an app makes an API call), the server processes the request and sends back a response.

Your laptop could be a server. If you ran a program that listened for incoming requests on a network port, congratulations, you're hosting a server. The difference between your laptop and a data center is scale, reliability, and the fact that data center machines run 24/7 with redundant power and cooling. But the concept is identical.

---

Netlify as a Filing Cabinet: Serving Files

When you deploy to Netlify, you're uploading a folder of files (HTML, CSS, JavaScript, images). Netlify stores those files across a global network of servers called a CDN (Content Delivery Network). When someone visits your URL, Netlify finds the file and hands it over. No code runs. No database queries. No logic.

It's like a librarian. You walk in and say "I need the book on shelf 3, row 2." The librarian walks over, grabs the book, and gives it to you. The librarian doesn't write the book. Doesn't customize it for you. Just fetches what's already there.

This is incredibly fast and cheap. There's nothing to break, nothing to compute. The files exist; Netlify serves them.

---

Cloud Run as a Chef: Cooking on Demand

Cloud Run works differently. When a request arrives, Cloud Run wakes up a container (more on that in a moment), runs your code, sends back the response, and goes back to sleep. It's like a restaurant kitchen that only fires up the stove when an order comes in, then turns everything off between orders.

This is what people mean by serverless. Not that there's no server (there obviously is). But you don't manage it. You don't rent it monthly. You don't keep it running when nobody's using it. The cloud provider handles the hardware, the operating system, the scaling. You just write the function and deploy it. The provider figures out where to run it.

The trade-off: the first request after a period of inactivity takes longer because the container needs to "wake up." This is called a cold start. Subsequent requests are fast because the container stays warm for a while.

---

Serverless vs. Traditional: Uber vs. Owning a Car

The difference between serverless and traditional hosting is like the difference between using Uber and owning a car.

Traditional (always-on server): You rent a server. It runs 24/7, whether anyone's using it or not. You're responsible for maintaining it: software updates, security patches, scaling it up if traffic spikes. Like owning a car: always available, always your responsibility, always costing you money even when parked.

Serverless: The cloud provider manages everything. Your code runs only when needed, and you pay only for the time it's actually executing. Like Uber: you request a ride when you need it, someone else maintains the vehicle, and you pay per trip. If you don't go anywhere, you don't pay.

Most modern web apps use serverless. It's simpler, cheaper for variable workloads, and removes an entire category of maintenance headaches.

---

Containers: Shipping Containers for Code

A container is everything your code needs to run, packed into one portable box: the runtime, libraries, configuration files, and the code itself. Think of a literal shipping container. It doesn't matter what's inside; the container is a standard size and shape that fits on any truck, ship, or train.

Same idea. A Docker container holding a Python app will run identically on your laptop, on Cloud Run, or on Amazon's servers. The container isolates your code from the outside world, so it doesn't care what machine it's running on.

This solves the classic "it works on my machine" problem. If it runs in the container, it runs everywhere the container runs.

Docker is the most common tool for building containers. A Dockerfile is the recipe: "start with Python 3.11, install these libraries, copy my code in, and run this command when you start." Cloud Run, AWS, Azure, they all run Docker containers.

---

Hosting in Practice: A Tour

Here's how three different types of tools might get hosted:

An analytics dashboard (Cloud Run, dynamic). When you visit the dashboard URL, Cloud Run wakes up a container running Next.js. The app queries a database for the latest data and hits an analytics API for live usage numbers. It assembles a fresh page with current data and sends it to your browser. If nobody visits for a while, the container goes back to sleep.

A documentation site (Netlify, static). Pre-built HTML files sitting on Netlify's CDN. When you visit, Netlify finds the file and sends it. No code runs. No container wakes up. No database queries. Just files being served.

An automated daily briefing (Cloud Run, scheduled). Nobody "visits" this service. A cloud scheduler triggers it every weekday morning. Cloud Run wakes up, the Python code pulls data from a CRM and email system, an AI model generates the briefing, and the service sends an email. Then it goes back to sleep until tomorrow. No browser involved.

---

Further Reading