If you’re running an Ubuntu 22.04 server, you know updates are important—but you probably also fear the reboot that might break everything.
This guide walks through practical steps so your apps survive reboots and updates without you babysitting the box.

I’ll focus on how your applications are managed and restarted, because that’s where most of the real pain happens.

Who This Is For (And the Real Problem)

This is for anyone running an Ubuntu 22.04 server with a non-root sudo user.
Maybe it’s a small business site, a side project, a hobby Minecraft server, or something you installed from a Git repo.

The usual story:

• You know you should update, but you’re scared to reboot.
• You’re not sure if your apps will come back automatically.
• You might have a mix of package-installed services and custom scripts.

The real goal is simple: after a reboot or unplanned downtime, everything important should start by itself, correctly.
Updates are only safe when that’s true.

Step 1 – Use systemd to Manage Your Applications

On Ubuntu 22.04, the init system is systemd.
That’s the piece that starts services, stops them, and brings them back after boot.
You interact with it using the systemctl command.

Most software installed from the Ubuntu package manager (like apt) that runs in the background already comes with a systemd service and a unit file.
This is the recommended way to run long-running applications.

A few examples of things that usually already have systemd units when installed via packages:

• Web servers (like Apache or Nginx)
• Databases (like PostgreSQL or MySQL/MariaDB)
• Caches, queues, and other daemons that sit in the background

If you installed something from a package and it runs in the background, chances are good it already hooks into systemd.

Step 2 – Check Which Services Are Managed by systemd

Before trusting your server to reboot safely, you should know which parts of your stack are actually handled by systemd.
Anything not managed by systemd might not come back on its own.

Use systemctl to list system services:

sudo systemctl list-units --type=service

You’ll see a long list of units with states like loaded, active, running, failed, and so on.
Focus on the services that matter to you—web stack, app servers, background workers.

You can check a specific service like this:

sudo systemctl status your-service-name.service

This shows whether it’s running, how it starts, and some logs.
If it’s a package-installed service (like nginx.service or postgresql.service), you’re in good shape.

Step 3 – Plan for Custom or Git-Based Apps

Here’s where a lot of people get burned.
If you’ve deployed your own app from a Git repo—say a custom API, background worker, or some random script—it probably doesn’t have a systemd unit by default.

That means after a reboot, it just stays dead until you remember to SSH in and run your start command.
For any custom or Git-based tools, you have three main options:

1. Write a systemd unit file (recommended long-term)
2. Use a lightweight process manager like Supervisor
3. Use cron with the @reboot syntax

The source we’re basing this on doesn’t go into unit file details, so I’ll stay high-level and focus on the concepts.
The important part is: pick one method and make sure it’s tested.

Step 4 – Understand Alternatives: Supervisor and Cron @reboot

If writing systemd unit files feels heavy for a small script, there are two lighter options mentioned in the source: Supervisor and cron.

Option A – Supervisor (lightweight process manager)

Supervisor is a small tool that keeps processes running.
If they crash, Supervisor restarts them.

It’s often used when you want a simple way to manage custom apps without diving deep into systemd configs.

With Supervisor in place:

• Your script or app is defined in a config file.
• Supervisor starts it and keeps it alive.
• On reboot, Supervisor starts and then starts your app.

This works well for long-running scripts or workers.

Option B – cron with @reboot

Your system’s cron scheduler lets you run commands at schedule.
The @reboot syntax tells cron to run a command every time the server boots.

Example idea (not full syntax, just the concept):

• Configure cron to run your app start command on every reboot.
• Cron triggers it once at boot time.

This is simpler than a full service, but less feature-rich.
It’s fine for some small tasks that just need a single start on boot.

Step 5 – Test Your Restart Strategy with Reboots

Once your configuration is in place—whether using systemd, Supervisor, or cron—you must test it.
Never assume it will work just because you configured something.

Use this command to reboot safely:

sudo shutdown now -r

This does a clean reboot:

• Stops running processes properly
• Reboots the system immediately

You can also schedule the reboot in the future, using time formats like hh:mm or a number of minutes from now instead of now.
This helps you line up the reboot with a maintenance window or a low-traffic period.

For example (concept only, based on the info given):

• sudo shutdown 23:30 -r → reboot at 23:30
• sudo shutdown +10 -r → reboot 10 minutes from now

After the reboot, log back into the server and check:

• Are all the critical services running?
• Are your apps responding?
• Did anything fail silently?

Use systemctl status for your important services and confirm they came back up.
If something is missing, fix it now, before relying on automatic updates or unplanned reboots.

Step 6 – Why This Matters for Automatic Updates

Linux package managers like apt are designed to run non-disruptively in the background.
They’re meant to do maintenance without you constantly watching them.

But there’s a big catch: even if the update itself is fine, the reboot afterward is what hurts you if your services don’t restart correctly.
That’s why a lot of people avoid a proper update strategy—they’re simply not confident the box will behave after a reboot.

If you:

• Make sure your apps are under systemd (or at least Supervisor/cron), and
• Test reboots until you’re confident everything comes back,

…then automatic or regular updates become a lot less scary.
Production deployments should ideally survive reboots without requiring your attention.
That’s what we’re building toward here.

Step 7 – Safety Tips Before You Rely on This in Production

A few quick safety habits so you don’t learn the hard way like I did back in the 486 and diskette days:

• Use a non-root sudo user (as assumed here).
  This reduces the chance of wrecking the whole system with one bad command.
• Test on a non-production server first if you can.
  A small test droplet or spare VM is a good place to mess around with services and reboots.
• Reboot during low traffic.
  Even if everything should come back, give yourself breathing room.
• Document what you changed.
  Future you (or your teammate) will be much happier when debugging a weird startup issue.

The key idea: don’t let the first real test of your restart strategy be during a 3 a.m. outage.

Wrap Up

Keeping an Ubuntu 22.04 server updated isn’t just about running apt.
The real work is making sure every important app can restart correctly after downtime or a reboot.

You do that by:

• Letting systemd manage as many services as possible
• Using tools like Supervisor or cron’s @reboot for custom apps
• Testing everything through actual reboots with sudo shutdown now -r

Once you’re confident your stack survives reboots on its own, updates become much less stressful.
Need more help? Check the latest CrushEdge posts.