Back to course overview
Module 8Deploy 13 min

Build & deploy

From laptop to the internet: what deployment actually is, the database swap you've been prepped for since Module 4, env vars in production, and the first live smoke test.

Deployment demystified: a hosting platform takes your repo, runs the production build (npm run build — a stricter compile that surfaces the loose ends dev mode tolerated), and serves the result on its computers at a real URL, redeploying automatically every time you push. The course path uses Vercel (the platform made by Next.js's makers — the lowest-friction pairing in the industry; the concepts transfer to any host):

  • The build must pass locally first. Run npm run build on your laptop before ever involving the platform. It will likely surface 2-3 complaints dev mode let slide (a type error, a missing null-check) — fix them with the assistant here, where the loop is seconds, not in the deploy logs where it's minutes.
  • The database swap — prepared since Module 4, executed now. Your SQLite file lives on your laptop; production needs a hosted database (serverless platforms don't keep local files between requests — ask the assistant to explain why in one paragraph; it's a good mental-model stretch). Create a free hosted Postgres (Vercel's marketplace or Neon), and have the assistant convert lib/db.ts and your queries — the schema is identical, the SQL nearly so, and because every database touch goes through that one module and your routes, the swap is an afternoon, not a rewrite. This painless swap is your architecture paying you back; say thank you to Module 4 you.
  • Environment variables move by dashboard, not by file. Your .env.local never leaves the laptop; production secrets (the AI key, the database URL, your passcode if you gated access) get entered in the platform's env settings. Same names, different vault. The .env.example you've maintained is now the checklist.
  • Then: push, import, initialize, deploy, smoke. The first push, walked through (Module 1 promised this moment): on GitHub, + → New repository, named replyable, no README (your project has one). Copy the two commands GitHub shows for 'an existing repository' — git remote add origin <url> then git push -u origin main — and run them; the browser sign-in window that appears is the authentication, approve it. Import the repo in Vercel, set the env vars — and initialize the hosted database: your local tables were created by lib/db.ts automatically, but the hosted one starts empty, so ask the assistant to turn your create-tables + seed into a one-time script you run against the production database URL, then confirm the tables exist in the provider's dashboard. Deploy, and run TESTING.md's critical path against the live URL (seed a message, draft with AI, send, refresh). The first live AI draft on a URL you own is the moment this course was pointed at; screenshot it.
Production failures are config failures, almost always

When live behaves differently than local, the suspect list is short and ordered: an env var missing or misnamed (check the dashboard against .env.example first, every time), the database connection (is the URL var set? did the schema get created — run your seed/migration against the hosted DB?), and only then actual code. The platform's function logs are your production terminal — find them before you need them, because 'where do I even see the error' is not a question you want to meet during your first incident.