Maintain and update

A machine that runs 24/7 and is reachable from the outside is never “done.” It’s alive, and like everything that’s alive, it needs a bit of upkeep. The good news: 90% of it comes down to two habits, one automatic, the other monthly. Let’s look at which ones, and above all how to update without breaking anything.

The OS: the base system

Your Ubuntu is the foundation. Two levels of upkeep:

# The routine move: refresh the package list, then install updates
sudo apt update && sudo apt upgrade -y
# Clean out packages that have become useless
sudo apt autoremove --purge

For security, you’ve already automated everything in System settings with unattended-upgrades: the machine applies critical patches on its own. That’s the automatic habit we mentioned.

Once every two years, a new LTS version of Ubuntu comes out. The latest, Ubuntu 26.04, was released in April 2026, and the upgrade path from 24.04 has been open since its first point release, 26.04.1, published at the end of August: Canonical always waits for that “.1” before offering LTS-to-LTS upgrades. Nothing urgent, 24.04 gets security fixes until 2029. The day you go for it, back up first (see Git, GitHub & backups) and skim the release notes.

# First finish pending updates, reboot if asked
sudo apt update && sudo apt full-upgrade -y
# Then start the upgrade to the next LTS (inside tmux if you're over SSH)
sudo do-release-upgrade

Dependencies: what your projects rest on

This is where the surprises hide, because a dependency that jumps a major version can break a project.

• Node (via nvm): nvm install --lts installs the latest LTS (Node 24 as of October 1, 2026, with Node 26 due to become LTS on October 28), nvm alias default sets it as the default. Keep the old one around long enough to confirm your projects still run.
• A project’s packages: npm outdated shows what’s behind, npm update updates within the bounds of your package.json. For major versions, read the changelog first: that’s where the breaking changes live.
• The habit that saves you: lockfiles. Version your package-lock.json / requirements.txt. They guarantee your project reinstalls exactly the same versions, everywhere, and that nothing shifts behind your back.

Tools and agents

The rest of your stack updates cleanly, each in its own way:

• Docker: follows the system’s apt updates. Remember to clean up what piles up (see below).
• Ollama: rerun the install script to move to the latest version (curl -fsSL https://ollama.com/install.sh | sh). And for models, you grab a new vintage with ollama pull <model>: the local version is replaced. To spot the ones worth updating to, the Quelle IA ranking of local models (in French) is refreshed every week.
• Your coding agents: Claude Code, installed through its script, updates itself in the background, and claude update forces the latest version. OpenCode moves to the latest with opencode upgrade. If you had installed Claude Code with npm, switch to the native installer (curl -fsSL https://claude.ai/install.sh | bash), then remove the old copy with npm uninstall -g @anthropic-ai/claude-code. An up-to-date agent means new capabilities for free.
• Tailscale and cloudflared: installed via their own repos, they update with the system. Nothing special to do.

Disk space: the silent trap

Models, Docker images, and old packages fill a disk without warning, and a full machine starts crashing in mysterious ways. The cleanup comes down to three commands:

df -h                      # how much room is left
docker system prune -a     # drop unused images and containers
ollama rm <model>          # remove a model you no longer use
sudo apt autoremove --purge # orphaned packages

Knowing when it breaks

A machine working alone overnight only warns you if you programmed it to. The risk is not the outage, it is how long it takes to reach you. Everything below comes from real incidents on this machine.

1. A script calling another must propagate its exit code

The classic trap, and a very common one:

#!/bin/bash
set -uo pipefail
python3 import.py >> import.log 2>&1        # the exit code goes in the bin
systemctl --user restart my-site || true    # last command: always returns 0

This script always returns 0. The import can crash, systemd reports success, and your weekly report tells you everything is fine. It happened here: a database sat empty for a day while the monitor showed green.

The fix is two lines:

python3 import.py >> import.log 2>&1
rc=$?
systemctl --user restart my-site || true
exit $rc

2. OnFailure: get told the second it falls over

systemd can trigger one unit when another fails. You write a small service that messages you, and wire it onto everything that matters.

# ~/.config/systemd/user/my-service.service.d/onfailure.conf
[Unit]
OnFailure=alert@%n.service

Use an override file in a .d/ directory rather than editing the unit: it works even on a unit symlinked from a repository, and removing it means deleting a folder.

3. A system probe, because no unit alert sees the machine drowning

When RAM fills up, no unit is “failed”. The machine itself is going under, and OnFailure cannot see a thing. You need a separate probe, on a timer, watching available memory, processes killed by the kernel, swap and load, then messaging you on state change so it does not repeat the same alert every five minutes.

Let the agent help you

This is exactly the kind of chore your agent loves. “Check what’s due for an update on this machine, summarize the important changes for me, and propose a plan”: it lists the packages that are behind, reads the changelogs for you, and offers to act step by step. You keep your finger on the button, it does the investigative work.