40  40. Hosting and Deployment: Getting Your App Online

An app running on localhost works only on your own computer. To share it, it has to run on a server that is always on and reachable from the Internet - that is hosting - and getting your code onto that server is deployment. This page compares the main kinds of hosting and walks through the push-to-deploy workflow most student projects use.

40.1 Development vs. production

  • Development (“dev”) is where you build: your laptop, localhost, test data, test keys (for example Stripe’s sandbox keys), detailed error messages, and a server that reloads when you save a file.
  • Production (“prod”) is the real, public version: real users, real data, real money. It must stay up, keep secrets safe, and run an optimized build.
Development Production
Address http://localhost:3000 https://your-app.vercel.app or your own domain
Started with npm run dev the host runs npm run build, then starts the app
Data test data real users’ data
Keys test keys in .env.local live keys in the host’s settings
Who sees errors you, in full detail users should see a friendly message

Deploying means building your app for production, copying it to the hosting service’s servers, and switching visitors to the new version. Many teams also have a preview (or “staging”) version in between: a private copy for testing changes before they go live.

40.2 Where to host: four kinds of services

Type What you get Examples Good for
Static hosting Your HTML, CSS and JavaScript files served from fast servers worldwide; no server code GitHub Pages, Netlify, Vercel, Cloudflare Portfolios, documentation, SSG sites, front-end-only apps
App platforms Your server code runs without you managing the machine: connect a Git repository and it builds and runs your app Vercel, Netlify, Render, Railway, Fly.io Full-stack apps (Next.js, Express, Django…)
Backend-as-a-service (BaaS) A ready-made back end - database, logins, file storage, server functions - used through APIs Supabase, Firebase Apps that need data and logins without writing a whole back end
Big cloud providers Hundreds of building blocks with maximum control - and complexity AWS, Google Cloud, Microsoft Azure Large or specialized systems; learning cloud skills

A common student setup, and the one in this book’s tutorial, combines two of these: the Next.js app (front end and server code) on an app platform such as Vercel, and the database and logins on Supabase.

40.2.1 Free options (checked October 6, 2026)

Free plans change often, so check each pricing page before you rely on one.

Service Free option Watch out for
GitHub Pages Free for public repositories Static files only; not allowed for running an online business or store
Vercel Free “Hobby” plan Personal, non-commercial use only
Netlify Free plan Usage is measured in monthly credits
Cloudflare Free Workers plan Limited daily usage for server code
Render Free instances Free web services sleep after 15 minutes without traffic (the next visit waits while they wake up); free databases expire after 30 days
Railway Free trial, then a small free plan Very limited resources
Fly.io Short free trial only No ongoing free tier: pay as you go
Supabase Free plan Free projects are paused after a week of inactivity
Firebase Free “Spark” plan Usage limits; some features need the paid plan
AWS, Google Cloud, Azure Trial credits plus some always-free services Complex billing - set budgets and alerts. Azure for Students offers credit with an academic email address

40.3 Deploying from GitHub

The most common workflow for app platforms and static hosts is push to deploy:

 your laptop            GitHub                 hosting service
 -----------            ------                 ---------------
 git push  -------->    repository  -------->  1. notices the new commit
                        updated                2. builds it (npm install, npm run build)
                                               3. deploys it
                                               4. live at https://your-app.vercel.app

The first time (the exact screens differ by service):

  1. Push your project to GitHub (see Putting Your Repository on GitHub).
  2. Sign in to the hosting service with your GitHub account and import the repository. It usually detects the framework and fills in the build command for you.
  3. Enter your environment variables (next section).
  4. Click Deploy and wait a minute or two. You get a public address such as https://club-events.vercel.app.

After that, every push to your main branch triggers a new production deployment automatically. Services such as Vercel and Netlify also build preview deployments, each with its own address - for pull requests, and on Vercel for every push to another branch - ideal for testing a change before merging it (see Branches and Merging).

If a build fails, it isn’t published: the live site keeps running the last successful version. Open the build log, find the first error, and fix it - pasting the log into Claude Code is a good way to get an explanation. Most platforms also let you roll back to an earlier deployment with a click.

40.4 Environment variables on the host

Your .env.local file is (correctly) not in Git, so the hosting service has never seen it. You must enter the same variable names - with production values - in the host’s project settings (usually Settings → Environment Variables). Hosts such as Vercel and Netlify let you give a variable different values for production and for previews, so that, for example, the live Stripe key is used only in production.

On many hosts (Vercel, for example), a changed variable takes effect only in the next deployment, so redeploy after changing one. And when an app “works on my machine but not in production”, a missing or misspelled environment variable on the host is the first suspect.

