How to Keep Your Ubuntu 20.04 Server Updated Safely

Before & After: Updating Ubuntu Without Fear

Before: you’ve got an Ubuntu 20.04 server running something important, and every time you see packages can be upgraded your stomach drops. You know you should update, but you’re scared a reboot will kill your app and you’ll spend your evening undoing the damage.

After: your services restart cleanly, you’re not afraid of apt upgrade, and you can reboot when needed without babysitting the box. Updates become boring maintenance instead of a mini heart attack.

This guide is for anyone running Ubuntu 20.04 servers (especially on VPSes like droplets) who wants a simple, safe way to keep things updated. We’ll focus on one core idea: if your apps can survive a reboot, updates stop being scary.

Prerequisites: Don’t Do This as Root

Quick checklist before touching anything:

Ubuntu 20.04 server
This guide assumes you’re on Ubuntu 20.04.
Non-root user with sudo
You should be logged in as a regular user that can run sudo, not directly as root. This reduces the chance of breaking things with a typo.

If you don’t have a sudo user set up yet, do that first following a standard “Initial Server Setup with Ubuntu 20.04” approach. It’s worth the few minutes; it’s your main safety net.

Whenever you see commands here, assume you run them as your non-root user with sudo in front when needed.

Step 1 – Make Sure Your Apps Survive a Reboot

The real problem with updates usually isn’t the packages themselves. It’s what happens after: services don’t start, background apps vanish, or some custom script never comes back.

So first goal: every important application on your server should come back automatically after a reboot.

On modern Ubuntu (including 20.04), this is handled by systemd, and you manage it with the systemctl command.

1.1 Check which apps are managed by systemd

Most software you installed from the Ubuntu repositories that runs in the background should already have a systemd service. That’s the ideal situation.

To see if a service is running and managed by systemd, use for example:

sudo systemctl status apache2

Replace apache2 with whatever you’re using (nginx, mysql, etc.). You’ll see whether it’s active, enabled, and if it will start on boot.

active (running) → it’s running now.
enabled → it will start automatically on boot.

If something critical is not enabled, you can enable it so it starts on reboot:

sudo systemctl enable your-service-name

This simple step alone fixes a lot of “after reboot my app is gone” sadness.

1.2 What about custom apps or code from Git?

If you’re running your own software, or something you just pulled from a Git repository, it often doesn’t come with a built-in systemd service. That means if the server reboots, it won’t start automatically.

In that case, you have a few options:

Write your own systemd unit file to manage it like a normal service.
Use a process manager like Supervisor as a lightweight alternative.
Use cron’s @reboot syntax to run something when the server starts.

The main idea: don’t rely on screen, manual ssh sessions, or “I’ll just start it by hand”. Put your app under something that knows how to restart it.

Step 2 – Use systemd Properly for Background Services

Let’s focus on the most common and recommended path: systemd. This is what Ubuntu 20.04 expects you to use for services.

2.1 Interact with your services using systemctl

For anything that should run in the background (web servers, databases, queues, etc.), you use systemctl:

Start:

bash sudo systemctl start your-service

Stop:

bash sudo systemctl stop your-service

Restart (useful after updates):

bash sudo systemctl restart your-service

Check status:

bash sudo systemctl status your-service

If your package came from apt and is meant to be a daemon, it should already have a unit file and integrate with systemd. That’s best practice.

2.2 Why this matters for updates

When you update packages, some of them may need to restart services in the background. Ubuntu’s package manager is built to do this without making a mess.

If your stack is fully under systemd, those restarts and reboots are predictable:

Services stop cleanly.
Services start again automatically.

That’s the whole foundation of safe, boring updates.

Step 3 – Alternatives: Supervisor and Cron @reboot

Sometimes you don’t want to deal with writing full systemd unit files, or you have a simple script you just want to keep running. There are lighter approaches.

3.1 Using Supervisor as a lightweight alternative

Supervisor is a process-control system. You tell it what commands to run, and it keeps them alive.

It’s useful when:

You’re running app code from a Git repo.
You don’t want to build full systemd unit files.
You still want something to restart your process if it crashes or after reboot.

You configure programs in Supervisor, and it will make sure they start on boot and restart when needed. It’s lighter on the brain than doing the full systemd dance, especially for small custom tools.

3.2 Using cron with @reboot

Another quick and dirty but sometimes perfectly fine option: cron’s @reboot.

You can tell cron to run a command every time the system starts. Example concept (don’t run literally, adapt it):

@reboot /path/to/your/script.sh

This is handy for simple scripts that just need to run once on boot or start a basic background process. It’s not as smart as systemd or Supervisor, but it’s much better than relying on “I’ll remember to start it manually”.

The key is still the same: your apps shouldn’t depend on you being awake and online after a reboot.

Step 4 – Safely Testing Your Reboot Behavior

Once you’ve got your services under systemd, Supervisor, or @reboot cron, you must test it. Better to find issues now than during a midnight incident.

4.1 Use a clean reboot command

To reboot the server cleanly and stop processes properly, use:

sudo shutdown now -r

That will:

Stop running processes cleanly.
Reboot the system immediately.

This is much safer than yanking power or using something that doesn’t give services time to shut down.

4.2 Schedule a reboot for later

If you don’t want to reboot right now (maybe users are online), you can schedule it.

You can specify a time in hh:mm format instead of now. For example:

sudo shutdown 23:30 -r

Or a number of minutes from now. This lets you pick a quiet time instead of surprising everyone.

4.3 After reboot: verify everything came back

Once the server is back:

Log in with your sudo user.
Check your key services with systemctl status your-service.
Hit your website/app from the browser or via curl.
Confirm any background workers or scripts are running.

If anything is missing, fix that now (unit file, Supervisor config, or cron entry). You want a situation where a reboot does not require manual steps.

Step 5 – Why This Makes Updates Less Scary

Ubuntu’s package management is designed to be non-disruptive. It runs in the background and handles maintenance so you don’t have to do everything by hand.

But many admins still avoid a good update strategy because they’re worried: “What if it reboots and my app doesn’t come back?”

By putting your apps under systemd, Supervisor, or @reboot cron and testing reboots, you remove that fear. Updates might still require reboots occasionally, but:

You know what happens after a reboot.
You’ve already tested it.
You’re not tied to the server each time.

That’s the real win: you can let Ubuntu do its thing and not panic every time it touches a service or asks for a reboot.

Step 6 – Quick Safety Tips and Next Steps

A few habits that keep you out of trouble:

Always use a sudo user, not root directly.
One typo as root can wreck the system. Sudo adds a tiny bit of friction that saves you.
Test changes on a non-critical server first if you can.
If you’ve got more than one Ubuntu 20.04 box, try new setups on the less important one first.
Plan reboots when users are least active.
Use shutdown hh:mm -r or minutes-from-now scheduling to reboot when it hurts the least.
After any big app change, do a reboot test.
New services, new app stack, or a move from “manual start” to systemd? Reboot once and make sure it all comes back clean.

If you build this habit—services under system control, clean reboots, and basic checks—keeping Ubuntu 20.04 updated becomes a normal task, not a dice roll.

If this saved you time, bookmark CrushEdge for more fixes.

Photo by Ling App on Unsplash