Skip to content
DevelopmentBeginner8 min read

What Happens When You Deploy a Website?

Deploying is moving code from your machine to one the public can reach. Here's every step in between, and where it usually goes wrong.

Written by Daksh BathlaFounder, Technology, Product & Business
Published 5 June 2026 · Updated 1 August 2026

WHAT YOU’LL LEARN

  • Describe the full path from git push to a live URL
  • Explain what a build step produces and why
  • Point a domain at a host without guessing
  • Diagnose the four failures that account for most broken deploys

PART OF A PATH

Start a Business

By the end you can explain what you're building, who it's for, why they'd pay, and how they'll find it.

The pipeline

  1. You push codeYour commits go to a repository, usually GitHub. Nothing is live yet; this is a copy of source code, not a website.
  2. A build is triggeredThe host notices the push and starts a fresh machine, installs your dependencies, and runs your build command.
  3. The build produces outputSource code becomes what a browser can use: bundled JavaScript, compiled CSS, optimised images, and, for a static site, the actual HTML files.
  4. The output is distributedFiles are copied to servers, usually many of them in different regions so the reader is served from somewhere near.
  5. Traffic is switchedThe new version starts receiving requests. On a good platform this is atomic: everyone sees old or new, nobody sees half of each.
  6. The old version is keptSo the rollback is a switch back rather than a rebuild. This is the single most valuable feature of a modern host.

What the build actually does

The build step exists because the code you write and the code a browser wants are different. You write in TypeScript, in many small files, with imports and comments. A browser wants JavaScript, in few files, as small as possible.

  • Compiles, TypeScript to JavaScript, modern syntax down to what older browsers understand
  • Bundles, hundreds of files into a handful, so the browser makes fewer requests
  • Minifies, strips whitespace, comments, and long names
  • Hashes filenames, `main.a3f9c2.js`, so a new version can never be served from a stale cache
  • Pre-renders, for static pages, runs your code once at build time and saves the resulting HTML

Pointing a domain at it

Your host gives you a working URL immediately. Using your own name means telling DNS where to send visitors, two records, in the domain registrar's settings.

The records you'll actually set
RecordUsed forPoints at
AThe root domain (example.com)An IP address
CNAMEA subdomain (www, learning)Another hostname
TXTProving you own the domainA verification string

Changes are not instant. Old answers are cached across the internet for as long as the previous record's TTL allowed, so a change can take minutes or hours to be visible everywhere. Lowering the TTL a day before a planned move makes the switch faster.

HTTPS certificates are issued automatically by most hosts once DNS resolves. If the certificate step is failing, the usual cause is that DNS isn't fully pointing at the host yet.

Environments and secrets

Most projects run in at least three places: your machine, a preview for each change, and production. They share code and differ in configuration, which database, which API keys, which URL.

Those differences live in environment variables, set in the host's dashboard, never committed to the repository. A `.env` file belongs in `.gitignore` on day one, because removing a secret from git history afterwards is genuinely painful and the key should be considered leaked either way.

The four common failures

Deploy failures and their usual cause
SymptomUsual cause
Build fails on the host, works locallyUncommitted file, or a dependency you installed globally
Build passes, page is blankA runtime error, check the browser console and the host's function logs
Works on preview, fails in productionA missing environment variable in the production scope
Domain shows the wrong site or a certificate errorDNS still pointing elsewhere, or a stale cache

For the first one, the reliable test is to clone your own repository into a clean folder, install, and build. If that fails, you've reproduced the host's environment on your own machine and the fix is immediate.

Common mistakes

  • Committing a `.env` file
  • Deploying on a Friday evening with no plan for rolling back
  • Assuming DNS changes are instant
  • Never testing the production build locally, so every deploy is the first run
  • Setting environment variables on preview only, then wondering why production breaks

Key takeaways

  • Deploy is: push, build, distribute, switch traffic, keep the old version
  • The build turns code you can read into files a browser can use quickly
  • DNS points a name at a host, and it's cached, so it isn't instant
  • Most deploy failures are a missing file, a missing variable, or stale DNS

Try it yourself

Run your production build command locally and serve the output. Whatever breaks there would have broken on the host, and finding it on your own machine takes a minute instead of a build cycle.

CHECK YOUR UNDERSTANDING

1. Why does the lesson say the old version of a deployed site is kept around after a new one goes live?
2. A build fails on the host but works fine on your own machine. What's the usual cause per the lesson?
3. You want to point the root domain example.com (not a subdomain) at your host's IP address. Which DNS record do you use?
4. Why does the lesson insist a .env file belongs in .gitignore from day one?
5. A deploy works fine on preview but fails in production. What does the lesson say is the usual cause?

Pass the quiz below to unlock this.

TERMS USED HERE

RELATED LESSONS