Deployment

Website Rebuild with Next.js

Chapter 11 · Deployment

This chapter's own deployment story is genuinely different from three of its five already-complete siblings — Laravel, Rails, and Astro all found a way to reuse the site's own already-live Apache. This course stands up entirely new infrastructure instead, the same real situation Django Rebuild 11 independently faced.

Two Real Paths: Vercel or Self-Hosted

Named honestly, not silently chosen
Vercel is built by the Next.js team, specifically for Next.js — vercel deploy gets a working production URL with essentially zero configuration, precisely because the platform and the framework share an owner. That's the genuinely easiest real path for a real Next.js project. This chapter goes self-hosted instead, deliberately: it's the only way to give this course a genuine, comparable production deployment story against its own siblings, on the same kind of server the real site this whole series rebuilds actually runs on.

Building for Production

npm run build # next build — Turbopack by default, per Chapter 1

next build produces the production bundle; next start serves it. Neither of these alone stays running after the terminal session ends — that's the next problem.

PM2: Keeping the Server Running

// ecosystem.config.js module.exports = { apps: [{ name: 'website-rebuild-with-nextjs', script: 'node_modules/.bin/next', args: 'start', cwd: '/var/www/website-rebuild-with-nextjs', env: { NODE_ENV: 'production', PORT: 3000 }, }], };
pm2 start ecosystem.config.js pm2 save pm2 startup

pm2 startup registers PM2 itself to relaunch on server reboot — without it, a reboot would silently take the whole site down until someone noticed.

The same real job as Django's own gunicorn
PM2 exists to solve the identical problem Django Rebuild 11's own gunicorn needed a process supervisor for: a production server process that must keep running unattended, restart itself if it crashes, and survive a reboot. Different runtime, same real requirement.

nginx: A Fresh Reverse Proxy

Stood up from nothing — not reused
The site's own existing Apache setup has a real, working path for PHP (via mod_php or PHP-FPM) — but nothing for proxying to a plain Node process on a local port. Rather than bolt an unfamiliar module onto Apache, this chapter stands up a fresh nginx instance instead, exactly the same call Django Rebuild 11 made for the identical reason.
# /etc/nginx/sites-available/nextjs-rebuild server { listen 80; server_name nextjs-demo.example.com; location / { proxy_pass http://localhost:3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; } }

The Upgrade/Connection headers matter specifically because Next.js's own dev-time hot-reload and certain runtime features rely on WebSocket upgrades — worth proxying correctly even in production, not just for local development.

certbot: TLS for the New Proxy

sudo certbot --nginx -d nextjs-demo.example.com

certbot's own nginx plugin edits the site's config in place, adding the certificate paths and a redirect from port 80 to 443 automatically — the same Let's Encrypt mechanism behind every genuinely free HTTPS setup on a self-hosted server.

Secrets: A Plain .env

# .env — never committed DATABASE_URL="mysql://user:password@localhost:3306/nextjs_rebuild" AUTH_SECRET="a long, random, generated value"
AUTH_SECRET, the direct equivalent of a name every sibling course already has
AUTH_SECRET is what Auth.js uses to sign the JWT sessions Chapter 9 introduced — the exact same job Django's SECRET_KEY, Laravel's APP_KEY, and Rails' master.key each do in their own frameworks. A plain .env file is the simplest secrets story of the whole series — matching Django and Laravel's own convention exactly, not Rails' own reversed, encrypted-commit-to-the-repo approach.

Deployment, Compared Across the Series

Next.jsDjangoLaravelRailsAstroExpress
ApproachStood up fresh — PM2 + nginx + certbotStood up fresh — gunicorn + nginxModernize in place — Apache mod_proxy_fcgiModernize in place — Apache mod_passengerModernize in place — Apache mod_proxy_httpStood up fresh — reuses Astro's own PM2 + mod_proxy_http unchanged
SecretsPlain .envPlain .envPlain .envEncrypted, committed (master.key)Plain .envPlain .env (via dotenv, an explicit package)
First-party zero-config platform?Yes — Vercel (not used here, named honestly)NoPaid, AWS-specific (Vapor)NoNoNo

Hands-On Exercises

Exercise 1

Run next build, start the result with PM2 using this chapter's own ecosystem.config.js, and confirm pm2 status shows the process running and pm2 startup is registered.

📄 View solution
Exercise 2

Configure the nginx reverse proxy from this chapter, run certbot against it, and confirm the site is reachable over HTTPS with a valid certificate — not just HTTP on port 3000 directly.

📄 View solution
Exercise 3

Explain why this course's own deployment chapter had to stand up nginx from nothing, while Laravel Rebuild's, Rails Rebuild's, and Astro Rebuild's own Chapter 11s could all reuse the site's already-live Apache instead.

📄 View solution

Chapter 11 Quick Reference

  • Vercel or self-hosted — Vercel is genuinely easier; this chapter goes self-hosted for a comparable production story across the series
  • PM2 — keeps next start running unattended and across reboots, the same real job as Django's gunicorn
  • nginx, stood up fresh — the existing Apache has no path for a plain Node process; certbot handles TLS
  • AUTH_SECRET in a plain .env — the direct equivalent of Django's SECRET_KEY/Laravel's APP_KEY/Rails' master.key
  • Next chapter: Capstone: A Complete, Working Flexible-Routing Site