Categoría: Web y aplicaciones
Aplicaciones PHP con Laravel o Symfony: despliegue, colas y servidor gestionados
Vuestro equipo escribe el código; nosotros nos ocupamos de que llegue a producción sin cortes, de que las colas no se queden paradas y de que el servidor aguante el día que más tráfico tenéis.
- Dónde se monta
- En vuestra cuenta, a vuestro nombre
- Copias
- Con restauración probada
- Actualizaciones
- Planificadas y documentadas
- Licencia
- Open source: Laravel y Symfony, MIT
En resumen
Laravel y Symfony son los dos marcos de trabajo de PHP más usados para aplicaciones web y APIs. Preparamos el servidor o los contenedores en vuestra cuenta, montamos despliegues automáticos desde Git sin corte de servicio, mantenemos vivos los workers de colas y el scheduler, ajustamos PHP-FPM y OPcache, y vigilamos errores, colas y tiempos de respuesta. El código sigue siendo de vuestro equipo.
¿Qué nos encargamos de mantener?
Una aplicación de Laravel o Symfony en producción es más que la web: hay workers procesando colas, tareas programadas, una base de datos, a menudo Redis y una configuración de PHP que nadie revisa desde que se instaló. Esto es lo que dejamos bajo control:
Despliegues
Desde Git, sin corte, con migraciones y cachés generadas y vuelta atrás inmediata.
Colas
Workers supervisados con Supervisor o systemd, o Horizon; reinicio ordenado y trabajos fallidos a la vista.
Scheduler
Tareas programadas que se ejecutan una vez, a su hora, aunque haya varios servidores.
PHP-FPM y OPcache
Procesos, memoria y versión de PHP ajustados a vuestra aplicación y a vuestro tráfico.
Datos
MySQL, MariaDB o PostgreSQL, y Redis o Valkey, con copias fuera y restauración probada.
Monitorización
Errores, colas que crecen, workers caídos, tiempo de respuesta, disco y certificados.
¿Cómo es un despliegue?
Seguimos el modelo de versiones en carpetas que usan herramientas como Deployer, o una imagen de contenedor nueva por versión si la aplicación ya va en contenedores:
Preparar
Se descarga el código de la etiqueta o rama, se instalan dependencias con Composer sin las de desarrollo y se compilan los recursos del frontal.
Optimizar
Se generan las cachés de configuración, rutas y vistas en Laravel, o la caché del contenedor en Symfony.
Migrar
Se ejecutan las migraciones de base de datos, con una copia previa si tocan tablas grandes.
Activar
El enlace de la versión activa cambia, PHP-FPM se recarga para limpiar OPcache y los workers se reinician.
Las variables de entorno y los secretos viven fuera del repositorio, en el servidor o en el gestor de secretos del proveedor. Si queréis montar todo el circuito de integración continua, lo tratamos en infraestructura como código, GitOps y CI/CD.
¿Qué problemas encontramos más a menudo?
- Workers con código viejo: se despliega una versión nueva, pero los procesos de colas siguen con la anterior en memoria.
- Scheduler duplicado: varios servidores ejecutan la misma tarea programada a la vez.
- Colas que crecen en silencio: los procesos están vivos, pero no dan abasto y nadie mira el tamaño de la cola.
- PHP fuera de soporte: la aplicación sigue en una versión de PHP sin parches de seguridad.
- Modo depuración activado en producción: errores con rutas, variables y consultas visibles para cualquiera.
- Despliegue a mano por SSH: un git pull en el servidor y una caché sin regenerar.
¿Cómo tratamos las colas y el scheduler?
En Laravel, cada conexión de colas tiene sus workers con un límite de tiempo y de memoria por trabajo; si usáis Redis, Horizon da un panel con el estado de cada cola y lo dejamos protegido. En Symfony, los consumidores de Messenger corren igual, supervisados y con un número máximo de mensajes antes de reiniciarse para no acumular memoria. El scheduler se lanza desde el cron del sistema o como proceso propio, y si hay varios servidores nos aseguramos de que cada tarea corra en uno solo. Cuando la mensajería crece hasta necesitar un broker propio, lo montamos como en RabbitMQ gestionado.
¿Cómo hacemos copias y actualizaciones de PHP?
La base de datos se copia con el método que corresponda a su motor, y los archivos subidos por usuarios, si no están ya en un almacenamiento de objetos, también salen fuera del servidor. Restauramos de prueba con regularidad. Para cambiar de versión de PHP preparamos un entorno con la versión nueva, vuestro equipo pasa allí sus pruebas y revisamos los avisos de funciones obsoletas; después cambiamos producción servidor a servidor. Las versiones de parches de PHP y del sistema operativo se aplican en cuanto salen. Si la base de datos necesita réplicas o recuperación a un minuto concreto, la llevamos como en PostgreSQL gestionado o MySQL y MariaDB gestionados.
¿Contenedores o servidores?
Las dos opciones funcionan. Servidores con Nginx y PHP-FPM son lo más sencillo de operar para una aplicación con tráfico estable. Contenedores tienen sentido si ya los usáis en desarrollo, si queréis el mismo entorno en todas partes o si pensáis escalar la parte web por separado de los workers. Si preferís un panel donde vuestro equipo despliegue solo, encaja con Coolify y Dokploy gestionados. Si queréis que alguien responda de la aplicación en producción cada mes, está en el SRE como servicio.
- GitPush o etiqueta
- NginxHTTPS
- PHP-FPMLaravel o Symfony
- WorkersColas y scheduler
- Bases de datosMySQL o PostgreSQL, y Redis
¿Dónde lo montamos?
En vuestra cuenta, en el proveedor que ya uséis o en el que mejor encaje. Si los datos tienen que quedarse en la UE, Hetzner y OVHcloud son las opciones europeas.
Proveedores en los que lo montamos
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Servidor propio
| Proveedor | Cómo lo montamos | A tener en cuenta |
|---|---|---|
| Hetzner | Servidores cloud con Nginx y PHP-FPM, un servidor aparte para workers cuando la carga lo pide y copias en Object Storage de Hetzner. | Hetzner no ofrece base de datos gestionada: la montamos y la cuidamos nosotros. |
| AWS | EC2 o contenedores en ECS, con RDS, ElastiCache para Redis o Valkey y SQS si vuestras colas ya lo usan. | |
| Google Cloud | Compute Engine o Cloud Run para la parte web, Cloud SQL y Memorystore. | En Cloud Run los workers de colas largas necesitan otro sitio; lo planteamos antes. |
| Azure | Máquinas virtuales o App Service, con Azure Database for MySQL o PostgreSQL. | |
| DigitalOcean | Droplets con PHP-FPM y bases de datos gestionadas de DigitalOcean. | |
| OVH | Instancias de Public Cloud y bases de datos gestionadas de OVHcloud. | |
| Servidor propio | La aplicación en vuestros servidores o máquinas virtuales, con el mismo sistema de despliegue. |
Qué incluye
- Servidores o contenedores con Nginx, PHP-FPM y la versión de PHP que pida vuestra aplicación, en vuestra cuenta.
- Despliegue automático desde Git con versiones en carpetas separadas y vuelta atrás en segundos.
- Migraciones de base de datos dentro del despliegue, con copia previa cuando tocan tablas grandes.
- Workers de colas supervisados con Supervisor o systemd, reiniciados en cada despliegue, o Laravel Horizon si usáis Redis.
- Scheduler de Laravel o Symfony ejecutado una sola vez por minuto, aunque haya varios servidores.
- PHP-FPM y OPcache dimensionados según memoria y tráfico, con la caché de configuración y rutas generada en el despliegue.
- Copias de base de datos y de archivos subidos fuera del servidor, con restauración de prueba.
- Monitorización de errores, colas atascadas, workers caídos, tiempo de respuesta y disco, con alertas.
Preguntas frecuentes
¿Hay corte de servicio en cada despliegue?
No debería. Cada versión se prepara en su propia carpeta: se instalan las dependencias, se generan las cachés y, cuando todo está listo, el enlace de la versión activa cambia de golpe. Si algo falla, se vuelve a la anterior cambiando el enlace otra vez. Lo único que puede pedir una ventana es una migración que bloquee una tabla grande, y eso lo vemos antes.
¿Qué pasa si un worker de colas se queda colgado?
Supervisor o systemd lo vuelven a arrancar si el proceso muere, y los workers se reinician de forma ordenada tras cada despliegue para que no sigan con el código viejo. Además vigilamos el tamaño de las colas y los trabajos fallidos: si la cola crece sin bajar, salta una alerta aunque los procesos parezcan vivos.
¿Laravel Forge, Vapor o nuestro propio servidor?
Forge prepara servidores y Vapor lleva Laravel a funciones de AWS; los dos son buenos si encajan con vosotros. Montamos la aplicación sin ellos cuando queréis una configuración descrita en vuestro repositorio, otro proveedor como Hetzner, o alguien que además vigile y responda. Si ya usáis Forge, podemos trabajar sobre los servidores que gestiona.
¿Escribís o corregís el código de la aplicación?
No es lo que hacemos. Si un error viene del código, os lo entregamos con el registro, la petición que lo provoca y lo que hemos visto en el servidor, para que vuestro equipo lo arregle rápido. Sí nos encargamos de todo lo que rodea al código: versiones de PHP, extensiones, configuración, despliegue e infraestructura.
¿Gestionáis también otras aplicaciones PHP?
Sí, con el mismo enfoque: CodeIgniter, Slim, aplicaciones sin marco de trabajo o versiones antiguas que hay que llevar a un PHP con soporte. Para WordPress y WooCommerce tenemos una página propia.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Documentación oficial consultada
Los datos técnicos de esta página se basan en:
Revisado el