How to deploy a small web app to a VPS without DevOps

You built something. It runs on your laptop — you type a command, open localhost, and there it is. Now you want other people to see it, at a real address, on the internet. That last step is where a surprising number of side projects quietly stall.

The code is done. What's left is everything around it: getting your app onto a server, keeping it running after you close your laptop, and making it reachable at a proper address with a padlock. That bundle of chores has a name — DevOps — and it's the part nobody signed up for.

What "deploying" actually means

Deploying is just moving your app from "runs on my machine" to "runs on a machine the whole world can reach." For that, three things have to be true:

• the code has to be on the server,
• it has to keep running — including after a crash or a reboot,
• and visitors have to be able to reach it at a domain, over HTTPS.

On your laptop you get the first two almost for free: you start the app and it runs until you stop it. A server is different — and that difference is the whole job.

The wall between your app and the internet

Here's the stack of small, unfamiliar pieces that usually sits in the way:

• A process manager — your app needs to start on its own and come back after a crash or a reboot. Run it by hand and it dies the moment you log out.
• A reverse proxy — your app listens on some internal port like 3000, but visitors arrive at 80 and 443. Something has to sit in front and route them in.
• HTTPS — the padlock. A certificate, issued and renewed, or browsers label your site "Not secure."
• A domain and an open door — the name has to point at the server, and the firewall has to let web traffic through.

None of these is hard on its own. Together, for a first deploy, they're a wall — four tools you've never met, each with its own config file and its own way of failing silently.

What your app actually needs

Strip away the tooling and the requirements are simple. Your app needs somewhere to run, a way to stay running, a route from the public address to its internal port, and a certificate so the connection is private. That's the entire list. Every tool in the DevOps pile exists to provide one of those four things.

Keep that in mind and deploying stops feeling like magic. It's four needs — however you choose to meet them.

The shortcut

You can wire up each piece yourself: pick a process manager, configure a reverse proxy, set up certificates, point the domain, open the port. It's a genuine education, and a genuine afternoon — or three. Or you can let Server Manager do it: you tell it you've got a web app and the address it should live at, and it puts your app on the server, keeps it running across crashes and reboots, routes your domain to it, and turns on HTTPS — the four needs, handled, without a config file in sight.

The one prerequisite is the domain. If you haven't done that yet, start with pointing a domain at your server — and the padlock follows on its own once the name resolves.

Your app, your server

The gap between "it works on my machine" and "it's live" is where a lot of good ideas go to wait forever. It doesn't have to be that way. The code was the hard part, and you already did it — putting it online should be the easy part, not the wall that stops you. Your app, on your own server, at your own address: that's the whole reward.

The help guides walk through deploying an app step by step whenever you're ready.