DSA & System Design
All the parts

Build · Run it

Hosting

Where does my app's code actually run?

What it is

Your code needs a computer that is always on and reachable from the internet. Hosting is renting that computer. Some hosts run your code only while a request is being handled (serverless), some keep a program running all day (a server or container), and you pick how much of the setup you do yourself.

It is renting a shop: a pop-up stall costs little and needs no upkeep, while a full building is yours to fix, but you can do anything in it.

Add it when You want anyone other than you to open your app from a link.

It can wait when You are still building and a local dev server on your laptop is enough.

1 Which one should I pick?

Answer what you can. The ranking updates as you go, and you can ignore it if you disagree.

What does your app do?
How much of the server do you want to manage?
What matters most right now?

Most people start with

2 Side by side

Three pips is strong, one is weak. Pick a row to read about it below.

OptionQuick to set upCheap while smallEasy to leaveRoom to growPrice
Free tier for hobby use, then per seat and per use
Small free or trial plan, then pay for what runs
Pay per hour or month for the machine
Free allowance each month, then pay per request and run time
Pay for the compute and load balancer you run

3 Look closer, then wire it in

Managed service

Vercel

Push to Git and your Next.js app is live, with serverless and edge functions.

Pick it when You build with Next.js and want deploys, preview links and HTTPS with no server work.

Skip it if You need long-running jobs, always-open connections or a bill you can predict under heavy traffic.

  • Deploys on every Git push, with a preview link per branch
  • Made by the Next.js team, so features work first
  • No servers to patch
  • Functions are short-lived, so long tasks do not fit
  • Cost can jump when traffic grows
  • Some lock-in to its platform features
Quick to set up
Cheap while small
Easy to leave
Room to grow

PriceFree tier for hobby use, then per seat and per use

How to connect it

  1. Push your project to GitHub.
  2. Import the repository in the Vercel dashboard.
  3. Add your environment variables under project settings.
  4. Deploy, then attach your own domain if you have one.
Put these in your .env file
  • DATABASE_URL
  • NEXT_PUBLIC_APP_URL
terminal
npm i -g vercel
vercel login
vercel          # first deploy, creates a preview link
vercel --prod   # ship to your real domain

4 Watch it work

Press play, or step through one message at a time.

Press Play to watch it run · 7 steps

You push code, the host builds it, and then visitors reach the running app.

A deploy and a first visitYou push code, the host builds it, and then visitors reach the running app.git pushTells the host about new codeInstall, build, start the new versionLive at your linkOpen your domainRun your code for this requestThe page
  • Client
  • External API
  • Service
Text description
  1. You → GitHub: git push
  2. GitHub sends (async) to Host: Tells the host about new code
  3. Host: Install, build, start the new version
  4. Host replies to You: Live at your link
  5. Visitor → Host: Open your domain
  6. Host: Run your code for this request
  7. Host replies to Visitor: The page

5 Mistakes to skip

  • Putting secret keys in the code you push to Git.

    Keep them in the host's environment variables and add .env to .gitignore.

  • Running a single server with no restart or backup.

    Use a process manager or a managed host, and take backups of anything you cannot recreate.

  • Saving uploaded files on the server's disk.

    Serverless and container disks are wiped on deploy. Use object storage instead.

See where it sits in a whole app

The stack builder draws your product with hosting in it and animates a request through it.

Open the stack builder

Works closely with