Choosing is two decisions, and most people make only the first. The first is the distribution: run what your team, client or host already runs, because shared runbooks beat any technical difference. Otherwise take the current Ubuntu 225 LTS, which this book's examples assume.
The second decision costs money later: every release has a date after which security fixes stop, and that date is a fact about your project.
| Distribution and version | Released | Standard support ends | Extended support |
|---|---|---|---|
| Ubuntu 26.04 LTS | 23 Apr 2026 | May 2031 | May 2036 (Pro) |
| Ubuntu 24.04 LTS | 25 Apr 2024 | May 2029 | May 2034 (Pro) |
| Debian 13 319 "Trixie" | 9 Aug 2025 | 9 Aug 2028 | 30 Jun 2030 (LTS) |
| Debian 12 "Bookworm" | 10 Jun 2023 | 12 Jul 2026 | 30 Jun 2028 (LTS) |
| RHEL 10 664 | 20 May 2025 | 31 May 2030 | 31 May 2039 (ELS) |
| Rocky Linux 10 11,029 | 11 Jun 2025 | 31 May 2030 | 31 May 2035 |
| AlmaLinux 10 7,122 | 27 May 2025 | 31 May 2030 | 31 May 2035 |
| Fedora 44 1,480 | 28 Apr 2026 | 2 Jun 2027 | none |
Three rules follow. Deploy on a release in its first year: an LTS adopted in year four leaves one comfortable year, then an unbudgeted migration. Never put an interim Ubuntu or a Fedora under a production site. Record the end-of-support date on day one, beside the domain expiry and the certificate renewal.