Everything you've built runs on your laptop, and your laptop closes. The dev server dies when the lid shuts, and localhost:3000 is an address only you can visit — your app, however capable, is one closed lid away from not existing. For an app to be real — visitable by other humans, at an address, at 3 a.m. — it has to live on computers that never close. That's hosting, it's the last piece of the infrastructure map, and the governing principle is one you've already absorbed twice in this section: you rent it, you don't build it. Nobody stacks servers in a closet anymore, the same way you didn't run your own database or write your own auth. "The cloud" is, with minimal loss of accuracy, other people's computers, rented by the slice — and your job is knowing which slice fits which piece of your app.
The menu
Static hosting — for pure frontends. Remember the build-step arc: npm run build produces dist, a folder of plain files, and "deploying is mostly putting dist on a server." Static hosts are that server: they do nothing but hand out files, which makes them cheap (usually free at hobby scale), absurdly fast, and nearly impossible to take down — there's no process to crash, just files being served. Netlify, Vercel, GitHub Pages, and Cloudflare Pages all live in this business, and for an app with no backend of its own, they're a wonderful deal: connect your GitHub repo, tell it the build command, and every push builds and ships automatically. The catch is right in the name: static hosts serve files. They cannot run your Express server, glance at wristbands, or hold a secret — no process, remember. Your apps have backends now, which is why the menu continues.
Server hosting — for backends that need to run forever, and this is where this course lives. Your Express app is a program that starts and refuses to end, so somewhere a computer has to keep Node running around the clock. The approachable version is a platform-as-a-service, where the deal is "connect your repo; we'll run it, restart it when it crashes, and hand you a URL." Render is our pick and where your capstone will live, and the reason is the thing this audience should prize above all: one landlord. Render runs your Node app and rents you a Postgres database in the same dashboard — app and database side by side, connection string wired between them, one signup, one place to look when something's wrong. Your server can even hand out your built frontend itself (one line of Express serves the dist folder), which means an entire real application — frontend, API, database — can live under a single roof. Railway and Fly.io are respectable neighbors in this business; below all of them sits renting a raw machine (a VPS) that you administer yourself, which buys control at the price of becoming your own 3 a.m. pager — file under "exists, not yet."
Cost honesty, because hosting is where free stops being the default: Render's free tier will run your app, with the quirk that a free server naps after fifteen-ish idle minutes and takes a long moment to wake for its next visitor — fine for a portfolio piece, explainable in one sentence. The database is the part that costs: Render's free Postgres is a thirty-day trial before it expires, and keeping one is in the several-dollars-a-month range. Which is the honest headline about shipping software: running something real costs about a coffee a month, and that's the whole price of being real. (If a permanently free database matters to you, managed-Postgres providers with genuine free tiers exist — Neon is a good one, and in the spirit of disclosing my database entanglements: I used to work there too — at the cost of a second landlord holding your data. The pattern is identical either way: a DATABASE_URL in the environment.)
The hyperscalers — one more tier on the menu, because you've absolutely heard these names: AWS, Azure, Google Cloud. These are the giants of the renting-computers business, and they sit at the opposite end of the trade from Render: less focused on making things easy, more focused on offering everything — hundreds of services, every scale from hobby to planet, and pricing that rewards knowing exactly what you're doing. This is where most of the world's serious software actually runs, it's where you'll likely land if something you build genuinely takes off, and — a fun fact that snaps the whole market into focus — many of the boutique platforms are themselves built on the hyperscalers. The friendly landlord is often renting from a bigger landlord and reselling the space with better furniture. That's not a scam; that's the business — you're paying the boutique to make hyperscaler-grade infrastructure not require a hyperscaler-grade education. For this course and probably your next several projects, the boutique tier is the right call; just know the giants are underneath, and that "we should move to AWS/Azure" is a sentence that means "we've gotten big enough to trade convenience for control and cost."
Serverless functions — the interesting middle, and here's a reveal to make it concrete: the pets API you've been calling all course is one. There is no server of mine humming in a rack waiting for your requests. The pets API is a Cloudflare Worker — a handler function, deployed to Cloudflare, which summons it into existence when a request arrives, runs it, and puts it away. That's serverless: you write route handlers — just the rooms, no hallway-and-building — and the platform conjures a server around them per-request. No always-on process to pay for or babysit, scales from zero to a pile of traffic without your involvement, and it is exactly the right shape for the pattern from the secrets lesson: a thin route that holds a key and proxies to a real service. Most platforms offer a flavor of these, and "static frontend plus a couple of serverless functions" is a legitimate sweet spot for apps that are mostly frontend with a secret or two to keep. Your apps have grown past that shape — a real Express backend with sessions and a database wants a real running process — but recognize the pattern when you meet it, because plenty of generated projects use it.
Everything platforms — and here's the bookend this course owes you. Replit is this entire lesson in one product. The editor, the running server, the database, the deployment, the URL your friends could visit — bundled, invisible, handled. When your app "just worked" there at the very start, all of the machinery in this section was working on your behalf behind the curtain: hosting, environments, a database, deploys. That's neither a criticism nor a graduation — it's the point this course has made from the beginning about tools: Replit made a bundle of decisions for you so you could ship on day one, and now you can see each decision individually, which means you can also now choose differently, piece by piece, when a project calls for it. Different tools for different problems, with open eyes.
Every rented service, one anatomy
Hosting is one aisle of a much bigger store. Real apps rent everything: file storage for user uploads (S3, R2), email sending (Resend, SendGrid), payments (Stripe), and the two you've already met — managed databases and rented auth. Here's the thing that makes the whole ecosystem readable at once: every one of these services has the same anatomy. An npm package (a dependency in the manifest), a credential in an environment variable (never in code — you know the doctrine), and dotted calls that read like sentences: stripe.charges.create(...), resend.emails.send(...) — go inside the service, grab the verb, press the do-it button, await it (it's the internet; of course it's async). When your agent adds "email your users a receipt" to an app, you already know what the diff will contain: one manifest line, one env var, one dotted-and-awaited sentence in a route handler. Read one rented service and you've read them all — the nouns change; the anatomy never does.
"Works on my laptop" versus deployed
Last idea, and it names something you're about to live: your app now exists in environments — local (your laptop: the dev server, the .env file with its DATABASE_URL) and production (the rented computers: the built files, the platform's env-var settings screen, whatever database lives out there). Deploying means getting all three of an app's movable parts — the code, the secrets, the data — present and correct in the production environment, and most deployment pain is exactly one of those three not making the trip: the code shipped but the env var wasn't entered in the settings screen; the frontend deployed to one place and still fetches localhost:3000, an address that means "this very machine" and therefore points at the visitor's machine out in the world. And the parts don't necessarily all live together: plenty of real apps are a static frontend with one host, a backend with another, and a database rented from a third — one app, three landlords, connected by URLs and credentials. (Your capstone will take the opposite arrangement — everything under Render's one roof — precisely because fewer landlords means fewer places for a move to go wrong.) When something works locally and fails deployed, the diagnosis begins with the inventory: which of the three parts didn't arrive?
🤖 Ask your AI Assistant. The pre-deployment interview, which is about to become extremely relevant: point it at any of your apps — the React pet tinder is perfect — and ask "If I wanted to deploy this for real people, list every piece of it, where each piece should live, and every environment variable or credential that would need to move." Read the answer as an inventory against this lesson's menu: a pure frontend goes to a static host, a server goes to a platform like Render (where it can serve the frontend too), a database gets hosted — which yours already is, because you started on rented Postgres; deployment just means the production app gets its own
DATABASE_URL. You're rehearsing the exact conversation you'll have before the capstone ships — and practicing reading a deployment plan, which is a genre of agent output you'll be reviewing for the rest of your building life.
Recap
- Apps become real by living on computers that never close, and the rule is the section's refrain: rent, don't build. The cloud is other people's computers, by the slice.
- The menu: static hosts serve files (pure frontends; free-ish; can't run a process), server platforms run your backend forever — Render is our pick and the capstone's home: app, Postgres, and even your built frontend under one roof, one landlord — serverless functions conjure a handler per-request (the pets API was one all along — a Cloudflare Worker), and everything-platforms like Replit bundle the whole lesson into one product. Now you can see the bundle's contents.
- Real hosting costs about a coffee a month once a database is involved; a free-tier server naps between visitors. Both are honest prices for being real. Free-forever managed Postgres exists (Neon) at the cost of a second landlord.
- The hyperscalers (AWS, Azure, Google Cloud) trade ease for completeness, scale, and cost control — and many boutique platforms are built on top of them. Moving there is what "we got big" looks like.
- Every rented service shares one anatomy: a package in the manifest, a credential in the environment, dotted-and-awaited sentences in the code. Read one, read them all.
- Local and production are different environments; deploying moves code, secrets, and data. When deployed behavior differs from local, inventory which of the three didn't make the trip — and remember
localhostin shipped frontend code points at the visitor's machine.
Next: the section's project — the pet app gets users, logins, and a memory that survives anything.
