Choosing a Linux distribution for a cloud server

Distribution choice generates more heated opinion than almost any decision of comparable consequence. For a cloud server the practical considerations are narrower and less contentious than the debate suggests.

Three things matter: how long it is supported, how current the packages are, and how likely it is that a search for your specific error returns a useful answer.

Support lifetime, which matters most

A server distribution’s support window determines how often you have to perform a major upgrade, which is the most disruptive routine maintenance a server sees.

Long-term support releases typically offer around five years of security updates, sometimes extendable. Enterprise distributions offer around ten. Short-cycle releases offer months.

For anything you intend to leave running, choose a long-term support release. The temptation to take the newest release for slightly newer packages is almost always a bad trade: you gain marginally fresher software and commit to a disruptive upgrade far sooner.

Check the actual end-of-life date before provisioning rather than assuming. Deploying onto a release with eighteen months of support remaining means an upgrade project sooner than anyone planned.

Package currency, and the trade it involves

Distributions sit on a spectrum between stable and current.

Stable-leaning distributions freeze package versions at release and backport security fixes. Your runtime will be the version available at release, possibly several years old. Nothing changes underneath you, which is exactly what you want for a server and exactly what frustrates developers who need a newer language runtime.

Current-leaning distributions ship newer packages more often. You get modern versions without extra work, at the cost of more change.

The pragmatic resolution used by most teams is to take a stable distribution and get the runtime from somewhere else: a language version manager, an upstream repository, or a container image. That separates the operating system’s stability from the application’s currency, which is the right separation.

The realistic shortlist

Ubuntu LTS is the default for good reasons. It is the most widely deployed cloud distribution, which means documentation, tutorials, error messages and third-party install instructions overwhelmingly assume it. Five years of standard support, predictable two-year release cadence. If you have no strong reason to choose otherwise, this is the safe answer.

Debian Stable is the choice for maximum stability and minimum surprise. Fewer defaults are set for you, packages are older, and the project’s conservatism is a feature. Excellent for a server you intend to leave alone. Very close to Ubuntu in practice, since Ubuntu derives from it, so most documentation transfers.

Enterprise distributions and their community rebuilds suit organisations standardising on a vendor-supported platform, or where compliance frameworks and commercial software specify them. Long support windows, a different package manager, and a security framework worth learning if you use it.

Alpine is a specialist choice, primarily inside containers, valued for very small images. It uses a different C library, which occasionally breaks software that assumes otherwise. Not a general-purpose server distribution for most teams.

Rolling-release distributions are excellent workstations and a poor fit for unattended servers, because packages change continuously and unattended upgrades can surprise you.

The consideration people underweight

Search results.

When something breaks at an inconvenient hour, the value of a distribution is largely determined by whether pasting the error message into a search engine returns a relevant answer. Popularity is genuinely a technical merit here, and it is the strongest argument for choosing a mainstream option unless you have a specific reason not to.

The same applies to third-party software. Install instructions, official repositories and support documentation disproportionately assume the most common distributions.

Making the choice quickly

1. Is a distribution mandated by compliance, by commercial software support, or by an existing estate? If so, that decides it.
2. Does the team already administer one comfortably? Familiarity beats marginal technical differences, and consistency across an estate has real operational value.
3. Otherwise take the current Ubuntu LTS, and check its end-of-life date is far enough out.
4. Get your language runtime from upstream or a container, rather than choosing a distribution based on which version it packages.

After choosing

Whichever you pick, the first-hour work is the same: enable unattended security updates, configure the firewall, disable password SSH authentication, and set up log rotation.

And write down which release you deployed, along with its end-of-life date, somewhere you will see it. The most common distribution problem in practice is not choosing wrongly; it is running something unsupported for two years without noticing.

If you are weighing providers rather than techniques, our cloud account catalogue lists what each one is strongest at, alongside the configurations available.

For the vendor’s own reference on the services involved here, see the Hetzner documentation.

This is cheap to practise on, which is rather the point of Hetzner. Our Hetzner accounts come in five configurations, and the cloud account catalogue sets out the alternatives.

Questions people ask