Laravel

Aprende Laravel: Deploy a producción

Autorangel cruz
Publicado
Lectura4 min de lectura
Aprende Laravel: Deploy a producción

Construiste, validaste y testeaste tu app. El último paso es sacarla del localhost y ponerla online. Hacer deploy de Laravel es, sobre todo, tres cosas: cumplir los requisitos del servidor, cachear todo para producción y apagar el modo debug. Este es el checklist y las opciones para no complicarte.

Requisitos del servidor

Tu servidor necesita PHP 8.3 o superior y las extensiones que Laravel usa: Ctype, cURL, DOM, Fileinfo, Filter, Hash, Mbstring, OpenSSL, PCRE, PDO, Session, Tokenizer y XML. La mayoría vienen por defecto en una instalación estándar de PHP.

Regla de oro: el docroot apunta a public/

El servidor web (Nginx, Apache) debe servir desde el directorio public/, dirigiendo todas las peticiones a public/index.php. Nunca muevas ese index.php a la raíz del proyecto: exponer la raíz deja tus archivos de configuración (y el .env) accesibles desde internet. También existe FrankenPHP como servidor moderno si quieres algo más simple que Nginx + PHP-FPM.

Permisos de directorios

Laravel necesita escribir en dos carpetas: storage y bootstrap/cache. El usuario del servidor web debe tener permiso de escritura ahí, o verás errores al primer request.

Optimización para producción

Aquí está el grueso del deploy. Laravel trae un comando que cachea configuración, eventos, rutas y vistas de una sola vez:

php artisan optimize

Por dentro corre los granulares, que también puedes usar sueltos:

php artisan config:cache   # combina la config en un solo archivo
php artisan route:cache    # cachea el registro de rutas
php artisan view:cache     # precompila las vistas Blade
php artisan event:cache    # cachea el mapeo de eventos

Y para las dependencias de Composer, en producción instalas sin las de desarrollo y con el autoloader optimizado:

composer install --optimize-autoloader --no-dev

Ojo con config:cache: una vez cacheada la configuración, el .env deja de leerse. Asegúrate de llamar a env() solo dentro de los archivos de config, nunca directo en tu código.

Para limpiar todas esas cachés (por ejemplo al depurar un deploy), tienes php artisan optimize:clear.

Apaga el debug (lo más importante)

En tu .env de producción:

APP_ENV=production
APP_DEBUG=false

APP_DEBUG en producción SIEMPRE debe ser false. Con true, un error muestra el stack trace completo con valores sensibles de tu configuración a cualquiera que visite el sitio.

El health check /up

Laravel incluye una ruta de salud en /up que devuelve 200 si la app arrancó sin errores, o 500 si algo falló. Es ideal para conectarla a un monitor de uptime, un load balancer o Kubernetes.

Reiniciar servicios de larga duración

Tras cada deploy, los procesos que quedan corriendo con el código viejo (workers de cola, Reverb, Octane) deben reiniciarse:

php artisan reload

¿Servidor propio o plataforma gestionada?

  • Laravel Cloud: plataforma gestionada y auto-escalable, hecha por el equipo de Laravel. Compute, base de datos, caché y storage administrados. La opción de menor fricción.
  • Laravel Forge: si prefieres tu propio VPS (DigitalOcean, Linode, AWS) pero no quieres configurar Nginx, MySQL y Redis a mano, Forge te los instala y administra.

Para una primera app en producción sin dolores de cabeza, una plataforma gestionada te ahorra toda la parte de sysadmin.

Siguiente Paso

Con esto completas la serie Aprende Laravel desde cero: de la instalación al deploy. El salto natural ahora es potenciar tu flujo con IA. Mira IA para desarrolladores Laravel o vuelve al índice en Aprende Laravel desde cero.

Preguntas Frecuentes

¿Qué necesito para hacer deploy de Laravel 13?

Un servidor con PHP 8.3+ y las extensiones requeridas, el docroot apuntando a public/, permisos de escritura en storage y bootstrap/cache, y las variables APP_ENV=production y APP_DEBUG=false.

¿Qué hace php artisan optimize?

Cachea de una sola vez la configuración, los eventos, las rutas y las vistas para producción, reduciendo el trabajo por request. Corre los comandos config:cache, route:cache, view:cache y event:cache.

¿Por qué APP_DEBUG debe estar en false en producción?

Porque con true cualquier error muestra el stack trace completo, incluyendo valores sensibles de tu configuración, a cualquier visitante. Es un riesgo de seguridad serio.

¿Conviene un servidor propio o una plataforma gestionada?

Para empezar, una plataforma gestionada como Laravel Cloud te evita configurar y mantener el servidor. Forge es el punto intermedio si quieres tu propio VPS pero con la configuración automatizada.

Recursos Adicionales