Esta guía propone un enfoque pensado para despliegues repetibles, seguros y predecibles, con builds deterministas, releases atómicas, gestión correcta de permisos, configuración limpia de entorno y un rendimiento estable en producción.

Asumimos un stack clásico: Linux + Nginx o Apache + PHP-FPM + SQL + Git (con o sin CI/CD). Da igual si usas Deployer, Ansible, GitHub Actions o scripts propios: los principios son los mismos.

Principios de producción que te ahorran problemas a medio plazo

Antes de entrar en comandos, revisemos algunas reglas básicas:

  • Nunca ejecutes la app desde un directorio mutable. Usa releases con un symlink current (cambio atómico).
  • Separa código de datos de ejecución. Caché, logs y uploads, ya que estos no viven en Git.
  • La configuración es entorno, no código, como las variables de entorno o secretos.
  • Calienta la caché antes de poner la release en producción. Evita penalizar al primer usuario.
  • Ten una estrategia para OPcache. O validas timestamps (más lento) o recargas PHP-FPM tras el deploy (más seguro).

Estructura de directorios recomendada (releases + current)

Una estructura probada y muy común:

El servidor web debe apuntar siempre a tu Document root, como por ejemplo: 

/var/www/myapp/current/public

Instalación de dependencias en producción

Dentro del directorio de la nueva release:

Esto elimina dependencias de desarrollo y optimiza el autoload, algo esencial en producción.

Si usas Symfony Flex y .env:

En muchos entornos modernos se prefieren variables de entorno reales y no .env en producción.

Variables de entorno y secretos

La opción recomendada es usar variables de entorno en (systemd, Docker, CI/CD), para valores sensibles. Variables habituales:

  • APP_ENV=prod
  • APP_DEBUG=0
  • DATABASE_URL=...
  • MAILER_DSN=...
  • MESSENGER_TRANSPORT_DSN=...

Consejo importante, valida que no falte ninguna antes de ir a producción:

Esto evita errores típicos de “funciona en staging pero no en prod”.

Permisos: no soluciones todo con chmod 777

Symfony necesita escribir en var/ (caché y logs). El usuario de PHP-FPM (por ejemplo www-data) debe tener permisos. La forma más segura es usar ACLs para que tanto el usuario de deploy como el del servidor web puedan escribir.

Un error muy común es limpiar caché como root y la app deja de poder escribir en var/ en runtime. Por lo que una regla simple es que nunca ejecutes comandos de Symfony como root si afectan a var/.

Caché y preparación antes de poner la release en vivo

Antes de cambiar el symlink current:

Si usas Doctrine, nunca hagas cambios de esquema “a mano” en producción. Usa migraciones:

Assets (Encore, Importmap, AssetMapper)

Depende de tu stack:

  • Webpack Encore: compila en CI o en servidor y despliega los assets ya generados.
  • AssetMapper / Importmap: más simple, pero revisa headers y caché.

Asegúrate de que public/build (o equivalente) corresponde exactamente a esa release.

Cambio de release atómico

Cuando todo este listo puedes crear el acceso directo a tu última release creando un enlace simbólico:

Ese único comando hace el deploy instantáneo y reversible.

Después, recarga servicios si procede:

Recargar PHP-FPM es una buena forma de asegurarte de que OPcache no servirá código o datos antiguo.

Configuración mínima del servidor web

Imprescindibles en producción:

  • Servir solo /public como document root.
  • Bloquear acceso a archivos sensibles (.env, /config, /var, etc.).
  • Headers de caché correctos para assets.
  • TLS bien configurado, HTTP/2 (o HTTP/3 si aplica).

Checklist rápido post-deploy

Haz esto en cada despliegue:

  • php bin/console about --env=prod
  • php bin/console lint:container --resolve-env-vars
  • Acceder a un endpoint de salud (/health si existe)
  • Revisar var/log/prod.log
  • Verificar versión/commit activo (muy útil exponerlo en un endpoint interno)

Script de despliegue con rollback automático

Conclusión

Un buen despliegue en Symfony no se nota cuando funciona. Pero cuando está mal hecho, se convierte en deuda técnica inmediata. Si aplicas estos principios, releases atómicas, permisos correctos, caché bien gestionada, entorno limpio, y verificación post-deploy, tendrás despliegues tranquilos, repetibles y seguros. 

Compartir es construir