¿En qué versión de Laravel está, y sigue recibiendo correcciones?

Laravel publica una tabla de soporte, y es la página más útil de su sitio para cualquiera que sea dueño de una aplicación y no quien la escribe. Le dice, con fechas, si el framework sobre el que funciona su negocio sigue recibiendo correcciones.

Aquí está tal como se publica, al escribir esto:

Son las cifras de la propia Laravel. Lea las dos columnas de la derecha contra la fecha de hoy y tiene su respuesta.

Qué significan las dos columnas

Las correcciones de errores son el flujo de mantenimiento ordinario: algo se comporta de forma incorrecta, se corrige, y usted recibe la corrección en una versión de parche.

Las correcciones de seguridad continúan durante más tiempo, y cubren solo fallos con impacto en la seguridad. Una versión en esta ventana sigue siendo segura de ejecutar en el sentido de que las vulnerabilidades reportadas se parchean, pero sus defectos ordinarios ya son permanentes.

Después de las dos fechas, no se publica nada más para esa versión en absoluto.

La política detrás de la tabla es 18 meses de correcciones de errores y 2 años de correcciones de seguridad para cada versión, con una versión mayor nueva cada año hacia el primer trimestre. Ese es todo el modelo de planificación, y es más generoso de lo que parece a primera vista: significa que puede ir una versión entera por detrás y seguir recibiendo parches de seguridad.

Dónde deja eso hoy a la mayoría de las aplicaciones

Laravel 10 está completamente fuera de soporte desde febrero de 2025.

Laravel 11 pasó su fecha de correcciones de seguridad el 12 de marzo de 2026. Si está en 11, no llegará ninguna corrección más de ningún tipo.

Laravel 12 dejó de recibir correcciones de errores el 13 de agosto de 2026, lo bastante recientemente como para que quizá no se haya notado. Sigue recibiendo correcciones de seguridad hasta febrero de 2027, así que no hay emergencia, pero el reloj ya es visible.

Laravel 13 llegó el 17 de marzo de 2026 y es la única versión que recibe correcciones de errores actualmente.

Cómo comprobar dónde está

Desde el directorio de la aplicación:

php artisan --version

Si no puede ejecutar comandos en el servidor, busque en composer.json la línea laravel/framework. Muestra la restricción que el proyecto permite, como ^12.0. Para la versión instalada de verdad, composer.lock es la respuesta honesta: una restricción de ^12.0 le dice que es algún Laravel 12, no cuál.

Ya que está, compruebe su versión de PHP con php -v, porque las dos están vinculadas y la de PHP suele ser el obstáculo real. La tabla de arriba lista las versiones de PHP que soporta cada versión de Laravel, y solo avanzan.

Lo que cuesta de verdad quedarse sin soporte

No lo que la gente teme, y tampoco nada.

Su aplicación no deja de funcionar. No hay comprobación de licencia, ni fecha límite que desactive nada. Una aplicación en Laravel 10 que funciona hoy funciona exactamente igual que antes.

Lo que pierde son las correcciones futuras. Una vulnerabilidad encontrada en el framework el año que viene se parchea en las versiones soportadas y no en la suya. No hay notificación ni cambio visible el día que ocurre: sencillamente tiene un fallo sin parchear con una descripción pública de cómo funciona.

El coste más lento es que el ecosistema se aleja. Los paquetes dejan de soportar versiones antiguas del framework, así que un paquete del que necesite una corrección acabará exigiendo una versión de Laravel en la que no está. Lo mismo ocurre debajo: cada versión de Laravel soporta un rango de versiones de PHP, y PHP tiene su propio calendario de fin de soporte. Quedarse quieto significa acabar ejecutando un PHP sin soporte sobre un framework sin soporte, que es donde «deberíamos actualizar» se convierte en «no podemos actualizar sin un proyecto».

Y se vuelve más difícil cuanto más lo deja, que es la parte con la que conviene planificar. Cada salto tiene su propio conjunto de cambios incompatibles, y el trabajo de cuatro saltos juntos es peor que cuatro saltos por separado: con un año de diferencia, cada uno es un trabajo acotado contra una guía documentada. Cuatro años después, es un ejercicio de desenredar en el que un fallo podría venir de cualquiera de ellos.

Un calendario que funciona

Actualice una vez al año, poco después de que la nueva versión mayor se asiente. Laravel publica las versiones mayores hacia el primer trimestre, así que elija un mes a mitad de año, cuando la versión ha tenido tiempo de estabilizarse y los paquetes de los que depende se han puesto al día.

Haciéndolo así, siempre está dentro de la ventana de correcciones de errores, siempre a un salto documentado de la versión actual, y el trabajo se mantiene lo bastante pequeño como para caber en una semana normal en lugar de necesitar su propia partida presupuestaria.

Si ya va varias versiones por detrás, el mismo principio aplica a la inversa: vaya de una versión en una en lugar de apuntar directamente a 13. Cada versión tiene una guía de actualización escrita para la versión inmediatamente anterior, así que tomarlas en orden significa usar esas guías tal como se escribieron.

La pregunta que hacer a su desarrollador no es «¿estamos en la última versión?»; ir una por detrás es un sitio perfectamente razonable donde estar. Es «¿seguimos dentro de la ventana de seguridad, y cuándo nos quedamos fuera?». Eso tiene una fecha como respuesta, y puede ponerla en un calendario.

Actualizamos y mantenemos aplicaciones Laravel y los sistemas web construidos sobre ellas, incluidos los que van varias versiones por detrás. Si quiere saber dónde está la suya y qué haría falta para ponerse al día, cuéntenos qué está ejecutando.