40.5 Custom domains and HTTPS

Hosting services give you a free address on their own domain, such as your-app.vercel.app, your-site.netlify.app or yourname.github.io. To use a domain you registered (see URLs, Domain Names, IP Addresses, and DNS):

  1. Add the domain in the host’s dashboard.
  2. The host shows you DNS records to create (usually an A record and/or a CNAME record); add them at your registrar.
  3. Wait for DNS to update - minutes to hours.

The major hosts then obtain and renew an HTTPS certificate for you automatically, often from Let’s Encrypt, a free certificate authority. You don’t have to do anything else to get the https:// address.

40.6 CI/CD in one paragraph

CI (continuous integration) means every push automatically runs checks - installing, building, running tests and linters - so problems are caught before code is merged. CD (continuous delivery or deployment) means code that passes the checks is automatically released. The push-to-deploy flow above is a simple CD pipeline. With GitHub Actions you can define your own steps in YAML files in your repository’s .github/workflows/ folder, for example “run the tests on every pull request”.

  • A virtual server (VPS or VM) is a whole computer you rent in a data center, such as an AWS EC2 instance, a DigitalOcean Droplet or a Hetzner server. You install and maintain everything yourself - operating system updates, security, the web server. Maximum control, maximum responsibility.
  • A container packages your app together with everything it needs (runtime, libraries, settings) so that it runs the same way on any machine - the cure for “it works on my machine”. Docker is the best-known tool: a Dockerfile is the recipe, and the result is an image that platforms such as Render, Railway, Fly.io and Google Cloud Run can run.
  • Serverless functions let you upload individual functions instead of a whole server. The platform runs each one on demand, scales automatically and bills per use. Examples: AWS Lambda, Vercel Functions, Netlify Functions, Supabase Edge Functions, Cloudflare Workers. “Serverless” still uses servers - you just never manage them.

Practice Questions

Easy

Question 1 · Short answer

What is the difference between development and production?

Development is where you build and test, usually on your own computer (localhost) with test data and test keys. Production is the real, public version that real users rely on, with real data, live keys and an optimized build, running on a hosting service.

Question 2 · Multiple choice

What does “deploying” an app mean?

  1. Writing the app’s code
  2. Building the app for production and putting it on servers where users can reach it
  3. Buying a domain name
  4. Running npm run dev on your laptop

b. Deployment builds the app, copies it to the hosting service and switches visitors to the new version. Writing code (a) comes first, a domain (c) is optional, and npm run dev (d) runs a development server only on your own computer.

Question 3 · Matching

Match each service with the kind of hosting it is best known for.

Service Kind
1. GitHub Pages A. Backend-as-a-service
2. Render B. Big cloud provider
3. Supabase C. Static hosting
4. AWS D. App platform

1 → C, 2 → D, 3 → A, 4 → B.

Question 4 · True or false

GitHub Pages can run a Node.js back end that saves sign-ups to a database.

False. GitHub Pages serves static files only (HTML, CSS, JavaScript, images). Server code needs an app platform, a backend-as-a-service or another kind of hosting.

Question 5 · Fill in the blank

CI stands for ______ and means ______. CD stands for ______.

CI = continuous integration: every push automatically runs checks such as building and testing. CD = continuous delivery (or deployment): code that passes the checks is released automatically.

Question 6 · True or false

As of October 2026, a small business may run its online store on Vercel’s free Hobby plan.

False. Vercel’s Hobby plan is for personal, non-commercial use. A business would need a paid plan (or another host). Always check the current terms, since free plans change.

Medium

Question 7 · Scenario

Maria’s app works perfectly with npm run dev. After deploying it to Vercel, the login page shows an error saying the Supabase URL is missing. What is the most likely cause, and how does she fix it?

Her environment variables live in .env.local, which is (correctly) not in Git, so Vercel never received them. She must add the same variables (for example the Supabase URL and publishable key) in the project’s Environment Variables settings on Vercel, then redeploy.

Question 8 · Ordering

Put the steps of a first deployment in order: (a) click Deploy, (b) push the project to GitHub, (c) enter the environment variables, (d) import the repository on the hosting service, (e) open the public address and test.

b → d → c → a → e.

Question 9 · Choose

Suggest a suitable kind of hosting for each: (a) a static portfolio site, (b) a Next.js app with logins and a database, (c) a small Python FastAPI back end.

  1. Static hosting such as GitHub Pages or Netlify. (b) An app platform such as Vercel or Netlify for the Next.js app, plus a backend-as-a-service such as Supabase for the database and logins.
  2. An app platform that runs Python servers, such as Render or Railway (or a container on a platform that runs containers).

