Un desarrollador implementa Laravel en un VPS "idéntico a las instalaciones". El archivo .env se copia con APP_DEBUG=true, la cola permanece en el controlador sync, el programador no existe, el directorio storage/ no es accesible para escritura. La máquina es correcta. El entorno de producción no lo es. Laravel requiere que el componente de hardware esté claramente separado de la configuración de la aplicación; de lo contrario, cada implementación se convierte en una lotería.
La confusión sigue surgiendo en el soporte: compramos un servidor "listo para Laravel" porque PHP 8.3 está instalado, luego nos olvidamos de almacenar en caché rutas y vistas, iniciar trabajadores o bloquear permisos. El servidor ejecuta el código; el entorno decide si se ejecuta en modo de demostración o en modo de producción. Mientras estas dos tarjetas no se lean por separado, los incidentes parecen errores de aplicación aunque provengan de la implementación.
Servidor y entorno: dos tarjetas separadas
El servidor incluye el sistema operativo, nginx o Apache, PHP-FPM, Redis posiblemente, parches de seguridad. El entorno incluye el archivo .env, APP_KEY, las URL de la base de datos, la configuración de correo, el controlador de cola y los cachés de Laravel (config:cache, route:cache, view:cache). La capa build agrega composer install --no-dev y compilación Fast o Mix. La capa runtime agrega los trabajadores supervisados y la línea cron que llama a schedule:run cada minuto.
| Capa | Ejemplos | Error común |
|---|---|---|
| Servidor | nginx, PHP-FPM 8.2, Redis | Cree que PHP instalado = listo para producción |
| Medio ambiente | .env, APP_KEY, QUEUE | .env de puesta en escena copiada en vivo |
| Construir | Redactar sin desarrollo, activos compilados | Dependencias de desarrollo en producción |
| Tiempo de ejecución | trabajadores, planificador | Trabajos en sync, cron ausente |
Un servidor preparado para Laravel mal configurado sigue siendo una aplicación Laravel en modo de demostración.
Lista de verificación de implementación que se mantiene
Las variables de entorno deben mostrar APP_ENV=producción, APP_DEBUG=false, claves únicas y URL correctas. Las dependencias pasan por composer install --no-dev --optimize-autoloader. Los activos frontales se compilan en CI o se implementan localmente; php crafts store:link crea el enlace simbólico esperado. Después de cada implementación, regenere las cachés, rutas y vistas de configuración. El usuario de PHP-FPM debe poder escribir en los directorios storage/ y bootstrap/cache/.
Las colas requieren Supervisor o systemd con Redis o una tabla dedicada; Esté atento a los trabajos_fallidos. El programador requiere una entrada cron * php artisan Schedule:run. Las migraciones se inician con migrate --force solo después de guardar la base de datos. Cada paso se puede automatizar (Forjar, Enviar, Acciones de GitHub, Implementar), pero la lista sigue siendo la misma ya sea que haga clic o escriba un script.
Elija el host más allá del procesador
Un host Laravel creíble ofrece PHP reciente, extensiones documentadas, Redis instalable o administrado, SSH, cron confiable y una ruta de implementación no disruptiva: publique un enlace simbólico o implementación gradual si el tráfico es crítico. Un entorno de preparación mínimo con .env separado evita sorpresas desagradables. Compartido puede ser suficiente para una aplicación pequeña; Tan pronto como entran en juego las colas y los trabajadores, el VPS o plataforma administrada se convierte en la norma.
Alinee la versión de PHP con Elija una versión de PHP y las dependencias con Composer en producción. Octane y Horizon agregan complejidad útil solo después de comprobar el cuello de botella de FPM o la necesidad de crear paneles en archivos de Redis.
La cumbre: el despliegue exitoso es invisible
Busque hosts PHP en el directorio y compare ofertas con Redis y acceso SSH a través de la comparación.
Decide y avanza sin puntos ciegos
Versione un modelo .env.production sin secretos e inyecte las claves a través de su canalización o administrador de secretos. Automatice la implementación con pasos de caché, migración y reinicio de trabajadores en orden documentado. Configure Supervisor para colas y pruebe una reversión a la versión anterior antes del primer incidente real. Supervise los failed_jobs y los registros de aplicaciones tan pronto como se publiquen. Finalmente, verifique que el programador esté realmente ejecutándose; a menudo se nota que falta un cron tres semanas después, cuando los informes ya no llegan.
Preguntas frecuentes
¿Cuál es la diferencia entre el servidor y el entorno Laravel?
El servidor designa la máquina: sistema, servidor web, versión de PHP. El entorno designa el contexto de la aplicación: archivo .env, valor APP_ENV=production, cachés de configuración y claves API. Confundir los dos lleva a APP_DEBUG=true en claves de producción o de preparación en línea.
¿FPM o Laravel Octane en producción?
PHP-FPM sigue siendo la opción sólida por defecto. Octane con Swoole o RoadRunner puede ganar en una API de alto tráfico, pero impone restricciones de compatibilidad en los paquetes. Comience con FPM a menos que el punto de referencia demuestre lo contrario.
¿Cómo gestionar las colas de Laravel?
Supervisor o systemd deben reiniciar queue:work o queue:listen. Utilice Redis o una cola de base de datos; nunca el controlador de "sincronización" en producción para correos electrónicos y trabajos pesados.
¿Qué pedirle a un host para Laravel?
PHP 8.2 o posterior, Composer, Redis, cron confiable, acceso SSH, extensiones útiles (intl, bcmath, pcntl para trabajadores) y un procedimiento de implementación documentado y sin problemas.
En Laravel, la producción comienza cuando .env dice producción, no cuando DNS apunta al VPS.