Publish to the internet

Your app runs great on localhost, but nobody else can reach it yet. To go live, the single most important decision is how you host it. Get that right and the rest is smooth; get it wrong and you'll burn time on ops you didn't need.

Let's make the three paths clear, walk the easiest one end to end, and then cover deploying your code, HTTPS, and the pitfalls that trip people up.

Three ways to go live

Almost every project fits into one of these three buckets. Find yours first, then read on.

A quick way to decide:

• No backend (pages, tools, docs, marketing) → use static hosting. It's the easiest.
• A backend but you don't want to touch a server (full-stack apps, APIs) → use Serverless / PaaS.
• You want full control, or to minimize long-term cost → run your own VPS. See Buy a server and Cheap cloud servers.

The simplest path: static sites

If your project builds into a folder of static files (HTML / CSS / JS), congratulations — going live takes minutes. Here's Cloudflare Pages (Vercel and Netlify are nearly identical).

git init
git add .
git commit -m "first deploy"
git remote add origin git@github.com:your-username/your-project.git
git push -u origin main

Apps with a backend

If your app needs a long-running process (handling API requests, talking to a database, running background jobs), static hosting alone won't cut it. You have two paths:

PaaS (Railway / Render / Fly.io) — try this first

• You just write code; the platform runs the container, gives you a domain, sets up HTTPS, and shows you logs.
• Connect a Git repo and deploy — as low-effort as static hosting.
• Best for: full-stack apps, Node/Python/Go backends, projects that need a database.
• Railway and Render can spin up a managed database (Postgres / Redis) alongside your app, so you don't install one yourself.
• Downside: per-unit cost is higher than a VPS at scale, and there's some platform lock-in.

Your own VPS — when you want control or savings

• You get a clean Linux box and do everything yourself: install the runtime, configure an Nginx reverse proxy, harden it.
• Best for: running special software, long-term low-cost always-on workloads, or just learning ops.
• For buying and setting one up, see Buy a server and Cheap cloud servers.

Getting your code deployed

Whether you go PaaS or VPS, modern deployment follows the same core idea: Git-based deploys.

1. Build command: after the platform pulls your code, it runs this to produce a runnable artifact.
2. Output folder (dist / output): for static sites this is the built folder; for backend apps the platform runs your start command instead.
3. Environment variables: secrets, database connection strings, third-party API keys — these must never be hardcoded. Set them in the platform dashboard.

A typical build + start flow looks like this:

# install dependencies (use the lockfile for reproducible versions)
npm ci

# build
npm run build

# start (backend apps; static sites skip this)
npm start

On PaaS, open your project's Settings → Variables / Environment to add them. Read them in code via process.env.DATABASE_URL; use a local .env in development and platform variables in production — they don't interfere with each other.

HTTPS & custom domains

Good news: most platforms give you free HTTPS automatically. Cloudflare Pages, Vercel, Netlify, Railway, and Render all issue and renew certificates for you — you do nothing, and the site loads over https://.

Attaching a custom domain is easy too:

1. Add your domain under the platform's Custom domains section.
2. Add the CNAME (or A) record it tells you to in your DNS, pointing at the platform.
3. Wait for the certificate to issue automatically (usually minutes), and your domain is live.

• No domain yet? See Buy a domain.
• Want Cloudflare for DNS, CDN, and protection? See Set up Cloudflare.

Common pitfalls

The right way to bind the port and host (Node example):

const port = process.env.PORT || 3000;
app.listen(port, "0.0.0.0", () => {
  console.log(`listening on ${port}`);
});