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 migracion se pasa por alto, y el cache sigue sirviendo el bundle viejo. No hay registro de que se lanzo 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 mas 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 mas 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 migracion — y se ejecutan en cada deploy contra el commit exacto que se esta lanzando. Eso elimina toda una clase de bugs donde produccion se comporta distinto porque alguien ejecuto los pasos en otro orden o se salto uno bajo presion.
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 despues de una revision para que un release sea un acto deliberado. Un equipo mas agil activa el webhook para que cada push a la rama de produccion se lance automaticamente, convirtiendo git push en un deploy. Ambos ejecutan el mismo pipeline; la unica diferencia es que jala el gatillo, y puedes empezar manual y activar el webhook una vez que confies en el flujo.
Repositorios privados y tokens seguros
La mayoria del codigo real esta en repositorios privados, asi que la plataforma se autentica con un token que tu proporcionas en lugar de exigir que el codigo sea publico. 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 despues de guardarse, y como esta separado de tu codigo 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 ultima brecha
El bug post-deploy mas comun es un release nuevo escondido detras de un cache edge desactualizado — se lanzo CSS o JS nuevo, pero los visitantes siguen cargando el bundle viejo cacheado. GitHub Deploy purga el cache edge como parte del release, asi que el deploy no se considera terminado hasta que el cache 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 ultimo deploy, y los pasos configurados son visibles en el panel, asi que cualquiera puede ver si el ultimo push llego a produccion y que se ejecuto. Para agencias esto significa un modelo de entrega estandar entre proyectos de clientes, donde entregar un sitio a otro desarrollador no requiere hacer ingenieria inversa de un ritual de deploy a medida y sin documentar.
Como 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 — tipicamente main o production. La rama que eliges es la que se vuelve la version en vivo, asi 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 codigo en el momento del deploy, y se puede revocar o rotar sin tocar tu aplicacion.
Define los pasos de build y migracion
Define los comandos que convierten un checkout en un release en ejecucion — para una app PHP eso normalmente es composer install --no-dev, un build de assets de front-end, y una migracion de base de datos. Estos pasos se guardan con la app para que cada deploy ejecute el mismo pipeline identico, no lo que alguien recuerde escribir.
Elige auto-deploy manual o por webhook
Despliega bajo demanda con un boton en el panel, o activa el webhook para que un push a la rama conectada dispare el deploy automaticamente. El webhook usa un secret firmado, asi 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 cache edge de los assets cambiados se purga automaticamente para que los visitantes no reciban archivos desactualizados. El panel muestra el estado de deploy y la hora del ultimo deploy para que puedas confirmar que el release esta 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 cache edge se purga automaticamente.
Una agencia conecta un repositorio privado de GitHub con un token de deploy de alcance limitado, manteniendo el codigo cerrado mientras la plataforma sigue extrayendolo y desplegandolo.
Un equipo mantiene el auto-deploy apagado y hace clic en deploy en el panel despues de una revision de codigo, asi que cada release de produccion es una accion deliberada y registrada.
Preguntas frecuentes
GitHub Deploy construye una imagen Docker, o despliega codigo fuente?
Despliega el codigo fuente de la aplicacion en el runtime de la plataforma — extrae tu rama y ejecuta tus pasos de build y migracion sobre el codigo mismo. Eso encaja de forma natural para apps PHP y de framework. Si especificamente quieres construir y correr una imagen de contenedor, usa Container Apps con una imagen prearmada o Docker Compose Instant Deploy en su lugar.
Que ocurre exactamente en un push por webhook?
Un push a la rama conectada envia un webhook firmado a la plataforma, que verifica la firma, clona u obtiene ese commit, ejecuta tus pasos de build y migracion definidos, activa el nuevo release, y purga el cache edge. El panel entonces actualiza el estado de deploy y la hora del ultimo deploy para que puedas confirmar que aterrizo.
Como 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 despues de guardarse ni aparece en logs de build, y como vive por separado de tu codigo puedes rotarlo o revocarlo en GitHub sin cambiar nada en la app.
Puedo hacer rollback si un deploy sale mal?
Como los deploys estan ligados a commits y pasos definidos, recuperarse es cuestion 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 atras sea confiable en lugar de una carrera contra el tiempo.
Que rama se lanza en vivo, y puedo desplegar desde mas de una?
Eliges la rama desde la que desplegar, tipicamente main o una rama de produccion dedicada, y solo esa rama se lanza — los pushes a ramas de feature no despliegan. Esto mantiene el trabajo en progreso fuera de produccion 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 esta construido alrededor de una URL de repositorio Git, una rama, y un token, asi que no esta limitado especificamente a GitHub — cualquier repositorio al que puedas llegar con una URL y un access token encaja en el mismo modelo. GitHub es el caso comun, por eso lleva su nombre, pero la mecanica es Git estandar.