Poner Composer en un VPS es, casi siempre, uno de esos pasos que conviene dar nada más tocar el servidor por primera vez. Da igual si vas a montar un WordPress con dependencias a medida, un Laravel, un Symfony o cualquier aplicación que tire de librerías externas: tarde o temprano lo vas a necesitar. En esta primera parte de la guía veremos qué es exactamente Composer, qué necesitas antes de instalarlo y el proceso completo con comandos ya probados. Y de paso, cómo desplegar dependencias como es debido con composer install y composer update.
Qué es Composer y por qué lo necesitas en tu VPS
Composer es, a día de escribir esto, el gestor de dependencias estándar de PHP. La idea es simple: declaras en un archivo composer.json las librerías que tu proyecto necesita, y él se encarga de descargar las versiones compatibles (junto con sus dependencias transitivas, que son más de las que parece al principio). Sin Composer, tendrías que bajar cada librería a mano, resolver conflictos de versiones con paciencia de santo y mantener todo al día de forma artesanal. En un proyecto serio, inviable.
En un VPS, la cosa se vuelve imprescindible por varios motivos:
- Despliegues reproducibles: el archivo composer.lock garantiza que tu servidor use exactamente las mismas versiones que tu entorno de desarrollo. Ni una de más, ni una de menos.
- Autoloading PSR-4: Composer genera el autocargador de clases que usan frameworks como Laravel o Symfony, y también WordPress con WooCommerce en instalaciones avanzadas.
- Seguridad: actualizar dependencias con un solo comando te permite aplicar parches de vulnerabilidades en minutos. Eso, antes, era una tarde entera de trabajo.
- Rendimiento de disco: en producción puedes usar composer install –no-dev para excluir herramientas de desarrollo y tests que no sirven de nada ahí.
¿Y si solo gestionas WordPress? Pues también. Cada vez más temas y plugins de calidad exigen Composer para instalar librerías como Guzzle o el SDK de AWS. Dicho esto, si tu VPS se atranca durante la instalación o la configuración, en RedServicio (redservicio.net) puedes encontrar ayuda profesional especializada en servidores y WordPress.
Requisitos previos antes de instalar Composer en VPS
Antes de ejecutar el instalador, revisa que cumples esto en tu VPS:
- Acceso SSH con privilegios: necesitas entrar como root o con un usuario con sudo.
- PHP 7.2.5 o superior instalado: Composer 2 lo exige. Lo compruebas con php -v.
- Extensiones PHP obligatorias: php-cli, php-mbstring, php-xml, php-curl y php-zip. Ojo con esta última: sin la extensión zip, Composer no podrá descomprimir paquetes.
- Git instalado (recomendado): muchos paquetes se clonan desde repositorios. Instálalo con apt install git o yum install git.
- Permisos correctos del directorio de proyecto: el usuario web (www-data en Debian/Ubuntu) debe poder escribir en las carpetas vendor y en la caché.
En Debian o Ubuntu, instala las dependencias previas con este comando:
sudo apt update && sudo apt install php-cli php-mbstring php-xml php-curl php-zip unzip git -y
Si usas CentOS, AlmaLinux o Rocky, el equivalente sería: sudo dnf install php-cli php-mbstring php-xml php-curl php-zip unzip git -y. Un error que veo a menudo: intentar instalar Composer con una versión de PHP del sistema antigua (PHP 7.0 en Ubuntu 18.04, por ejemplo, sin repositorio adicional). En ese caso, añade primero el repositorio Sury o Remi para tener PHP 8.x.
Instalar Composer en VPS paso a paso (comandos verificados)
El método oficial, y el más seguro, es el instalador con verificación de integridad. Son cuatro comandos, en este orden:
Primero, descarga el instalador: php -r «copy(‘https://getcomposer.org/installer’, ‘composer-setup.php’);»
Segundo, verifica la integridad del archivo comparando su hash SHA-384 con el publicado en la página de claves públicas de Composer. Si no coincide, no continúes. El archivo podría estar comprometido.
Tercero, ejecuta la instalación. Puedes instalarlo de forma global para tenerlo disponible en todo el sistema:
sudo php composer-setup.php –install-dir=/usr/local/bin –filename=composer
Cuarto, elimina el instalador: php -r «unlink(‘composer-setup.php’);»
Comprueba que todo va bien con composer –version. Deberías ver algo como Composer version 2.x.x. Si el comando no aparece, revisa que /usr/local/bin está en tu variable PATH. Un consejo práctico: si trabajas con varias versiones de PHP (por ejemplo, PHP 8.1 por defecto pero un proyecto en 8.3), puedes invocar Composer con la versión que toque usando php8.3 /usr/local/bin/composer. Esencial cuando los requisitos de dependencias difieren entre proyectos alojados en el mismo VPS.
Desplegar dependencias PHP con composer install y composer update
Composer instalado. Bien. Ahora toca gestionar las dependencias del proyecto, y aquí es donde más gente se tropieza: confundir los dos comandos principales tiene consecuencias, y no pocas.
composer install: el comando para desplegar
composer install lee el archivo composer.lock e instala exactamente las versiones que están registradas en él. Ni una más, ni una menos. Por eso es el comando correcto para producción: garantiza determinismo, es decir, el mismo resultado en cualquier servidor donde lo ejecutes. En un despliegue típico harías algo así:
composer install –no-dev –optimize-autoloader
¿Qué hace cada opción? –no-dev omite los paquetes que solo necesitas en desarrollo (PHPUnit, PHPStan, fábricas de datos…). Y –optimize-autoloader genera un mapa de clases que mejora el rendimiento en producción de forma notable. Nada exótico, pero marca diferencia.
composer update: reservado para desarrollo
composer update funciona al revés: ignora el lock, consulta Packagist, resuelve las versiones más recientes que cumplan tus restricciones y reescribe composer.lock. Suena inofensivo. No lo es. Ejecutarlo en producción es una mala práctica porque puedes desplegar una versión con cambios incompatibles, o con un bug sin probar, sin darte cuenta hasta que ya es tarde.
La regla de oro es sencilla: actualiza en desarrollo o staging, pasa los tests, y despliega el nuevo composer.lock al VPS con composer install.
Tip: ¿necesitas actualizar una sola librería de forma controlada? Usa composer update vendor/paquete (por ejemplo, composer update guzzlehttp/guzzle). Así no arrastras cambios no deseados al resto de dependencias.
Un detalle que acaba con más de un despliegue: los errores de memoria. Si te aparece algo como PHP Fatal error: Allowed memory size exhausted, puedes subir el límite de forma puntual con php -d memory_limit=512M /usr/local/bin/composer install, o usar COMPOSER_MEMORY_LIMIT=-1 para desactivarlo durante esa ejecución. En la segunda parte de esta guía veremos la optimización avanzada, la seguridad con composer audit y cómo resolver los conflictos de versiones más frecuentes.
Optimizar el autoloader y buenas prácticas en producción
El autoloader de Composer es de sus piezas más potentes, y también de las más desperdiciadas. La versión por defecto comprueba el sistema de archivos en cada carga de clase, algo que en producción es puro desperdicio cuando las dependencias ya están fijadas. En el servidor de producción, ejecuta:
composer dump-autoload –optimize –no-dev –classmap-authoritative
Con esto generas un classmap completo y eliminas las comprobaciones dinámicas. La ganancia real en proyectos medianos suele estar entre el 20% y el 40% en tiempo de carga de clases. Y al desplegar, no olvides la opción –no-dev para excluir las dependencias de desarrollo:
composer install –no-dev –optimize-autoloader –no-interaction
- Versiona composer.lock: en producción, composer update nunca. Instala siempre a partir del lock; es lo que garantiza builds reproducibles.
- Cachea paquetes: si despliegas con CI/CD, cachea el directorio ~/.cache/composer. Las instalaciones vuelan.
- Restringe scripts: si los hooks post-install no hacen falta en el servidor, usa composer install –no-scripts.
- Audita periódicamente: añade composer audit a tu pipeline para detectar vulnerabilidades conocidas en lo que tienes instalado.
Errores comunes al desplegar dependencias y cómo solucionarlos
1. «Your requirements could not be resolved»
El conflicto de dependencias más frecuente. Composer te indica qué paquetes chocan y con qué restricciones. Léelo entero, aunque dé pereza: casi siempre basta con ajustar una versión en composer.json o actualizar una dependencia transitiva. Para saber qué está bloqueando una actualización, composer why-not paquete/version es tu amigo.
2. «could not be fully loaded, invalid UTF-8» o clase no encontrada
Si una clase no aparece tras instalar, prueba a regenerar el autoloader con composer dump-autoload. Y en servidores con particiones NFS o discos lentos, el autoload optimizado también mitiga errores de timeouts al escanear archivos.
3. «The following exception is caused by a lack of memory»
Ya vimos cómo ampliar el memory_limit. Pero si el problema persiste en el update, hazlo en local y sube solo el composer.lock al VPS. De hecho, es la práctica recomendada en cualquier caso: resolver dependencias en el VPS consume recursos que el servidor necesita para servir tráfico.
4. Permisos incorrectos en vendor/
Tras instalar, comprueba que el usuario del servidor web (www-data, nginx) puede leer vendor/. Y algo que repito hasta la saciedad: nunca ejecutes Composer como root en el proyecto. Crea un usuario específico de despliegue y ajusta la propiedad con chown -R si hace falta.
¿Puedo borrar vendor/ y reinstalar sin riesgo? Sí, siempre que conserves composer.json y composer.lock. rm -rf vendor && composer install reconstruye exactamente el mismo estado. Ante instalaciones corruptas, es la solución más rápida.
Conclusión: Composer listo para tus proyectos en el VPS
Instalar Composer en VPS es solo el primer paso. Dominar el flujo completo —el gestor de dependencias, el autoloader optimizado, el control del memory_limit, las auditorías de seguridad— es lo que separa un despliegue frágil de uno profesional. Quédate con los pilares: instala siempre desde composer.lock en producción, excluye las dependencias de desarrollo, optimiza el autoloader con classmap autoritativo y automatiza la detección de vulnerabilidades con composer audit. Con esto, tus proyectos PHP sobre WordPress o frameworks modernos cargarán más rápido y serán bastante más seguros.
¿Y si te atascas? Conflictos de dependencias que no cesan, errores de memoria recurrentes, permisos rebeldes… pasa. Para esos casos, en RedServicio (redservicio.net) encontrarás ayuda profesional de expertos en administración de servidores y WordPress capaces de poner tu VPS a punto en tiempo récord.
