Hack University
Course outline · 0% complete

0/29 lessons0%

Course overview →

Build and deploy

lesson 9-2 · ~9 min · 28/29

From laptop to URL

Shipping is a two-command story you can rehearse locally:

next build   # compile + prerender static pages + print the route table
next start   # run the production server

next build is the moment everything from Unit 7 happens: static pages render to HTML, generateStaticParams lists expand, and the route table prints with its static/dynamic markers. Read that table before every deploy. It is the truth about what you built.

In production you almost never run next start by hand. A hosting platform does it for you.

The Vercel-style workflow

Platforms like Vercel (made by the Next.js team), Netlify, and others all follow the same git-driven loop:

  1. Push to GitHub. Your repo is connected to the platform.
  2. The platform builds. It runs next build on its servers with the environment variables you configured in its dashboard, not your .env.local, which stays on your machine and out of git.
  3. It deploys atomically. The new version goes live at your URL only when the build succeeds. Pull requests even get their own preview URLs.

Two habits that save real pain: set env vars in the platform dashboard before building (remember, NEXT_PUBLIC_* is inlined at build time), and never commit .env.local.

git push(GitHub)platform runsnext build + envlive URL(atomic swap)a failed build never replaces the running site
The git-driven deploy loop: push triggers a build with the platform's env vars, and only a successful build is promoted to the live URL.

When a NEXT_PUBLIC_ change does not take effect

Suppose you changed NEXT_PUBLIC_API_URL in your hosting dashboard, but the live site still uses the old value. The most likely fix is to trigger a fresh build.

NEXT_PUBLIC_ variables are inlined during next build, which means the value is copied into the JavaScript as a literal constant. The running bundle contains the old string, not a lookup that could pick up a new value. Changing the dashboard entry affects only future builds, so the site keeps serving the old constant until you rebuild and redeploy.

This is the practical consequence of build-time inlining, and it catches nearly everyone once. Server-only variables behave differently: they are read at runtime, so changing one and restarting is enough.

The order of a git-driven deploy

The sequence is: push to GitHub, the platform runs next build, then the new version goes live.

The push is the trigger, since the whole workflow is event-driven off your repository. The platform then builds with its own configured environment variables rather than anything from your laptop. Only a successful build is atomically promoted to the live URL.

Why it works out that way

  • The trigger is a git event, which is what makes deploys reproducible: the deployed artifact always corresponds to a specific commit.
  • Nothing goes live unless the build succeeds first. A failed build leaves the previous deployment untouched and serving traffic, which is the safety net of this workflow.
  • Because the build happens on the platform, the environment variables it uses must be configured there beforehand, as the previous block showed.