The pipeline
- You push codeYour commits go to a repository — usually GitHub. Nothing is live yet; this is a copy of source code, not a website.
- A build is triggeredThe host notices the push and starts a fresh machine, installs your dependencies, and runs your build command.
- 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.
- The output is distributedFiles are copied to servers, usually many of them in different regions so the reader is served from somewhere near.
- 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.
- 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.
| Record | Used for | Points at |
|---|---|---|
| A | The root domain (example.com) | An IP address |
| CNAME | A subdomain (www, learning) | Another hostname |
| TXT | Proving you own the domain | A 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
| Symptom | Usual cause |
|---|---|
| Build fails on the host, works locally | Uncommitted file, or a dependency you installed globally |
| Build passes, page is blank | A runtime error — check the browser console and the host's function logs |
| Works on preview, fails in production | A missing environment variable in the production scope |
| Domain shows the wrong site or a certificate error | DNS 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.