Ubuntu Server en 2026: elegir entre versiones LTS (y actualizar)
Hay tres versiones LTS de Ubuntu en servicio ahora mismo: la 22.04 se acerca al final de su soporte estándar, la 24.04 está en sus cómodos años intermedios, y la nueva 26.04 «Resolute Raccoon» llega con Linux 7.0. Cuál corresponde a tu servidor depende de en qué punto del ciclo estés, y la respuesta es distinta para despliegues nuevos y para flotas existentes. Esta guía ofrece la tabla de ventanas de soporte, lo que realmente cambió en 26.04 para quienes operan servidores, las razones honestas para quedarte en 24.04 por ahora, y la mecánica de la actualización, incluida la fecha de agosto de 2026 en la que se abre la ruta de LTS a LTS.
Loading...
Respuesta directa
- ¿Servidor nuevo hoy? Despliega 24.04 LTS o 26.04 LTS: 26.04 si quieres el nuevo kernel y un reloj de soporte que llega hasta 2031, 24.04 si algún repositorio de terceros del que dependes todavía no ha publicado paquetes de 26.04 (compruébalo antes de comprometerte; tres meses después del lanzamiento, algunos todavía no lo han hecho).
- ¿Tienes 24.04? Vas bien: soporte estándar hasta 2029, y la actualización in situ sancionada a 26.04 solo se abre con la versión puntual 26.04.1, prevista para agosto de 2026. Sin prisa; actualiza según tu propio calendario entre ese momento y 2029.
- ¿Tienes 22.04? Empieza a planificar ya. El mantenimiento de seguridad estándar termina en primavera de 2027, y tu ruta hacia 26.04 son dos saltos (22.04 → 24.04 → 26.04). Programa esos saltos, o activa Ubuntu Pro para ganar tiempo hasta 2032.
- ¿Tienes una versión intermedia (no LTS) en un servidor? Pásate a una LTS: las versiones intermedias reciben nueve meses de soporte y existen para early adopters y escritorios, no para servidores de producción.
El panorama
| Versión | Kernel (GA) | Fin del soporte estándar | Con Ubuntu Pro | Pro + complemento Legacy |
|---|---|---|---|---|
| 22.04 «Jammy» | 5.15 | primavera de 2027 | 2032 | 2037 |
| 24.04 «Noble» | 6.8 (HWE: más reciente) | 2029 | 2034 | 2039 |
| 26.04 «Resolute» | 7.0 | abril de 2031 | 2036 | 2041 |
Fechas según el ciclo de versiones de Canonical; la precisión a nivel de mes se desplaza de vez en cuando, así que planifica en trimestres, no en días. Dos notas estructurales: cada LTS recibe cinco años gratuitos de mantenimiento de seguridad para el repositorio main; el repositorio universe, muy usado, recibe cobertura sistemática mediante el ESM de Ubuntu Pro (gratis hasta cinco máquinas, más detalles más abajo en «Ubuntu Pro»). Y a mitad de vida de la LTS, la pila HWE (hardware enablement) ofrece kernels más nuevos sobre versiones más antiguas: las versiones puntuales de 24.04 llevan kernels mucho más allá de 6.8, que a menudo es todo lo que realmente exige «necesito controladores más nuevos».
Qué cambia 26.04 para quienes operan servidores
Resolute Raccoon (publicada el 23 de abril de 2026) es un paso de plataforma mayor que el de una LTS típica. Los puntos que importan en servidores:
- Linux 7.0. Más un hito de numeración de versiones que uno arquitectónico: upstream renumeró tras la 6.19, así que 7.0 es el siguiente kernel normal, no una reescritura. Lo que realmente obtienes frente al 6.8 de 24.04: dos años más de hardware enablement, mejoras en io_uring y en redes, y trabajo en el planificador.
- systemd 259 elimina cgroup v1 por completo. El actualizador de versión se niega a ejecutarse en sistemas que aún usan v1. Todo lo moderno ya está en v2 (confírmalo con
mount | grep cgroup2); las víctimas son motores Docker antiquísimos e instalaciones LXC viejas; arréglalas antes de actualizar el sistema operativo, no durante. - OpenSSH 10.2 con intercambio de claves poscuántico por defecto y DSA eliminado por completo.
- APT 3.1 con el nuevo solucionador y una CLI más limpia.
- Espacio de usuario seguro en memoria:
sudo-rsy los coreutils de Rust sustituyen por defecto a sus antecesores en C. La compatibilidad es alta, pero los scripts que dependen de un comportamiento oscuro de las opciones desudo/cp/datemerecen una ronda de pruebas. - Asperezas reportadas hasta ahora: Postfix ya no va en chroot por defecto (revisa tu configuración al actualizar), los montajes de medios extraíbles se mudaron de
/mediaa/run/media(rompe scripts), el kernel 7.0 abandona series de drivers NVIDIA muy antiguas, y las notas de publicación registran una regresión de rendimiento de PostgreSQL bajo configuraciones concretas. Si tienes una máquina con carga intensa de bases de datos, lee los problemas conocidos actuales antes de programar el cambio.
Ninguno de estos puntos es motivo para evitar 26.04; todos son motivos para actualizar de forma deliberada en lugar de a la ligera.
El argumento honesto para quedarte en 24.04 (por ahora)
- Los repositorios de terceros van con retraso. Las PPA y los repositorios de proveedores (bases de datos, PHP, agentes de monitorización) publican para una nueva LTS según su propio calendario. Si
apt updateen 26.04 fuera a dejar atrás alguna dependencia crítica, eso es decisivo. Espera. - La regla del .1 existe por algo. El propio Canonical no ofrece la actualización a los usuarios de LTS existentes hasta la 26.04.1 (prevista para agosto de 2026): la primera versión puntual absorbe los arreglos de la ventana de lanzamiento. Las flotas en producción rara vez pierden algo por respetar esa barrera.
- Tu reloj no corre. 24.04 tiene soporte gratuito hasta 2029. Actualizar a finales de 2026 o durante 2027 es una postura perfectamente actual.
La otra cara: las máquinas nuevas no cargan con riesgo de migración, así que desplegar 26.04 desde cero hoy, allí donde tus dependencias lo permitan, pone en marcha el periodo de soporte más largo posible.
Ubuntu Pro y ESM, en breve
Ubuntu Pro convierte los cinco años de cada LTS en diez (más un complemento «Legacy» que llega a quince), añade cobertura ESM para el repositorio universe, Livepatch (parches de seguridad del kernel sin reinicio), y las herramientas de hardening de USG (perfiles CIS/DISA-STIG). Es gratis hasta cinco máquinas, y tiene un precio de catálogo de 500 $/servidor/año a partir de ahí (los SLA de soporte cuestan más; los precios cambian, comprueba el actual).
Cuándo se rentabiliza: en flotas que no pueden seguir la cadencia de actualización (Pro convierte «tienes que dejar 22.04 antes de 2027» en «antes de 2032»), en regímenes de cumplimiento que quieren artefactos FIPS/CIS, y para cualquiera cuyos paquetes críticos vivan en universe. Cuándo no: en una flota pequeña y bien cuidada que actualiza en cada ciclo de LTS y toma la mayoría de main. El nivel gratuito cubre tus primeras cinco máquinas de todos modos.
Actualizar in situ
La ruta sancionada es do-release-upgrade, de LTS a LTS, un salto cada vez: las máquinas con 22.04 pasan por 24.04. La mecánica, resumida (la disciplina más completa para servidores remotos es la misma que en nuestra guía de actualización de Debian; las precauciones se trasladan tal cual):
apt update && apt full-upgrade # be fully current first
# backups + snapshot; then, inside tmux:
do-release-upgrade # offers 26.04 once 26.04.1 is out
Antes de empezar: verifica cgroup v2 (mount | grep cgroup2), comprueba de nuevo que cada repositorio de terceros ya ofrece paquetes de 26.04 (el actualizador los desactiva durante el proceso; los reactivas después), y ten probado el acceso a la consola fuera de banda. En un servidor dedicado, KVM-over-IP es la diferencia entre «contratiempo interesante» y «reaprovisionar». Después: systemctl --failed, pruebas de humo de los servicios, y reactiva tus repositorios.
Preguntas frecuentes
¿Es Ubuntu 26.04 ya lo bastante estable para producción?
Para despliegues nuevos, sí, con la salvedad habitual: contrasta la lista actual de problemas conocidos con tu carga de trabajo (la nota sobre la regresión de PostgreSQL es el ejemplo obvio) y confirma que tus repositorios de terceros ya publican paquetes de 26.04. Para actualizaciones in situ de máquinas existentes, la respuesta es la propia barrera que impone Canonical: el actualizador no ofrece 26.04 a los usuarios de LTS hasta la 26.04.1 en agosto de 2026, y eso es un valor por defecto sensato para flotas en producción, no burocracia.
¿Debería alguna vez ejecutar versiones intermedias (25.10, 26.10…) en un servidor?
Casi nunca. Las versiones intermedias reciben nueve meses de soporte, lo que en un servidor implica una migración de sistema operativo más de una vez al año solo para seguir parcheado. Su propósito es anticipar lo que contendrá la próxima LTS. El único uso defendible en un servidor es una máquina de vida corta que necesita de verdad una función meses antes de la próxima LTS, e incluso entonces, un contenedor o un kernel HWE sobre la LTS actual normalmente te lleva ahí con menos trastorno.
Necesito un kernel más nuevo en 24.04. ¿Tengo que actualizar a 26.04?
Normalmente no: instala la pila HWE (apt install linux-generic-hwe-24.04), que sigue kernels más nuevos a través de las versiones puntuales de la LTS. Esa es la respuesta pensada para «hardware nuevo, espacio de usuario estable». Actualiza el sistema operativo cuando quieras la nueva plataforma (systemd, OpenSSL, pilas de lenguaje), no solo el kernel.
¿Ubuntu o algo completamente distinto?
Si estás sopesando distribuciones en lugar de versiones, ese es otro artículo: Ubuntu vs Debian cubre la alternativa más cercana, y cómo elegir una distribución Linux traza todo el terreno, incluida la familia RHEL. La versión corta: la cadencia de LTS de Ubuntu y las ventanas de Pro son sus elementos diferenciadores; si eso no tiene valor para ti, el abanico se abre.
Desplegar en Serverside
Desplegamos tus servidores dedicados Ubuntu con la versión LTS compatible que elijas en menos de un minuto, en nuestra red ASN 55285 con mitigación DDoS siempre activa y firewall perimetral en autoservicio. KVM-over-IP viene de serie, justo la red de seguridad fuera de banda que asume la sección sobre la actualización in situ, y cuando prefieras empezar limpio en 26.04 en vez de actualizar in situ, el reaprovisionamiento en menos de un minuto convierte la instalación nueva seguida de restauración en una estrategia real en lugar de un último recurso.
Después de desplegar: la lista de verificación de hardening de la primera hora, y reglas de firewall por defecto sensatas.

Escrito por
Co-founder & CTO, Serverside.com
Jesse is the co-founder and CTO of Serverside.com, where he leads the engineering behind the company's bare-metal cloud: from the ASN 55285 backbone to the core automation that drives day-to-day operation. He writes about dedicated servers, operating systems, and running production workloads on bare metal.
Seguir leyendo
Ver todos los artículos¿Te ha gustado este artículo?
Recibe nuevas guías y artículos técnicos en tu correo. Sin spam, cancela cuando quieras.




canadiense y
neerlandés