Deployment

What Does "Deployed" Mean?

Your project works on your computer at localhost:3000. You can see it, click around, and it feels real. But nobody else can see it. Your computer is not a web server; it is not listening for requests from the outside world.

Deployment means putting your project on a server that is connected to the internet, so anyone with the URL can access it. That is the gap between "it works on my machine" and "it is live." Closing that gap is one of the most satisfying moments in building.

Deployment is not the finish line. It is the starting line. The moment your work is live is the moment real feedback begins.

Static vs Dynamic

There are two kinds of websites, and the distinction matters for deployment:

A static site is a collection of pre-built files (HTML, CSS, JavaScript) served as-is. The server does not think. It just hands over files when asked. Blogs, portfolios, documentation sites, and marketing pages are usually static. This entire Zero Vector site is static.

A dynamic site runs code on the server for every request. It talks to databases, processes user input, and generates pages on the fly. Web apps with login systems, dashboards, and real-time features are dynamic.

Most things you build early will be static, and that is fine. Static sites are faster, cheaper (often free), simpler to deploy, and more secure. You can go surprisingly far before needing a server.

The Build Step

When you write code in React, Vue, or any modern framework, your browser cannot read it directly. JSX is not HTML. Sass is not CSS. Your source code needs to be compiled into plain HTML, CSS, and JavaScript that browsers understand.

This is the build step. You run a command, usually npm run build, and your build tool (Vite, Webpack, etc.) processes everything, optimizes it, and outputs the result into a dist/ or build/ folder.

The dist/ folder is what gets deployed. Not your source code, not your node_modules, not your .env file. Just the clean, compiled output. This is why deployment and development are separate steps: what you work with is not what you ship.

# Build your project for production
npm run build

# This creates a dist/ folder with the compiled files:
# dist/
# ├── index.html
# ├── assets/
# │   ├── index-abc123.js    (your compiled code)
# │   └── style-def456.css   (your compiled styles)
# └── images/

Hosting Platforms

The easiest way to deploy a static site is through a platform that connects to your GitHub repo, watches for pushes, and auto-deploys your latest code. The three most popular:

Netlify offers a generous free tier, excellent for static sites and simple serverless functions. Zero Vector is deployed on Netlify. Drag-and-drop deploy is available, but Git-based deploy is better.

Vercel was built by the creators of Next.js. Great developer experience, fast CDN, similar free tier. Particularly good for Next.js and React projects.

GitHub Pages provides free hosting directly from a GitHub repository. More limited than Netlify or Vercel, but zero configuration for simple projects. Good for portfolios and documentation.

All three follow the same pattern: connect your repo, set the build command (npm run build) and publish directory (dist), and every push to main automatically builds and deploys. This is called continuous deployment: you push code, it goes live.

Your First Deploy

Let us walk through the Netlify workflow, since it is what we use:

1. Click "Add new site" → "Import an existing project" → select GitHub.

2. Pick the repository you want to deploy from the list of your existing GitHub repos.

3. Set the build command: npm run build.

4. Set the publish directory: dist (or build, depending on your tool).

5. Click "Deploy." Netlify clones your repo, runs the build, and publishes the output.

In about 90 seconds, you have a live URL like your-project-name.netlify.app. That is it. Your project is on the internet.

From this point on, every time you push to main, Netlify rebuilds and redeploys automatically. You do not need to manually deploy again. Push code → it goes live.

When Deployment Fails

Your deploy will fail eventually. This is normal. The build log tells you exactly what went wrong.

The most common failures: a missing dependency (you installed something locally but forgot to save it to package.json), a build error (something in your code that works in development but fails in production), or an environment variable that is set locally but not on the hosting platform.

Read the build log from the bottom up. The last error is usually the cause. Fix it, push again, and the platform rebuilds automatically. This loop (push, fail, read the log, fix, push again) is completely normal. Even experienced developers go through it.