Ubuntu dedicated servers

An Ubuntu dedicated server is a physical, single-tenant machine that runs Ubuntu Server directly on the hardware — no virtualisation layer between your workload and the CPU, memory, and NVMe. You get full root, every core, and predictable performance, rather than a slice of a shared host.

Ubuntu is the most widely deployed server Linux, which is exactly why it is the safe default: the largest package base, first-class cloud-init automation, and the deepest pool of tutorials, images, and upstream support for Docker, Kubernetes, and virtually every runtime you might deploy.

Comparing distributions? Read our Linux dedicated server guide.

LTS versions and the release cadence

Ubuntu ships a Long Term Support (LTS) release every two years, in April of even-numbered years, with interim releases every six months in between. For servers you almost always want an LTS: five years of standard security maintenance, extended to ten years with Ubuntu Pro, and up to twelve with the paid Legacy Support add-on layered on top of Pro.

We provision the current and previous LTS by default, so you can standardise a fleet on a version and stay on it through its support window rather than being forced onto a rolling target. If you need an interim release for a newer kernel or userland, that is available on request.

When you are ready to move between LTS releases, do-release-upgrade handles the jump in place; because you have full root and a KVM console, you drive the upgrade — or a clean reinstall onto the newer LTS — on your own schedule, with no version lock and nothing forced from our side.

Ubuntu Pro, ESM, and Livepatch

Ubuntu Pro extends security coverage beyond the "main" repository to the far larger "universe" set, and adds kernel Livepatch for applying critical kernel CVEs without rebooting — useful when uptime on a bare-metal host matters. Canonical offers Pro free for personal and small-scale use; commercial fleets attach a subscription.

Because you have full root on a Serverside machine, you are free to attach your own Ubuntu Pro token, run Landscape, or manage patching entirely yourself — we do not lock the OS.

Boot your own Ubuntu with custom iPXE

You are not limited to our stock images. Custom iPXE configurations let you chain-boot your own Ubuntu build or a custom kernel straight onto the metal, so the machine comes up running exactly the image you signed off on.

The same path can run Ubuntu entirely in memory — a diskless, RAM-only root that leaves the local NVMe free for data or wiped clean on every boot. It is the strongest expression of the same theme: we hand you the hardware and stay out of the boot chain.

apt and snap: what you actually run

Ubuntu is built on dpkg/apt, and that is where the vast majority of server software lives. Ubuntu also ships snap, Canonical’s confined packaging format, which some server operators prefer for self-updating daemons and others disable to keep the base minimal.

On a dedicated server the choice is entirely yours: keep snapd, remove it, or pin everything to apt. Nothing in our provisioning depends on it.

What teams run on Ubuntu bare metal

Ubuntu’s ubiquity makes it the path of least resistance for container and orchestration workloads in particular — official Docker and Kubernetes images, runtimes, and CI runners all target it first.

• Container hosts and Kubernetes nodes (kubeadm, k3s, RKE2) that want raw CPU and NVMe without a hypervisor tax
• High-throughput web and API tiers where the full uplink and included DDoS mitigation matter
• Self-hosted databases and caches (PostgreSQL, MySQL, Redis) on local NVMe
• CI/CD runners and build farms that churn through cores
• Game and voice servers — our DDoS profiles are tuned per title for the games hosted across our network

Securing an Ubuntu server

Ubuntu’s default mandatory-access-control layer is AppArmor (not SELinux), which ships enabled with profiles for common daemons and is generally simpler to reason about.

Before traffic ever reaches the host stack, our self-service DDoS mitigation and firewall rule management filter it at the network edge. That gives you a layered defence: network-level filtering you control out front, with ufw and AppArmor enforcing policy on the box itself. Virtual private networking between your servers keeps east-west traffic — database replication, Kubernetes node-to-node — off the public interface entirely.

A sensible baseline on a fresh Serverside box:

• Enable unattended-upgrades so security patches land automatically
• Lock down SSH: key-only auth, no root password login, and our network-level filtering in front
• Turn on ufw and expose only the ports your workload needs
• Keep AppArmor in enforce mode; add profiles for anything custom
• Add Ubuntu Pro + Livepatch if you need kernel CVE coverage without reboots