Question 10 · Scenario

Sam changed an environment variable in his host’s dashboard, but the live site still uses the old value. Why, and what should he do?

On many hosts, environment variable changes apply only to new deployments; the running deployment was built with the old value. He should redeploy (trigger a new deployment, for example by pushing a commit or using the dashboard’s redeploy option).

Question 11 · Short answer

What is a preview deployment, and why is it useful?

A separate, automatically built copy of the app, with its own address, created for a branch or pull request (services such as Vercel and Netlify do this). It lets you and your teammates test a change on a real server before merging it into the main branch and releasing it to users.

Question 12 · Scenario

Sam pushes a commit and the build on his hosting service fails. Is his live site now down? What should he do next?

No - a failed build is not published, so the live site keeps running the last successful version. He should open the build log, find the first error message (and, if needed, paste the log into Claude Code for an explanation), fix the problem locally (for example run npm run build to reproduce it), then commit and push again.

Question 13 · Short answer

List the steps to put an app on your own domain with HTTPS.

  1. Register the domain with a registrar.
  2. Add the domain in the hosting service’s dashboard.
  3. Create the DNS records the host shows you (usually an A and/or CNAME record) at the registrar.
  4. Wait for DNS to update. The host then obtains and renews the HTTPS certificate automatically.

Hard

Question 14 · Scenario

Your team’s API runs on a free Render web service. During your class demo, the first request takes almost a minute, but later ones are fast. Explain, and give two ways to avoid it.

Free Render web services go to sleep after 15 minutes without traffic, and the next request has to wait while the service wakes up (as of October 2026). Options: open the app a few minutes before the demo to wake it up; move to a paid instance that stays on; or host on a service whose free plan doesn’t sleep in the same way. (Read the current free-plan limits before relying on any of them.)

Question 15 · Compare

Compare a virtual server, an app platform and serverless functions for a student team. Give one advantage and one disadvantage of each.

  • Virtual server: full control over everything; but you must install, update and secure the whole machine yourself.
  • App platform: push to deploy, little setup, HTTPS and scaling handled for you; but less control, and costs or limits set by the platform.
  • Serverless functions: no server to manage, scale automatically, pay per use; but you work within the platform’s limits (for example how long a function may run), and costs can be harder to predict at high volume.

For most student teams, an app platform (plus a backend-as-a-service) is the easiest starting point.

Question 16 · Long answer

Why should a payment-taking app use different keys and databases for development, previews and production? Describe how you would set this up.

So that testing can never touch real money or real customers’ data, and so a leaked development key can be revoked without breaking the live app. Setup: use Stripe sandbox (test) keys and a separate development database in .env.local and in the host’s Preview environment variables; use live keys and the production database only in the host’s Production environment variables. Then a bug in a preview can’t charge real cards or delete real sign-ups.

Question 17 · Scenario

Your app uses a free Supabase project. Nobody used it during spring break, and on demo day it doesn’t respond. What probably happened, and how could you have avoided the surprise?

As of October 2026, Supabase pauses free projects after a week of inactivity, so the database stopped answering. The owner can restore (unpause) it from the Supabase dashboard, which takes some time. To avoid the surprise: check the free plan’s rules in advance, open the app a day before the demo, and consider a paid plan for anything that must stay available.

Question 18 · Short answer

What problem do containers solve, and what are a Dockerfile and an image?

Containers solve “it works on my machine”: the app is packaged with everything it needs (runtime, libraries, settings), so it runs the same way on any computer or hosting platform. A Dockerfile is the recipe that says how to build the package; the image is the resulting package that platforms run.

Question 19 · Hands-on

Publish your hello-site (from HTML, CSS, JavaScript, and Browser Developer Tools) with GitHub Pages. Push it to a public GitHub repository, then in the repository go to Settings → Pages, under “Build and deployment” choose Deploy from a branch, select your main branch and the / (root) folder, and click Save. After a minute or two, find your site’s address on the same page. Then change the heading, commit and push: how long until the live site shows the change?

The site appears at an address like https://<your-username>.github.io/<repository-name>/. Because index.html is in the root of the branch, GitHub Pages serves it as the home page. Each push triggers a new build and deployment (you can watch it in the repository’s Actions tab); the change usually appears within a minute or two - this is push-to-deploy in action. If you see a 404, check that the repository is public, that you chose the right branch and folder, and that the file is named exactly index.html.

© 2025-2026 Y. Rosenthal. All rights reserved.