Deploy

Right now your sign-up page exists on exactly one computer on Earth: yours. Close the lid and it is gone. Deploying means copying it onto machines that never sleep and giving it a name people can type. On this stack that is four commands — plus one thing you cannot do from the terminal.

Working on your machine is not done. Deployed is done. This page gets you from the first sentence to the second without losing a secret or a weekend.

Hosting is someone else’s computer that never turns off

A host is a machine with a public address that stays on. You hand it your files; it answers when a browser asks. That is the whole idea.

What changed is the delivery. Modern hosts watch your repository and deploy on every git push: pull the code, build it, publish it in a minute or two, with a preview URL for every branch. Nothing is uploaded by hand, no web server is configured, and no bill arrives until you are genuinely popular.

Static or server-rendered decides almost everything else

Static means the site is built once, into a folder of plain HTML, CSS and JavaScript, and that folder is copied to machines around the world. Nothing runs per visitor. It is the cheapest, fastest and hardest-to-break option. The site you are reading is static: npm run build turns the source into dist/, and dist/ is the website.

Server-rendered means a program runs for each request: it checks who you are, reads the database, calls a paid API. That code lives on the server, out of the user’s sight, which is the only place secrets can live. It comes in two shapes — one long-running server, or small serverless functions (Cloudflare Workers, Vercel Functions) that wake per request and go back to sleep.

The rule for a first project: keep as much static as you can and push the dynamic part into the smallest possible function. Free tiers are counted in function invocations and CPU time, not in static files — Cloudflare’s free Workers tier gives 100,000 requests a day and 10 ms of CPU per invocation, while Pages lists no bandwidth cap at all for static assets. Serving a static page costs you nothing. A function spends budget every time someone loads it.

Five free tiers, and what each one does when you hit the wall

These are the real numbers as of September 2026. The column that matters is the last one.

For a student in Kazakhstan the choice is nearly made for you: a public GitHub repo, Cloudflare Pages or Workers for the site, and D1, Neon or Supabase for data. None of those asks for a card. Netlify’s free tier is the trap — twenty deploys and the month is gone, and you will deploy twenty times in one evening. Firebase is the other one: Cloud Functions need the pay-as-you-go plan, and that plan needs a billing account with a payment method on it.

A domain is a rented name, and DNS is the phone book

Your site already has an address the moment it deploys — something like qairu-event.pages.dev. A custom domain is a nicer name pointed at the same place.

DNS is the internet’s directory: it translates a human-readable name into the address of the machine that answers for it. When you attach a domain you add a record, and the one you will meet first is a CNAME — it says “this name means that server”. Your host then issues the SSL certificate that turns http:// into https://, automatically, for free.

The part that confuses everybody: DNS answers are cached worldwide, so a change takes anywhere from minutes to hours to reach everyone. If the site works for you and not for your friend, you are almost always looking at a cached old record, not a broken deploy. Wait before you debug.

Secrets belong on the host, never in the repo and never in the browser

An environment variable is a named value handed to your program when it starts — an API key, a database address, a setting like NODE_ENV=production. It lives outside the code so the same code can behave differently on your laptop and on the server.

There are exactly three places a secret can be, and only one of them is correct:

• In a .env file on your laptop. Fine, as long as .env is in .gitignore before your first commit.
• In the host’s dashboard, as an environment variable your server code reads. This is production.
• In the frontend. Never. Anything the browser downloads is public — a visitor opens developer tools and reads it in seconds.

Moving from the first place to the second is where first deploys die. Your .env never leaves your laptop, so nothing in it exists on the host until you type it there. Before you deploy, open .env, go key by key, and add each one in the host’s dashboard. When a page works locally and errors in production, the usual cause is one variable that lives in only one of those two places.

Module 8 gave your agent a deny rule on .env in .claude/settings.json. Keep it, and keep its limits in mind: it blocks Claude’s file tools and the shell readers it recognises, not a script that opens the file itself. It is a second layer, not a lock (Claude Code permissions docs).

Every branch gets its own URL, so break things where nobody is watching

A preview deploy is a full copy of your site built from one branch, published at its own address, with nothing pointing at it but the link. You send that link instead of a screenshot. On Netlify, deploy previews and branch deploys are not metered at all — it is only production deploys that cost credits, which makes previews the cheapest place to be wrong.

