Deployment — Shipping Your Work

What deployment actually means

When you run a project locally with a tool like Vite's dev server, your computer is temporarily acting as a web server, but only your machine can reach it. Deployment moves that responsibility to a server that's always on and connected to the public internet, then points a domain name at it so people can type a URL and reach your files. Static sites, meaning sites made of HTML, CSS, and JavaScript with no server-side code required, are the simplest and cheapest to deploy, and modern hosts like Netlify, Vercel, and GitHub Pages have made this close to a one-click process for exactly this kind of project, which covers everything you've built in this course.

Before deploying, you typically run your project's build command, the same npm run build step from the developer workflow chapter, which compiles your source files into an optimized dist folder containing minified HTML, CSS, and JavaScript ready for production. Deployment platforms are usually configured to run this build step automatically whenever you push new code, then serve the resulting files. Understanding this pipeline demystifies what's happening: your source code isn't uploaded directly, a processed and optimized version of it is, which is part of why performance techniques from earlier in this level matter even before a single visitor arrives.

A typical deployment workflow

• Push your project to a Git repository hosted on GitHub (or a similar service).
• Connect that repository to a hosting platform like Netlify or Vercel.
• Configure the build command (often npm run build) and the output directory (often dist).
• The platform builds your project and publishes it to a live URL automatically.
• Every future push to your main branch triggers a new automatic deployment, known as continuous deployment.

1# netlify.toml2[build]3  command = "npm run build"4  publish = "dist"56[[redirects]]7  from = "/*"8  to = "/index.html"9  status = 200

That redirect rule solves a specific and common problem for single-page applications: if your JavaScript handles routing on the client side (showing different views without a full page reload) and a visitor refreshes the page on a route like /about, the server needs to know to still serve index.html and let your JavaScript take over from there, rather than returning a 404 because no literal /about file exists on the server. This is a good example of how deployment decisions connect directly back to how your JavaScript is structured.

Environment variables and keeping secrets safe

If your project uses an API key, as you likely did in earlier chapters working with external APIs, you must never commit that key directly into your source code, especially once it's pushed to a public GitHub repository, since anyone can then read and misuse it. Instead, secrets belong in environment variables: values kept outside your codebase and injected at build or run time. Locally, these often live in a .env file that's listed in .gitignore so Git never tracks it; on a hosting platform, you configure the same variables through that platform's dashboard, where they stay private but are still available to your build process.

1// .env (never committed to Git)2// VITE_WEATHER_API_KEY=abc12334const apiKey = import.meta.env.VITE_WEATHER_API_KEY;56fetch(`https://api.example.com/weather?key=${apiKey}&city=Nairobi`)7  .then((res) => res.json())8  .then((data) => console.log(data));

It's worth being clear-eyed about a limitation here: anything shipped to the browser, including a key exposed through import.meta.env, is ultimately visible to anyone who inspects the network requests or bundled JavaScript. Environment variables at build time protect your keys from appearing in your Git history and source code, which matters, but they don't make a key invisible to a determined visitor. For anything sensitive, like a key with billing attached, the safer long-term pattern is routing requests through a small server-side function you control, which is a natural next step beyond what this course covers.