From code to a live URL

• Explain version control and what a GitHub repo is, in one line each. ★
• Define “a deploy”: taking built code and running/serving it on a host. ★
• Name the modern hosts (Vercel/Netlify/Cloudflare/Railway/Render/Fly) and the rough split between static/frontend hosts and app/server hosts. ★
• Trace domain → DNS (A/CNAME) → host, and say what HTTPS/SSL adds. ★
• Explain preview deploys, prod vs preview env vars, and where to read logs when it breaks. ★
• Say what CI/CD means at orientation level: push → build → test → deploy.

02 Curated reading

• GitHub — Hello World ↗

  essential 15m — Repo, commit, push, branch from the source.
• Vercel — Deployments overview ↗

  essential 12m — What a deploy and a preview deploy are, concretely.
• Cloudflare — What is DNS? ↗

  optional 12m — DNS, A vs CNAME, and the resolution path.

03 Knowledge check

What gets asked on this topic — tap a card for how to approach it, the follow-ups, and the trap. Company tags are best-effort & sourced.

• ▸ Commonly asked junior concept very common What is version control, and what is a GitHub repo — in one line each?

  Version control (Git) tracks the history of your code over time, lets you branch and merge, and lets you go back to any past state. A GitHub repo is a hosted home for a Git repository — the shared remote copy that you push to, others pull from, and deploys are triggered from.

  Git is the tool; GitHub is a hosting service for Git repos (with PRs, issues, and CI on top).

  Follow-ups they push on

  • What's the difference between a commit and a push?
  • What is a branch for?

  Red flag Conflating Git and GitHub. Git is the version-control tool; GitHub is one place to host Git repos.

  source: GitHub — Hello World ↗
• ▸ Commonly asked junior concept occasional Modern hosts — Vercel, Netlify, Cloudflare, Railway, Render, Fly. What's the rough split between them?

  Roughly two camps. Static / frontend hosts (Vercel, Netlify, Cloudflare Pages) are tuned for serving built frontends and serverless functions at the edge — push a repo, they build and serve it. App / server hosts (Railway, Render, Fly) are tuned for long-running servers, databases, and containers.

  The line blurs (most do some of both), but the orientation-level instinct is: a static site or a frontend-plus-functions app leans toward the first group; a long-running backend with its own database leans toward the second.

  Follow-ups they push on

  • Where would you host a static marketing site vs a websocket server?
  • What does 'edge' mean here?

  Red flag Treating all hosts as interchangeable — a pure static host won't run your always-on stateful backend well.

  source: Vercel — Deployments overview ↗
• ▸ Commonly asked junior concept common Walk the path from a domain name to your running app. What does HTTPS/SSL add?

  Domain → DNS → host. You point the domain at the host using DNS records: an A record maps a name to an IP address; a CNAME maps a name to another name (e.g. your-app.vercel.app). The browser resolves the name via DNS, then connects to the host.

  HTTPS/SSL adds encryption and identity: it encrypts traffic so it can't be read or tampered with in transit, and the certificate proves the server is who it claims to be. Without it, credentials and data travel in plaintext.

  Follow-ups they push on

  • When do you use an A record vs a CNAME?
  • Why does the padlock matter beyond 'it's secure'?

  Red flag Thinking DNS 'hosts' the site — DNS only maps the name to an address; the host serves the actual app.

  source: Cloudflare — What is DNS? ↗
• ▸ Commonly asked junior concept occasional What is a preview deploy, and where do you look first when a deploy breaks?

  A preview deploy is a full, live build of a branch or pull request at its own URL, separate from production — so you (and reviewers) can click through the change before it ships. Production and preview typically have separate env vars, which is a common gotcha when something works in preview but breaks in prod.

  When a deploy breaks, read the build logs first (did it compile?), then the runtime logs (is it crashing at request time?), and check that the right env vars exist for that environment.

  Follow-ups they push on

  • Why might something work in preview but fail in production?
  • What's the difference between a build-time and a runtime error?

  Red flag Forgetting prod and preview have different env vars — a missing prod secret is a classic 'works on preview' failure.

  source: Vercel — Deployments overview ↗