Previews also catch the classic “it works on my machine” failure: your host builds on Linux, and Linux cares about capital letters in filenames while Windows does not. Header.astro imported as header.astro works all day on your laptop and fails in the build log. Read the log; it tells you the filename.

The four commands that ship it, and the click at the end

1. Prove it builds before anyone else sees it

   The repo behind this site bundles its checks into one script, so there is one thing to remember. It runs the translation check, the type check, the build and the link check, in that order, and stops at the first failure.

   bashКөшіру

   npm run verify

2. Build the folder that is the website

   npm run verify already ran this as its third step. Run it once on its own anyway, then open dist/ and look inside: plain HTML, CSS and JavaScript. Understanding that a static site is just a folder removes most of the fear from this whole step.

   bashКөшіру

   npm run build

3. Push, which is your backup and your trigger

   Your commits go to GitHub. This is the history you can roll back to, and on a repo wired to CI it is also the button that starts everything else.

   bashКөшіру

   git push origin main

4. Publish the folder to the edge

   Wrangler is Cloudflare’s CLI. It uploads dist/ and hands you a live URL on pages.dev, served with HTTPS from data centres worldwide, at no cost. qairu-event is the Pages project name — use your own, and the URL that comes back is that name plus .pages.dev.

   bashКөшіру

   npx wrangler pages deploy dist --project-name=qairu-event

5. Attach the domain — and this one is not a command

   Be honest with yourself about this step: you cannot finish it from the terminal. You open the Cloudflare dashboard, find your Pages project, go to Custom domains, and add the name. Cloudflare creates the CNAME record and issues the SSL certificate for you. Then you wait for DNS to spread.

   Deploy guides that show four tidy commands quietly skip this one. Your agent will skip it too, and then tell you the site is live when it is live only on pages.dev.

One GitHub Action, start to finish

Continuous integration is the same commands, run by someone else’s machine on every push, so that “I forgot to run the tests” stops being possible. It lives in your repo as a file:

name: Deploy
on:
  push:
    branches: [main]
jobs:
  ship:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run verify
      - run: npx wrangler pages deploy dist --project-name=qairu-event
        env:
          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}

Read it top to bottom: on a push to main, rent a Linux machine, check out the code, install Node 20, install dependencies exactly as the lock file says, run the checks — which already produce dist/ — and then publish. The token is never in the file. GitHub stores it encrypted and substitutes it at run time, which is the same “secrets live on the host” rule applied to your build machine.

The cost: GitHub Free gives 2,000 Actions minutes a month on private repositories, and standard runners are free on public repositories. A public repo plus Cloudflare Pages is a complete pipeline for zero. (GitHub billing docs)

Rollback is a skill you practise on a quiet Tuesday

Your agent’s undo does not reach production. Claude Code checkpoints cover the edits it made to your files, and explicitly not remote side effects — database writes, pushes, deploys. /rewind puts your source back and the broken version stays live the whole time. (Checkpointing docs)

So rollback is a git operation followed by a deploy. Find the last commit that was fine, undo the bad one as a new commit, push, rebuild, publish:

git log --oneline -5
git revert --no-edit <commit-hash>
git push origin main
npm run build
npx wrangler pages deploy dist --project-name=qairu-event

What makes this fast is small commits. If one commit holds an agent’s entire afternoon across forty files, reverting it throws the good work out with the bad, and you will hesitate at exactly the moment hesitating is expensive. Commit before each agent request, not after each work session.

Then do the part almost nobody does: run that sequence today, while the site is fine. A rollback you have never tested is a plan, not a safety net.

Plan the deployment for this project to Cloudflare Pages. Do not write
any code yet.

Context:
- This is a static site. `npm run build` outputs to dist/.
- `npm run verify` runs all checks and must pass before any deploy.
- The repo is public on GitHub.

In your plan, cover:
1. The exact commands I run locally for a first manual deploy.
2. A .github/workflows/deploy.yml that runs the checks and deploys on
   push to main, reading its token from an encrypted Actions secret.
3. Which secrets I must create, and where each one is stored.
4. A rollback procedure using git revert plus a redeploy.

Then list separately, under the heading "I must do these in a browser",
every step you cannot perform from the CLI — including attaching the
custom domain. Do not claim the site is live until that list is done.