El problema con SFTP y los deploys manuales
Desplegar arrastrando archivos por SFTP es como los sitios terminan medio rotos: un archivo se olvida, composer no se ejecuta, una migración se pasa por alto, y el caché sigue sirviendo el bundle viejo. No hay registro de que se lanzó ni una forma limpia de reproducirlo. GitHub Deploy reemplaza eso con un pipeline definido ligado a tu repositorio, de modo que un release es el resultado determinista de un commit más un conjunto fijo de pasos — el mismo cada vez, por cualquiera del equipo.
Tus pasos de build, ejecutados de forma consistente
Un deploy real es más que copiar archivos: las dependencias deben instalarse, los assets compilarse, y las migraciones de base de datos aplicarse en el orden correcto. Defines esos pasos una vez — por ejemplo composer install, un build de npm o assets, y un comando de migración — y se ejecutan en cada deploy contra el commit exacto que se está lanzando. Eso elimina toda una clase de bugs donde producción se comporta distinto porque alguien ejecuto los pasos en otro orden o se salto uno bajo presión.
Deploys manuales y auto-deploy por webhook
Diferentes equipos quieren diferentes disparadores. Un equipo cauteloso mantiene los deploys manuales, haciendo clic en deploy en el panel después de una revisión para que un release sea un acto deliberado. Un equipo más agil activa el webhook para que cada push a la rama de producción se lance automáticamente, convirtiendo git push en un deploy. Ambos ejecutan el mismo pipeline; la única diferencia es que jala el gatillo, y puedes empezar manual y activar el webhook una vez que confíes en el flujo.
Repositorios privados y tokens seguros
La mayoría del código real está en repositorios privados, así que la plataforma se autentica con un token que tu proporcionas en lugar de exigir que el código sea público. El token se almacena como un secret y se usa solo para clonar en el momento del deploy; nunca aparece en logs ni en la interfaz después de guardarse, y como está separado de tu código puedes rotarlo o revocarlo de forma independiente. Las entregas de webhook se verifican con un secret firmado para que un POST aleatorio no pueda disparar un release.
Auto-purge cierra la última brecha
El bug post-deploy más común es un release nuevo escondido detrás de un caché edge desactualizado — se lanzó CSS o JS nuevo, pero los visitantes siguen cargando el bundle viejo cacheado. GitHub Deploy purga el caché edge como parte del release, así que el deploy no se considera terminado hasta que el caché refleja los archivos nuevos. Eso elimina el paso de flush manual que la gente olvida, y significa que lo que lanzaste es lo que los visitantes realmente reciben.
Entrega repetible para equipos y agencias
Cuando cada proyecto se despliega de la misma forma, el onboarding y la entrega dejan de ser conocimiento tribal. El estado de deploy, la hora del último deploy, y los pasos configurados son visibles en el panel, así que cualquiera puede ver si el último push llegó a producción y que se ejecuto. Para agencias esto significa un modelo de entrega estándar entre proyectos de clientes, donde entregar un sitio a otro desarrollador no requiere hacer ingeniería inversa de un ritual de deploy a medida y sin documentar.
Cómo desplegar, paso a paso
Conecta el repositorio y la rama
En el panel abre tu app, ve a GitHub Deploy, e ingresa la URL del repositorio y la rama desde la que despliegas — típicamente main o production. La rama que eliges es la que se vuelve la versión en vivo, así que las ramas de feature nunca se lanzan por accidente.
Autoriza un repositorio privado
Si el repositorio es privado, agrega un personal access token o un token de deploy para que la plataforma pueda clonarlo. El token se almacena como un secret, se usa solo para extraer el código en el momento del deploy, y se puede revocar o rotar sin tocar tu aplicación.
Define los pasos de build y migración
Define los comandos que convierten un checkout en un release en ejecución — para una app PHP eso normalmente es composer install --no-dev, un build de assets de front-end, y una migración de base de datos. Estos pasos se guardan con la app para que cada deploy ejecute el mismo pipeline idéntico, no lo que alguien recuerde escribir.
Elige auto-deploy manual o por webhook
Despliega bajo demanda con un botón en el panel, o activa el webhook para que un push a la rama conectada dispare el deploy automáticamente. El webhook usa un secret firmado, así que solo pushes genuinos de tu repositorio pueden iniciar un release.
Lanza, purga, y confirma
En el deploy la plataforma extrae la rama, ejecuta tus pasos, y activa el nuevo release; el caché edge de los assets cambiados se purga automáticamente para que los visitantes no reciban archivos desactualizados. El panel muestra el estado de deploy y la hora del último deploy para que puedas confirmar que el release está en vivo.
Escenarios de ejemplo
Un push a main dispara composer install, un build de assets, y migraciones, luego el release se lanza y el caché edge se purga automáticamente.
Una agencia conecta un repositorio privado de GitHub con un token de deploy de alcance limitado, manteniendo el código cerrado mientras la plataforma sigue extrayéndolo y desplegándolo.
Un equipo mantiene el auto-deploy apagado y hace clic en deploy en el panel después de una revisión de código, así que cada release de producción es una acción deliberada y registrada.
Preguntas frecuentes
GitHub Deploy construye una imagen Docker, o despliega código fuente?
Despliega el código fuente de la aplicación en el runtime de la plataforma — extrae tu rama y ejecuta tus pasos de build y migración sobre el código mismo. Eso encaja de forma natural para apps PHP y de framework. Si específicamente quieres construir y correr una imagen de contenedor, usa Container Apps con una imagen prearmada o Docker Compose Instant Deploy en su lugar.
Qué ocurre exactamente en un push por webhook?
Un push a la rama conectada envía un webhook firmado a la plataforma, que verifica la firma, clona u obtiene ese commit, ejecuta tus pasos de build y migración definidos, activa el nuevo release, y purga el caché edge. El panel entonces actualiza el estado de deploy y la hora del último deploy para que puedas confirmar que aterrizó.
Cómo se protege mi access token?
El token se almacena como un secret y se usa solo para clonar el repositorio en el momento del deploy. No se muestra después de guardarse ni aparece en logs de build, y como vive por separado de tu código puedes rotarlo o revocarlo en GitHub sin cambiar nada en la app.
Puedo hacer rollback si un deploy sale mal?
Como los deploys están ligados a commits y pasos definidos, recuperarse es cuestión de desplegar un commit conocido como bueno — apuntas el deploy al commit anterior que funcionaba o haces revert en la rama y dejas que el pipeline lo lance. Mantener los deploys reproducibles es exactamente lo que hace que volver atrás sea confiable en lugar de una carrera contra el tiempo.
Qué rama se lanza en vivo, y puedo desplegar desde más de una?
Eliges la rama desde la que desplegar, típicamente main o una rama de producción dedicada, y solo esa rama se lanza — los pushes a ramas de feature no despliegan. Esto mantiene el trabajo en progreso fuera de producción mientras te sigue permitiendo desplegar en el momento en que haces merge a la rama de release.
Funciona con GitLab u otros hosts de Git, o solo con GitHub?
El flujo de trabajo está construido alrededor de una URL de repositorio Git, una rama, y un token, así que no está limitado específicamente a GitHub — cualquier repositorio al que puedas llegar con una URL y un access token encaja en el mismo modelo. GitHub es el caso común, por eso lleva su nombre, pero la mecánica es Git estándar.
¿git deploy funciona con GitLab y Bitbucket, o solo con GitHub?
Git deploy funciona con cualquier servidor Git que pueda alcanzar cdn.com.tr: GitHub, GitLab, Bitbucket o un servidor propio. Con GitHub el camino es el más directo, porque la GitHub App se encarga de la autorización y de los webhooks; en los demás casos conecta la URL del repositorio con un token de despliegue y apunta un webhook a su aplicación, y un push a la rama seguida dispara el mismo proceso de compilación y publicación. El despliegue en sí es independiente del proveedor: descargamos la rama, ejecutamos sus pasos de compilación, publicamos la nueva versión y purgamos la caché del CDN.