Tech & AI, Explained

understand-deploy-pipeline

8 min read

Reading path: I want to understand the deploy pipeline

Status: 🟩 COMPLETE Last updated: 2026-06-19 Plain-English tagline: Follow code from the moment you save a file to the moment a user in Tokyo sees the change — every layer in between, in the order it happens.

What this is

A focused journey along the deploy pipeline: YOUR LAPTOP → Git → GitHub → Vercel → CDN edge → USER’S BROWSER. After this path, the chain of events from “I pressed save” to “someone halfway around the world sees the update” is clear, not magic.

This is shorter than the first-webapp path — focused only on the deploy chain. 15 stops. Read in order; each stop builds on the previous.

How to use this path

Each numbered stop has:

  • 🎯 Why you’re here — what part of the pipeline this covers
  • 📖 Read — the entries (with status badges)
  • 🧠 Anchor concept — the takeaway worth keeping

Stage 1 — Code on your machine (3 stops)

1. The starting point — code in your editor

🎯 Why you’re here: Everything begins with you typing into VS Code (or another editor). Understanding what’s there is the foundation.

📖 Read:

🧠 Anchor concept: Your code is just a folder of text files on disk. The editor displays them, the terminal runs commands on them, git tracks them. Nothing magical.

2. Running it locally

🎯 Why you’re here: Before you push anywhere, you run the app on your laptop. Understanding npm run dev vs npm run build is the first chance to catch bugs.

📖 Read:

🧠 Anchor concept: npm run dev runs a lenient dev server. npm run build produces a production build — the EXACT thing Vercel will run. Always build locally before pushing to catch errors early.

3. Tracking changes with Git

🎯 Why you’re here: You don’t push files directly; you commit them to Git, then push the commits.

📖 Read:

🧠 Anchor concept: A commit snapshots your code. Commits chain into HISTORY. Branches let you work on something without affecting the main line. You push commits, not files.

Stage 2 — Code on GitHub (2 stops)

4. GitHub — the cloud home for code

🎯 Why you’re here: GitHub stores your commits permanently, lets others see them, and (crucially) lets Vercel watch for new pushes.

📖 Read:

🧠 Anchor concept: GitHub = Git + a UI + collaboration. Pushing to GitHub triggers anything connected to GitHub (Vercel, GitHub Actions, etc.).

5. GitHub Actions — CI on every push

🎯 Why you’re here: Before code deploys, you can run tests, lint, type-checks automatically. GitHub Actions is the most-used way.

📖 Read:

🧠 Anchor concept: Every push triggers automation. Tests run; lint runs; type checking runs. If any fail, the deploy is blocked. The pipeline is your safety net.

Stage 3 — Code on Vercel (3 stops)

6. Vercel — the deploy platform

🎯 Why you’re here: Vercel sees your GitHub push and builds + deploys your code. Understanding what it does behind the scenes.

📖 Read:

🧠 Anchor concept: Vercel: clones your repo → runs npm install → runs npm run build → uploads the output → switches traffic to the new version → keeps the old version available for instant rollback.

7. What “the build” actually does

🎯 Why you’re here: A “build” turns your source code into the optimized files that actually run in production.

📖 Read:

🧠 Anchor concept: The build optimizes everything — minifies JavaScript, generates static HTML for cacheable pages, splits code per route, compresses images. The output is a folder Vercel can serve very fast.

8. Serverless functions — your “backend” on Vercel

🎯 Why you’re here: When your app needs server code (API routes, server actions), Vercel runs it as a serverless function. Not a long-running server.

📖 Read:

🧠 Anchor concept: Vercel functions sleep until called. Each request wakes one up, runs your code, returns the response, then it sleeps again. You pay only for execution time; idle time is free.

Stage 4 — Code reaching the user (4 stops)

9. CDNs — getting content close to the user

🎯 Why you’re here: A user in Tokyo shouldn’t fetch every byte from Vercel’s US datacenter. CDNs put copies of static assets near every user globally.

📖 Read:

🧠 Anchor concept: Vercel runs your code at the edge (close to users) and caches static content on a global CDN. A first-time visit fetches from origin; subsequent visits get cached responses in ~10ms.

10. DNS — pointing the domain at Vercel

🎯 Why you’re here: Your domain (stmarkbible.com) needs to point at Vercel’s servers. DNS is the system that makes the connection.

📖 Read:

🧠 Anchor concept: DNS maps human-readable names (stmarkbible.com) to numeric IP addresses. You configure DNS once when you connect a custom domain to Vercel; propagation takes minutes to hours.

11. SSL/HTTPS — the encryption layer

🎯 Why you’re here: Modern web traffic is encrypted. Vercel auto-issues a certificate; understanding what it does demystifies the padlock.

📖 Read:

🧠 Anchor concept: A certificate proves “this server really is stmarkbible.com.” Combined with encryption, it ensures nobody on the network can read or tamper with traffic. Vercel handles cert issuance + renewal automatically.

12. The user’s request actually arriving

🎯 Why you’re here: All the pieces above are in place. Now a user types your URL. What HAPPENS, second-by-second?

📖 Read:

🧠 Anchor concept: Browser → DNS resolves the IP → TCP connection opens → TLS handshake → HTTP request sent → Vercel edge handles → response back. Tens of milliseconds, end to end.

Stage 5 — When things break (3 stops)

13. Debugging deploys

🎯 Why you’re here: Eventually a build fails. Knowing how to read the log and what to look for is essential.

📖 Read:

🧠 Anchor concept: Vercel build failures fall into 6 categories: TypeScript errors, missing env vars, case sensitivity, missing deps, lint errors, runtime errors in build-time code. Each has a specific fix path. The build log shows which.

14. Environment variables — the configuration layer

🎯 Why you’re here: Code differs between local and production via env vars. Mismanaging them is the #1 deploy headache.

📖 Read:

🧠 Anchor concept: .env.local (gitignored, your secrets) → set the same keys in Vercel dashboard → code reads process.env.X regardless of where it runs. The NEXT_PUBLIC_ prefix exposes a value to the browser; never use it for secrets.

15. Rolling back

🎯 Why you’re here: A deploy can break production. Knowing how to roll back IN 5 SECONDS is the calmest possible recovery.

📖 Read:

🧠 Anchor concept: Vercel keeps every previous deploy. On the dashboard, click “Promote” on any earlier deploy → it’s live in 5 seconds. No rebuild, no waiting. Combined with git’s reflog, almost no mistake is permanent.

When you finish this path

You’ll be able to:

  • ✅ Explain — in plain English — what happens between git push and “the new feature is live”
  • ✅ Read a failed Vercel build log and identify the category of failure
  • ✅ Set env vars correctly across local / preview / production
  • ✅ Roll back a broken deploy in under 30 seconds
  • ✅ Debug “why isn’t this working in production” by checking 3-4 obvious places (env vars, build log, function logs, DNS)
  • ✅ Understand WHY HTTPS, CDNs, edge functions exist — what each layer adds

The whole pipeline ceases to be magic. It’s a chain of well-understood steps, each one debuggable.

When the pipeline isn’t enough

For larger projects, you’ll add:

  • Preview deploys — every PR gets its own URL (Vercel does this automatically)
  • Multi-environment — staging + production with separate databases
  • Custom GitHub Actions — extra checks beyond what Vercel runs
  • Monitoring — Sentry, Datadog, or platform tools for production observability
  • Feature flags — deploy code dark, enable selectively

But for solo / small projects, the chain in this path is everything you need. Vercel + Supabase + GitHub + your laptop = the complete pipeline.

See also

Sources

Graph View

Backlinks