• ▸ Commonly asked junior concept occasional What does CI/CD mean at a high level?

  CI (Continuous Integration) is automatically building and testing your code every time you push, so problems surface early. CD (Continuous Delivery/Deployment) is automatically taking the code that passed and deploying it.

  The whole pipeline, orientation-level: push → build → test → deploy. The point is no manual steps and no 'works on my machine' — every change goes through the same gated, repeatable path.

  Follow-ups they push on

  • What's the difference between continuous delivery and continuous deployment?
  • Why run tests before deploying?

  Red flag Thinking CI/CD is one tool — it's a practice/pipeline; many tools implement it.

  source: GitHub — Hello World ↗
• ▸ ★ must-know Commonly asked junior concept very common Walk the full chain from a git commit to a live URL. What happens at each step?

  Repo → build → bundle → deploy → host. You push a commit to the repo (e.g. GitHub). That triggers a build on the host: it installs dependencies and runs your build command, which bundles your source — many files of TS/JSX/CSS — into a small set of optimized, browser-ready static assets (dist/). The host then deploys those artifacts (copies them to its servers/CDN) and serves them at a URL.

  The mental model that matters: your source code is *not* what runs — the built bundle is. A push kicks off a pipeline that transforms source into deployable artifacts and puts them somewhere always-on. Modern hosts collapse all of this into 'git push and we handle the rest'.

  What a strong answer covers

  • Chain: push to repo → host builds → bundler produces optimized dist/ → deploy → live URL.

  • Bundling turns many dev files into a few optimized, browser-ready assets.

  • What runs in prod is the build output, not your raw source.

  • Modern hosts trigger the whole pipeline automatically on push.

  Quick self-check

  After `git push`, your host shows a live site. What did the browser actually download?

  • Your raw .tsx/.ts source files, run directly by the browser.
  • The bundled, transpiled output (the build artifacts in dist/).
  • The GitHub repo, cloned into the browser at load time.
  • Nothing — the server runs your code and only streams pixels.

  Follow-ups they push on

  • What does a bundler (Vite, esbuild) actually do to your files?
  • Why isn't your raw `.tsx` source what the browser downloads?

  Red flag Thinking the browser runs your source files — it runs the bundled, transpiled output; a build step sits between your code and what ships.

  source: Vite — Building for Production ↗
• ▸ Commonly asked junior concept common What does a bundler like Vite or esbuild actually do, and why do you need one?

  A bundler takes your project — dozens or hundreds of source files plus dependencies — and produces a small set of optimized files the browser can load efficiently. Along the way it transpiles modern TS/JSX into plain JavaScript the browser understands, resolves and combines imports, minifies (strips whitespace and shortens names), tree-shakes unused code, and fingerprints filenames for caching.

  You need one because browsers don't run TypeScript or JSX, and shipping hundreds of separate files would be slow. The bundler is the bridge between 'how you write code' (modular, modern, typed) and 'what loads fast in a browser' (few, small, plain-JS files).

  What a strong answer covers

  • Transpiles modern TS/JSX → plain browser-compatible JavaScript.

  • Combines many modules and resolves imports into a few output files.

  • Minifies and tree-shakes to cut size; fingerprints filenames for caching.

  • Bridges 'nice to write' (modular/typed) and 'fast to load' (few small files).

  Follow-ups they push on

  • What is tree-shaking?
  • Why does the browser need TS transpiled before it can run it?

  Red flag Confusing the bundler (prepares code to ship) with the host (serves it) — they're different stages; the bundler runs during the build.

  source: Vite — Why Vite (the problems it solves) ↗
