Implementar con éxito. Luego error 500: clase no encontrada. Alguien ejecutó composer update directamente en el servidor, la versión de la línea de comandos de PHP es 8.1 mientras que PHP-FPM ejecuta 8.2 y el archivo de bloqueo no se envió al repositorio. Composer en producción no es un administrador de paquetes en vivo: es un instalador reproducible desde un bloqueo fijo, validado en sentido ascendente.
Esta escena se repite cada semana en proyectos personalizados de Laravel, Symfony o PHP. La buena noticia: la ruta correcta se reduce a unas cuantas reglas simples. Lo malo: una sola excepción es suficiente para convertir un despliegue en una lotería.
instalar vs actualizar: la regla de oro
La distinción entre "instalación del compositor" y "actualización del compositor" no es sintáctica: separa dos mundos.
| Orden | Dónde ejecutarlo | Efecto |
|---|---|---|
actualización del compositor | IC local o de desarrollo | Recalcula versiones según compositor.json |
instalación del compositor | Construcción o producción de CI | Reproduce exactamente el bloqueo comprometido |
instalar --no-dev | Producción | Excluye dependencias require-dev |
instalar -o / --optimize-autoloader | Producción | Cargador automático PSR con rendimiento optimizado |
componer actualizaciónen producción significa sortear las versiones que cancelarán el pago esta tarde.
En el desarrollo, usted deliberadamente actualiza, prueba, confirma el nuevo bloqueo. En producción, usted instala lo que ya ha sido validado, nada más y nada menos.
Canal de implementación recomendado
Opción A: compilación de integración continua, implementación de artefactos. La integración continua ejecuta composer install --no-dev -o y luego realiza las pruebas. Archiva la versión (código más proveedor o proveedor independiente). La producción extrae el artefacto y reinicia los servicios, sin iniciar Composer en el servidor en vivo. Este es el enfoque preferible siempre que el tráfico o el equipo exceda de una persona.
Opción B: Redactar en el servidor. Obtiene una etiqueta Git inmutable, ejecuta composer install --no-dev -o --no-interaction, luego migra, borra el caché y recarga PHP-FPM. Aceptable para proyectos pequeños, pero frágil si la memoria del servidor es limitada o la red es inestable.
Errores comunes en la producción
PHP CLI diferente de PHP-FPM: una extensión de línea de comando faltante bloquea la instalación o genera un cargador automático incompatible con el tiempo de ejecución web.
Memoria insuficiente: los proyectos grandes de Symfony o Laravel consumen varios cientos de megabytes durante la instalación. Planifique una integración continua o un límite de memoria adecuado.
Permisos incorrectos: una carpeta de proveedor editable por el usuario web se convierte en una vulnerabilidad de seguridad.
Fuga del paquete de desarrollo: olvidar --no-dev expone PHPUnit u otras herramientas si la configuración web está bloqueada incorrectamente.
Plataforma de configuración: el campo config.platform.php en compositor.json alinea la resolución de dependencia con la versión de destino, incluso si la máquina local es más nueva.
Lo que el anfitrión debe permitir
Verifique que Composer 2.x esté disponible a través de SSH, que la versión de la línea de comandos de PHP coincida con PHP-FPM, que se pueda acceder a Git o un enlace de implementación y que haya suficiente memoria para una instalación, o que el host admita la implementación de artefactos sin Composer en el lado del servidor.
Para conocer los pasos posteriores a Composer, consulta nuestras guías Symfony y Laravel en producción.
La cumbre: El compositor se congela, no decide en producción
Decide y avanza sin puntos ciegos
Envíe el archivo compositor.lock al repositorio y trate cualquier cambio como cambio de código para probar. Configure la integración continua para ejecutar composer install --no-dev -o seguido de pruebas antes de cualquier implementación. Alinee PHP CLI y PHP-FPM con la misma versión y extensiones. Prefiere la implementación de artefactos tan pronto como el tráfico o el equipo lo justifique. Documente el comando exacto utilizado en producción para que nadie improvise una "actualización" un viernes por la noche.
Preguntas frecuentes
¿Deberíamos ejecutar la actualización del compositor en producción?
No. La producción ejecuta "composer install" desde un archivo de bloqueo confirmado en el repositorio. El comando "actualizar" recalcula nuevas versiones de dependencias; está reservado para el entorno de desarrollo o la integración continua, después de la ejecución de pruebas automatizadas.
¿Por qué --no-dev en prod?
PHPUnit y las herramientas de desarrollo aumentan la superficie de ataque y el tamaño de la carpeta del proveedor. No deberían estar presentes en un servidor de producción, donde cada paquete innecesario puede convertirse en una puerta de enlace o un cuello de botella en la implementación.
¿Debería versionarse Composer.lock?
Sí para aplicaciones (Laravel, Symfony, proyecto personalizado). No para las bibliotecas Composer publicadas. Para un sitio o una aplicación, el bloqueo garantiza la reproducibilidad entre desarrolladores, la integración y la producción continuas.
¿Error de memoria de instalación de Composer?
Puede aumentar temporalmente el límite con COMPOSER_MEMORY_LIMIT=-1 o agregar swap. Mejor aún: ejecute la instalación en integración continua e implemente un artefacto que contenga la carpeta del proveedor.
En producción, Composer repite, no improvisa. Si el bloqueo está ausente, también lo está el despliegue.