Ubuntu 22.04 LTS

The honest pitch

Ubuntu 22.04 LTS was released in April 2022. Its standard security maintenance ends in mid 2027, about six months from now. A server you deploy on Jammy today has a short free-patch runway. That is fine for some jobs and a liability for others.

Deploy 22.04 when you need to mirror an existing estate: a staging copy of a production fleet that hasn't been upgraded, a CI runner that must build artefacts against Jammy's glibc 2.35, or a vendor package that only certifies on 22.04. For anything new, start on Ubuntu 24.04.

What's in the box

• Linux 5.15 GA kernel, with HWE kernels available through linux-generic-hwe-22.04
• OpenSSL 3.0, Python 3.10, systemd 249, OpenSSH 8.9
• Netplan for networking, AppArmor for confinement, snapd by default
• ufw installed but inactive, unattended-upgrades enabled for security pockets

The HWE kernel is worth a look on Jammy. It tracks the newer kernel series from later Ubuntu releases and gives you better io_uring and NVMe behaviour without moving the userland. Install it with apt install linux-generic-hwe-22.04 and reboot.

First boot

apt update && apt full-upgrade -y
adduser ops && usermod -aG sudo ops
install -d -m 700 -o ops -g ops /home/ops/.ssh
cp ~/.ssh/authorized_keys /home/ops/.ssh/ && chown ops: /home/ops/.ssh/authorized_keys
sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart ssh

Unlike 24.04, SSH on Jammy is a plain service, not socket-activated. Changing Port in sshd_config and restarting is enough. Keep a second session open while you test, and keep the portal's browser console in mind as a fallback.

ufw allow OpenSSH
ufw allow 443/tcp
ufw enable

Keep it patched until you leave

Security updates arrive through jammy-security and unattended-upgrades applies them. Confirm with unattended-upgrade --dry-run --debug. Kernel updates still need a reboot. Check /var/run/reboot-required from your monitoring and reboot in a maintenance window.

After mid 2027, the free archive stops receiving fixes for most packages. If you can't migrate in time, attach Ubuntu Pro yourself (pro attach <token>) to keep ESM updates flowing. Canonical offers a free personal tier with a machine limit. Commercial use beyond that is a Canonical subscription and has nothing to do with your FastNode bill.

Planning the exit

Treat a Jammy server as something with an end date. A practical migration path:

1. Deploy a fresh 24.04 server on the same plan, in the same London region.
2. Rebuild it from your configuration management, not by copying /etc wholesale.
3. Replicate data: pg_basebackup or logical replication for PostgreSQL, rsync -aHAX for files.
4. Lower DNS TTLs a day ahead, cut over, and keep the old server stopped but not deleted for a week.

Because both servers sit on the same network, replication traffic stays local and quick. Traffic is unmetered, so a large sync costs nothing extra.

Jammy-specific gotchas

• Python 3.10 is getting old. Many libraries are dropping 3.10. Use uv or pyenv to install a newer interpreter per project, rather than replacing the system Python.
• OpenSSL 3.0 legacy ciphers. Old clients or keys using SHA-1 signatures may fail. Fix the client, don't re-enable legacy providers on the server.
• cgroup v2 by default. Older Docker or container tools that expect cgroup v1 break. Use current Docker Engine from Docker's own repository.
• do-release-upgrade over SSH. If you do upgrade in place, it starts a fallback sshd on port 1022. Allow that port in ufw and the portal firewall before you begin.

Sizing

Jammy runs comfortably on Spark for a single service or a lightweight runner. Staging copies of production should match production's shape. If production runs on four cores and 8 GB, put staging on Turbo so load tests mean something. Build agents compiling large C++ or Rust projects want Warp. Whatever you pick, put a review date in the calendar for early 2027 so the migration happens on your schedule, not the lifecycle's.