• ▸ Commonly asked junior concept common What's the difference between a build-time error and a runtime error when a deploy goes wrong?

  A build-time error happens while the host is compiling/bundling your code — a type error, a syntax error, a missing import. The build fails, nothing gets deployed, and you read the build logs to find it. Production keeps serving the last good deploy.

  A runtime error happens after a successful deploy, when the live code actually executes a request — a null reference, a crashed API call, a missing env var the code reads at request time. The build passed, the site is 'up', but pages error; you read the runtime/function logs to find it. First diagnostic question on any broken deploy: did it fail to build, or did it build and then fail to run?

  What a strong answer covers

  • Build-time: fails during compile/bundle (type/syntax/import errors) → check build logs; nothing deploys.

  • Runtime: fails while serving requests on a deployed build → check runtime/function logs.

  • A failed build leaves the previous good version live; a runtime error means broken-but-deployed.

  • First question: did it fail to build, or build fine then fail to run?

  Quick self-check

  Your deploy succeeds and the site loads, but one page throws 'cannot read property of undefined' for some users. What kind of error is this?

  • Build-time error — check the build logs.
  • Runtime error — check the runtime/function logs.
  • DNS error — the domain didn't resolve.
  • A bundler error — Vite failed to compile.

  Follow-ups they push on

  • A missing env var — is that more likely build-time or runtime?
  • Why might TypeScript catch a build-time error that JS would only hit at runtime?

  Red flag Looking in the build logs for a problem that's actually a runtime crash (or vice versa) — knowing which phase failed points you at the right log.

  source: Vercel — Logs (build vs runtime) ↗
• ▸ Commonly asked junior concept common How do you wire the same secret (like an API key) into local dev, preview, and production without committing it?

  Locally, you keep secrets in a .env file that is git-ignored (and you commit a .env.example with the keys but not the values, so teammates know what's needed). The code reads them via the environment (process.env.API_KEY), never hardcoded.

  For preview and production, you set the same variable names in the host's environment-variable settings (the dashboard or CLI), with environment-specific values. Each environment can hold a different value — a test key for preview, the real key for prod. The code stays identical; only the supplied values differ. The secret never enters git in any environment.

  What a strong answer covers

  • Local: git-ignored .env; commit .env.example (names only, no values).

  • Code reads from the environment (process.env.X), never hardcodes the value.

  • Preview/prod: set the same names in the host's env-var settings, per-environment values.

  • Same code everywhere; only the injected values differ; nothing secret hits git.

  Follow-ups they push on

  • Why commit a `.env.example` but never the real `.env`?
  • Why might preview use a different API key than production?

  Red flag Setting env vars only locally and forgetting the host — the build/runtime in prod has no value, so it works locally and breaks when deployed.

  source: Vite — Env Variables and Modes ↗
• ▸ Commonly asked mid concept occasional What does a CDN do, and why is serving your app from 'the edge' faster?

  A CDN (Content Delivery Network) is a global network of servers that cache your static assets close to users. Instead of every visitor fetching files from one origin server (which might be a continent away), they're served from a nearby edge location, cutting the round-trip distance and latency.

  'The edge' just means 'physically close to the user'. For a static frontend, the whole site can be cached at the edge so it loads fast worldwide. The tradeoff to remember: cached content is fast but can be stale until it's invalidated, and truly dynamic/personalized responses can't simply be cached for everyone.

  What a strong answer covers

  • A CDN caches assets on servers worldwide, serving each user from a nearby location.

  • 'Edge' = close to the user; less distance means lower latency.

  • Great for static assets and frontends; the whole site can live at the edge.

  • Tradeoff: cached content can be stale; per-user dynamic responses don't cache trivially.

  Follow-ups they push on

  • What kind of content is easy to cache at the edge vs hard?
  • What does 'cache invalidation' mean and why is it tricky?

  Red flag Assuming everything benefits from edge caching — highly dynamic or per-user responses can't be shared from a cache, and stale caches serve old content until invalidated.

  source: Cloudflare — What is a CDN? ↗