Make it survive without you

Your site is live — but it's not safe yet. Right now, if you close your terminal, the power blips, or the server just reboots on its own, your app quietly goes dark. This module fixes that, so your project keeps itself running even when you're asleep, on vacation, or simply not watching.

Right now, your site is more fragile than it looks

Back in Module 7, you started your app by typing something like node server.js into the terminal. That works great — but only while that exact terminal window stays open and connected to your server. The moment you close it, your app stops instantly, like unplugging a lamp.

It gets worse. If the server itself ever restarts — a provider doing routine maintenance, a power blip, or you rebooting it on purpose — nothing brings your app back automatically. It just sits there, off, until you notice and start it again by hand. That's not a great way to run a real website.

Keep it alive with a process manager

The fix is a process manager. Think of it as a babysitter for your app: it watches your program in the background, and the instant it crashes — or the whole computer restarts — the babysitter starts it right back up. No phone call needed, no you required.

We'll use pm2. It's a great fit here because it's just another Node.js tool, and it works nicely with the Node setup (via nvm) you already installed back in Module 5.

First, install pm2 itself. This only needs to happen once:

npm install -g pm2

The -g means "install this globally" — so the pm2 command is available anywhere on your server, not just inside one project folder.

Next, go into your app's folder and start it under pm2 instead of running it directly:

pm2 start server.js --name myapp

This tells pm2 "watch this file and keep it running." The --name myapp part just gives it a nickname, so later commands can refer to it by name instead of a long file path. Feel free to swap in your own app's short name.

Right now, pm2 will restart your app if it crashes — but it still forgets everything if the whole server reboots. Two more commands fix that for good:

pm2 startup      # prints one more command to copy-paste and run
pm2 save         # remembers the current apps

pm2 startup doesn't finish the job by itself — it looks at your specific server and prints out one more command, tailored to your system. Copy that whole line it gives you, paste it back into the terminal, and press enter once. Then pm2 save takes a snapshot of "these are the apps that should be running" so pm2 knows to bring them all back after any future reboot.

Reading the logs when something breaks

Every program leaves a trail of what it did — its logs. Think of logs as your app's diary: every request it handled, every error it hit, written down in order. When something goes wrong, logs are the very first place to look.

pm2 logs myapp

This shows your app's recent output and errors, and keeps streaming new lines live as they happen. Press Ctrl+C when you're done watching — that just stops the log view, it doesn't stop your app.

Is it even running?

Sometimes you just want a quick health check rather than a full diary. Two commands cover that:

pm2 status
sudo systemctl status caddy

pm2 status shows whether your app is up and how much memory it's using — worth a glance after any change. sudo systemctl status caddy checks the health of Caddy, the web server from Module 8 that actually faces the internet. Between the two, you can quickly tell whether the problem is your app or the front door.

Reassurance: reading logs and status isn't an advanced-programmer skill. It's just how you find out what broke instead of guessing — and guessing is the slow, stressful way.

Backups & snapshots: your safety net

A snapshot is a photograph of your entire server, taken at one moment. If a future change goes badly wrong, you can restore that photograph and be back exactly where you were — mistake undone.

Every major VPS provider has a "Snapshots" button somewhere in the dashboard. Some also offer automatic weekly backups for a small monthly fee.

Good habit: take a manual snapshot right before any risky change — a big new feature, an update you're unsure about, anything that could break your live site. Then experiment freely, knowing you can always rewind.

Routine updates: keep the system patched

The operating system on your server gets security fixes over time, just like your phone or laptop does. Keeping it patched closes holes before anyone can use them against you.

sudo apt update && sudo apt upgrade -y

apt update refreshes the list of what's available; apt upgrade -y actually installs the newer versions, and -y auto-answers "yes" so it doesn't stop to ask you at every step. Run this every so often — once a month is plenty for a small project — and reboot afterward if it suggests one.

If you want this to happen without even remembering, Linux has an optional tool called "unattended-upgrades" that installs security fixes automatically. Nice to know it exists; not something you need to set up today.

Cost hygiene: turning it off doesn't stop the bill

So how do you actually stop paying? Take a snapshot first (so you can rebuild everything later if you change your mind), then destroy — fully delete — the server. That's the one action that stops the charges. If your server just feels too big rather than unwanted, you can also resize down to a cheaper plan in a few clicks instead of deleting anything. And don't worry about keeping old snapshots around — they're cheap to store, far cheaper than a whole running server.

✏️ Hands-on: make your site heal itself

Time to put all of this to work on your real server. This takes about ten minutes, including a reboot.

1. Install pm2

   In your terminal, run npm install -g pm2.

2. Start your app under pm2

   From your app's folder, run pm2 start server.js --name myapp (use your own filename and a short nickname).

3. Make it survive a reboot

   Run pm2 startup, then copy-paste and run the one extra command it prints for you. Finish with pm2 save.

4. Actually test it

   Run sudo reboot. Wait about a minute, then reconnect over SSH like you did in Module 3. Visit your site in the browser — it should already be back up, all on its own.

5. Take your first snapshot

   Open your provider's dashboard and click the "Snapshots" button to save a photograph of your working server.