From localhost to a real URL: getting your project online

"It works on my machine" isn't "it's online." Between the project running on your screen and a real URL you can send someone, there's a step — and it's the one that stops the most people. Good news: it's not magic, it's a sequence of clear steps. Here's how to cross it cleanly.

"localhost" is just your own machine

When you run npm run dev, your computer starts a little server that serves only you. The address localhost (or 127.0.0.1) is an internal loop: it comes back to your own machine. No one else on Earth can open it. It's not the internet — it's your private workshop.

"Online" means something else: your code runs on a machine that's always on, reachable at a public address, that anyone can hit with the URL. That machine is the host.

So deploying is moving your project from the workshop to the shop: a public machine, configured for production. Everything else in this article is just the details of that move — and none of it is wizardry.

The build: what you ship isn't what you write

The code you write (React, Vue, etc.) isn't run as-is by the browser. A build step turns it into optimized files — compact HTML, CSS and JavaScript the browser loads fast. In development you use npm run dev, handy but chatty, made for you. To ship, you run npm run build, which produces the real package, usually in a dist/ or build/ folder.

The reflex that saves you most first-deploy headaches: run npm run build locally before deploying. Dev mode forgives things the production build refuses — a type error, a shaky import, a missing variable. Better to discover that in your workshop than in front of your visitors. If the build passes on your machine, you're off to a good start.

Environment variables don't travel

Classic first-deploy memory: "it worked on my machine, and online it's broken." Most of the time, the culprit is an environment variable.

Your local .env file stays on your machine — and that's a good thing, it has no business being online. The host has its own place to set these values: an "Environment Variables" screen in its dashboard. If your app reads an API key or a database URL from the environment, you have to recreate it there, otherwise it's simply absent in production.

The reflex: before deploying, list what your app expects from the environment, and copy each entry over to the host. And keep the client/server distinction in mind — a variable meant for the browser ends up in the public bundle, so you never put a secret there.

Static site or app with a server?

This is THE question that decides your host. Two cases:

• A static site: once built, your project is just a bundle of files (front-end only — a page, a React SPA, a generated site). It can be served from a static host, often free to start: Netlify, Vercel, Cloudflare Pages, GitHub Pages.
• An app with a server: you have code that runs server-side — an API, server-rendered pages, a database queried with a secret key. There, you need a host that runs your code continuously (or via functions): Vercel, Netlify, Railway, Render, Fly.io…

The deciding question: does your app need to run code on a server, or is it just files the browser executes?

Very common in vibecoding: a front-end plugged into a managed backend like Supabase. In that setup, your front-end is static (static host) and the "server" is Supabase. Simple and cheap.

And don't tense up about the "how": modern hosts detect your framework, run the build for you, and connect to your Git repo — every push redeploys on its own. Deploying, in practice, is often: connect the repo, fill in the variables, and let the platform do the rest.

HTTPS and a domain name

Two last points, simpler than they look.

HTTPS — the little padlock that encrypts traffic — is essentially mandatory today. The good news: on a decent host you do nothing, it's provided automatically and free. What used to be a nightmare a few years ago is now a non-event.

A domain name is optional, and it's worth saying: the moment you deploy, the host already gives you a public URL (something like your-app.vercel.app). You're already online before buying anything. To use your own mysite.com, you buy it from a registrar (Cloudflare, Namecheap, Gandi, OVH…), then point it at your host by adding a DNS record — the host gives you the exact value to paste. DNS is the internet's phonebook: you're just adding a line that says "this name leads here." Propagation can take a little while, then the host turns on HTTPS for your domain by itself.

In short

Going from localhost to a real URL isn't a leap into the void: it's moving your project onto a public machine, minding the build, the environment variables, and the right kind of host. Check your build locally, copy your variables over to the host, choose static or server based on what your app does, and connect a domain whenever you like — you're online well before that. Shipping calmly, step by step: that's exactly what vibecoding like a pro looks like.