Ubuntu 26.04 LTS Server Setup for Developers: What Changed and What to Watch

A new Ubuntu LTS lands every two years, and 26.04 is the one most teams will run in production through the rest of the decade. A fresh LTS is the right moment to revisit your server baseline not to chase novelty, but because the defaults, kernel, and toolchain have all moved, and a few of those moves will bite you if you provision a box the way you did in 2024. This guide is a developer-focused setup walkthrough: a secure, sensible baseline for 26.04, plus the specific changes worth watching before you migrate workloads onto it.

First, decide if now is the moment

A brand-new LTS is rock-solid for fresh installs but worth a beat of caution for migrating existing fleets: third-party repositories, drivers, and niche packages sometimes lag a release by weeks. For a new project, install 26.04 today. For an existing 24.04 fleet running fine, plan the migration deliberately rather than rushing it on week one there is a companion comparison guide dedicated to exactly that upgrade decision.

The secure baseline, step by step

Whatever the version, a server's first hour should look the same: patch, create a non-root user, lock down SSH, enable the firewall, and automate security updates. Here is the modern baseline.

apt update && apt full-upgrade -y
adduser deploy
usermod -aG sudo deploy
# Copy your SSH key to the new user before you lock down SSH:
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

# /etc/ssh/sshd_config.d/99-hardening.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
# then: systemctl restart ssh

ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw allow 80,443/tcp
ufw enable

apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades
# Confirm security origins are enabled in
# /etc/apt/apt.conf.d/50unattended-upgrades

In practice that means the whole baseline above collapses into a cloud-init file your provider runs on first boot the server comes up already hardened, with no manual SSH session at all:

#cloud-config
users:
  - name: deploy
    groups: [sudo]
    shell: /bin/bash
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    ssh_authorized_keys:
      - ssh-ed25519 AAAA... you@laptop
ssh_pwauth: false                 # keys only, from the very first boot
package_update: true
package_upgrade: true
packages: [ufw, unattended-upgrades, fail2ban]
runcmd:
  - ufw default deny incoming
  - ufw allow OpenSSH
  - ufw allow 80,443/tcp
  - ufw --force enable
  - systemctl enable --now fail2ban     # ban repeated SSH brute-force attempts

Run your app as a service behind nginx

A hardened box is only half the job your app needs to run as a supervised service that restarts on crash and on reboot, behind a reverse proxy that terminates TLS. On modern Ubuntu that is systemd plus nginx, and it is worth getting into your provisioning too.

# /etc/systemd/system/app.service
[Unit]
Description=My app
After=network.target

[Service]
User=deploy
WorkingDirectory=/srv/app
ExecStart=/srv/app/.venv/bin/gunicorn app:app --bind 127.0.0.1:8000 --workers 4
Restart=always            # crash? reboot? systemd brings it back
RestartSec=3

[Install]
WantedBy=multi-user.target
# enable with: sudo systemctl enable --now app

# /etc/nginx/sites-available/app  — reverse proxy, TLS terminated here.
server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8000;     # to the systemd-managed app
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

What to watch on 26.04 specifically

Beyond the universal baseline, a new LTS shifts several things that touch developers directly. Check each of these against your stack before migrating.

A newer kernel and toolchain

An LTS ships a newer kernel (better hardware support and performance) and refreshed compilers and core libraries. Most software benefits, but anything pinned to an exact kernel module, a specific compiler version, or an older system library needs verification. Custom or out-of-tree kernel modules and proprietary drivers are the usual sticking points.

Updated language runtimes

The default system Python, and the packaged versions of other runtimes, advance with the release. Code or tooling relying on the old default can break on subtle version differences. The durable fix is to stop depending on the system runtime at all: pin your application's language version explicitly (containers, version managers, or vendored runtimes) so the OS upgrade cannot move it under you.

Packaging and default shifts

Ubuntu has been steadily moving packages between formats and changing defaults around things like network management and, increasingly, how some CLI tooling is delivered. The practical risk is a script that assumes a package is installed a particular way, or a default config file living where it used to. Audit your provisioning scripts for hardcoded paths and package assumptions.

The pre-migration checklist

The bottom line

Ubuntu 26.04 LTS is the sensible production baseline for new servers and a worthwhile, but deliberate, migration target for existing ones. The setup that matters most has not changed patch, non-root user, key-only SSH, default-deny firewall, automatic security updates, all driven from code. Layer on a staging rehearsal and a check of the release-specific kernel, runtime, and packaging shifts, and you will land on 26.04 with a server that is secure today and stays supported for years.