versaDeploy es una herramienta de código abierto escrita en Go que compila un proyecto en la máquina del desarrollador, sube solo lo que ha cambiado a un servidor Linux por SSH y activa la nueva versión cambiando un único enlace simbólico. La publica en GitHub el desarrollador que firma como kriollo, bajo licencia MIT, y el 06/11/2026 llegó a la versión 1.12.0 tras una racha de cuatro versiones en dos días centradas sobre todo en seguridad.
Las claves de versaDeploy en 20 segundos
- Binario único en Go, con licencia MIT, para Windows, Linux y macOS.
- Compila en local PHP, frontends Node, Go y Python, y sube por SFTP.
- Cada despliegue es una carpeta nueva y el enlace
currentcambia de forma atómica. - Revierte solo si falla un hook, un servicio o la comprobación de salud.
- Proyecto creado en enero de 2026 y aún muy joven.
El planteamiento resultará familiar a quien haya usado Capistrano o Deployer: carpeta releases/, enlace current, directorio shared/ para lo que debe sobrevivir entre versiones y vuelta atrás instantánea. La diferencia está en dónde se hace el trabajo pesado. versaDeploy no instala Git, Composer ni npm en el servidor de producción para construir la aplicación, sino que lo hace todo en el equipo local o en el sistema de integración continua y envía al servidor un artefacto ya preparado. El propio README lo resume con una sola orden:
versa deploy productionCómo funciona un despliegue con versaDeploy
La documentación divide el proceso en cuatro fases. Primero, la detección: versaDeploy calcula el SHA256 de cada archivo y lo compara con el fichero deploy.lock que dejó en el servidor el despliegue anterior. Si nada ha cambiado, se detiene antes de compilar, y si solo han cambiado archivos PHP, no lanza el compilador del frontend. Antes de eso exige que el árbol de trabajo esté confirmado en Git y clona el HEAD en un directorio temporal, de modo que solo se despliega código que ya está en un commit.
Después llega la compilación local, con soporte para PHP y Composer, frontends basados en Node (npm, pnpm o yarn), Go y Python. La subida se hace por SFTP (el protocolo de transferencia de archivos sobre SSH): el artefacto se comprime en trozos de 10 MB por defecto, se envía con cuatro procesos en paralelo y se descomprime en el servidor con tar, después de comprobar que hay espacio en disco. Carpetas pesadas como vendor, node_modules o .venv se reutilizan de la versión anterior mediante enlaces duros cuando sus ficheros de dependencias no han cambiado.
La última fase es la activación. versaDeploy enlaza las rutas compartidas (por ejemplo, el .env), cambia el enlace current a la nueva carpeta, recarga servicios como PHP-FPM o Nginx, ejecuta los hooks posteriores al despliegue y reinicia los servicios que gestiona. Si falla un hook post_deploy, un servicio o la comprobación de salud (HTTP o por comando), devuelve el enlace a la versión anterior por su cuenta. Las versiones se guardan con marcas de tiempo en UTC (tiempo universal coordinado) y, por defecto, el servidor conserva cinco, que es también el límite hasta donde se puede volver atrás.
La documentación deja claro qué no hace la vuelta atrás: solo cambia el enlace simbólico, no recompila nada, no ejecuta de nuevo los hooks y no revierte las migraciones de base de datos. Es un matiz importante para cualquier aplicación con cambios de esquema. También avisa de que, con la subida incremental activada, la versión nueva y la anterior comparten ficheros a través de enlaces duros, así que un hook que modifique un archivo en su sitio (con sed -i, por ejemplo) alteraría también la versión previa.
El arranque rápido del README muestra el flujo completo con cinco órdenes:
cd my-project
versa init # creates deploy.yml
versa config validate production # check the file
versa info production # check SSH and the server
versa deploy production --initial-deploy # first deploy
versa deploy production # every deploy after thatLenguaje del código: PHP (php)Toda la configuración vive en un archivo deploy.yml con entornos separados (producción, preproducción…), rutas compartidas y preservadas, hooks locales y remotos, comprobación de salud y avisos por webhook a Slack, Teams o Discord. Para alojamientos sin SSH existe un modo local que genera una versión completa en una carpeta para subirla después por FTP, aunque en ese modo no hay historial de versiones ni vuelta atrás. Ejecutar versa sin argumentos abre además una interfaz de terminal a pantalla completa para consultar versiones, desplegar, revertir o abrir una terminal remota.
Claves SSH, known_hosts y un servidor que se prepara solo
La conexión se autentica con una clave privada, que es obligatoria en la configuración (key_path), y opcionalmente con las claves cargadas en el agente SSH. La documentación no contempla contraseñas para el usuario de despliegue. Para mantener secretos fuera del archivo, deploy.yml admite variables de entorno de la máquina local con la sintaxis ${NOMBRE}, que se sustituyen antes de interpretar el fichero.
La verificación de la clave del servidor sigue la lógica del cliente ssh. Si el servidor figura en known_hosts con una clave distinta, versaDeploy se niega a conectar. Pero si el fichero no existe o no se puede leer, por defecto conecta mostrando un aviso de clave no verificada, salvo que se active strict_host_key. Cualquier administrador que lo use en producción debería activar esa opción o registrar antes el servidor, como propone la propia documentación:
ssh-keyscan -p 22 your-server.com >> ~/.ssh/known_hostsLenguaje del código: JavaScript (javascript)Hay también una opción legacy_algorithms para servidores con OpenSSH anterior a la versión 7, como CentOS 5 o 6, que activa intercambios de claves SHA1 y cifrados CBC. La documentación la califica de insegura y recomienda usarla solo cuando no quede otra.
Desde la versión 1.9.0 la interfaz incluye una vista de servicios que convierte la herramienta en un pequeño panel sin agente: detecta qué ejecuta el servidor e instala nginx o Apache, PHP, PostgreSQL o MySQL, Redis, Python, Node, certificados SSL, cortafuegos y el usuario de despliegue. La detección funciona en cualquier Linux, pero la instalación, las actualizaciones y las copias de seguridad de bases de datos requieren Debian o Ubuntu. Los binarios de Go y los servidores Python pueden quedar gestionados por systemd, OpenRC o SysV init.
El registro de cambios merece una lectura atenta. La versión 1.10.0, del 05/11/2026, corrigió un fallo por el que, según el propio changelog, el usuario de despliegue podía convertirse en root a través de la regla de sudoers de los servicios. La 1.9.1 cerró otra vía por la que las copias de seguridad diarias, ejecutadas como root, podían escribir en rutas arbitrarias mediante un enlace simbólico, y la 1.11.0 sumó más de una docena de correcciones de seguridad, entre ellas sacar la contraseña de la base de datos de los argumentos de mysql y psql. Que el autor documente estos fallos con detalle habla bien de su transparencia, pero también indica que las funciones que tocan root son recientes. Algunas exigen además ejecutar de nuevo un paso de configuración en servidores ya existentes.
Un proyecto de diez meses frente a Deployer y Capistrano
El primer commit del repositorio data del 27/01/2026 y la primera versión del changelog, la 0.9.0-beta, del 29/01/2026. Todas las versiones publicadas hasta la 1.5.0 (agosto de 2026) llevaban el sufijo rc, y la 1.6.0 del 01/10/2026 fue la primera sin él. El historial clonado suma 59 commits, todos con la misma dirección de correo de autor, unas 21.800 líneas de Go y 35 ficheros de pruebas. Las pruebas automáticas de GitHub Actions se ejecutan en Ubuntu y Windows, no en macOS, aunque se publican binarios para los tres sistemas en arquitecturas x64 y ARM64. El repositorio incluye un archivo CLAUDE.md con instrucciones para asistentes de programación.
Las alternativas consolidadas parten de otras premisas. Deployer y Capistrano usan la misma estructura de carpetas, pero se configuran con recetas en PHP y en Ruby, respectivamente, y llevan muchos años en producción. Envoyer es el servicio comercial de Laravel para despliegues sin interrupción y, desde agosto de 2023, se integra con Forge. Ansible es una herramienta general de automatización sin agente sobre SSH, capaz de desplegar aplicaciones pero pensada para mucho más.
| Herramienta | Cómo se configura | Dónde se compila | Modelo |
|---|---|---|---|
| versaDeploy | YAML (deploy.yml), binario Go | En local o en CI; sube el artefacto por SFTP | Código abierto (MIT) |
| Deployer | Recetas en PHP | Según la receta, habitualmente en el servidor | Código abierto |
| Capistrano | Recetas en Ruby | Según la receta, habitualmente en el servidor | Código abierto |
| Envoyer | Panel web | En el servidor | Servicio de pago de Laravel |
El encaje de versaDeploy está en equipos pequeños con servidores propios, sobre todo de PHP, que prefieren no compilar en producción y quieren un binario sin dependencias que también funcione desde Windows. Es un perfil parecido al de quienes buscan paneles autoalojados como Vito para gestionar servidores y despliegues PHP. A cambio, se trata de un proyecto de un solo autor, con menos de un año de vida, sin una comunidad visible de colaboradores y con cambios de seguridad muy recientes. Probarlo primero en un entorno de preproducción y revisar la configuración de sudoers que genera parece lo prudente, en línea con la idea de revisar la seguridad antes de cada despliegue.
Preguntas frecuentes
¿Qué tipo de aplicaciones puede desplegar versaDeploy?
Proyectos PHP con Composer, frontends basados en Node, binarios de Go y aplicaciones Python, siempre hacia servidores Linux por SSH. También tiene un modo local que genera una versión lista para subir por FTP.
¿Cómo hace versaDeploy la vuelta atrás?
Cambia el enlace simbólico current a una versión anterior guardada en el servidor, que por defecto conserva cinco. No recompila, no ejecuta hooks y no revierte migraciones de base de datos.
¿Qué licencia tiene versaDeploy y es gratuito?
Se distribuye con licencia MIT y es gratuito. Los binarios para Windows, Linux y macOS se descargan desde la sección de versiones de GitHub.
¿Es versaDeploy un proyecto maduro?
Es reciente: su primer commit es de enero de 2026 y la primera versión sin sufijo rc llegó en octubre de 2026. Las últimas versiones corrigieron fallos de seguridad relevantes, por lo que conviene probarlo antes en preproducción.
Fuentes:
