GPT-5.6 y GitHub Actions: automatiza deploys sin enseñar las llaves

GPT-5.6 llega con mucho foco en código, herramientas y tareas largas. Eso no significa que debas darle las llaves de producción a ciegas. Significa algo más útil: puedes usarlo para diseñar una automatización revisable y luego quedarte tú con la última palabra.

Un caso muy real para una web de negocio es este: tienes el código en GitHub, la web en un servidor con acceso SSH y quieres que cada push a main pueda desplegar sin entrar a mano, sin copiar archivos por FTP y sin depender de acordarte de tres comandos.

La unión no debería ser “GPT entra en mi servidor”. Yo lo plantearía así:

1. GPT o Codex te ayuda a crear el workflow, revisar los comandos y detectar riesgos.
2. GitHub guarda el código y ejecuta GitHub Actions cuando haces push.
3. GitHub Actions se conecta al servidor por SSH con una clave específica.
4. El servidor hace git pull --ff-only desde GitHub y ejecuta el comando de deploy.

La parte importante es separar responsabilidades. GPT propone y revisa. GitHub automatiza. El servidor despliega. Los secretos no se pegan en el chat, ni se suben al repositorio, ni se imprimen en logs.

1. Pide a GPT el workflow con datos ficticios

En vez de darle rutas reales, usuarios reales o claves privadas, puedes pedir algo así:

Quiero un workflow de GitHub Actions para desplegar una web en un servidor Linux por SSH.

Condiciones:
- Rama de producción: main.
- El servidor hará git pull --ff-only origin main.
- Antes de hacer pull debe abortar si hay cambios locales en archivos versionados.
- Los secretos se llamarán SERVER_HOST, SERVER_USER, SERVER_SSH_KEY y SERVER_PORT.
- No escribas credenciales reales.
- Usa permisos mínimos en GitHub Actions.
- Añade comentarios solo donde ayuden a entender riesgos.

Con eso, GPT-5.6 no necesita conocer tu infraestructura. Le das la forma del problema, no las llaves. Después revisas el resultado como revisarías código de otra persona.

Si usas Codex conectado a GitHub, el flujo puede ser todavía más cómodo: le pides que cree una rama, añada .github/workflows/deploy.yml, adapte los comandos al proyecto y abra un pull request. La ventaja no es que “publique solo”, sino que puedes ver el diff antes de mezclarlo.

2. Prepara las dos conexiones SSH

Aquí suele haber confusión, porque hay dos enlaces distintos:

• GitHub Actions -> servidor. GitHub necesita entrar por SSH al servidor para ejecutar comandos.
• Servidor -> GitHub. El servidor necesita poder hacer git pull del repositorio.

Para el primer enlace, generas una clave específica para el deploy desde GitHub Actions. La clave pública va al archivo ~/.ssh/authorized_keys del usuario del servidor. La clave privada se guarda como secret en GitHub Actions, por ejemplo SERVER_SSH_KEY.

Ejemplo local para generar una clave dedicada:

ssh-keygen -t ed25519 -C "github-actions-deploy" -f ./github-actions-deploy

Para el segundo enlace, puedes usar una deploy key de GitHub. La clave pública se añade en el repositorio de GitHub como deploy key de solo lectura. La clave privada se queda en el servidor, en el usuario que hará el git pull.

En el servidor, la configuración mínima suele parecerse a esto:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

# La clave privada de lectura del repo viviría aquí.
chmod 600 ~/.ssh/id_ed25519_github_repo

cat > ~/.ssh/config <<'EOF'
Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_github_repo
  IdentitiesOnly yes
EOF

ssh -T git@github.com

Si el repositorio ya está clonado en el servidor por HTTPS con token, yo aprovecharía para cambiarlo a SSH:

cd /ruta/de/la/web
git remote set-url origin git@github.com:usuario/repositorio.git
git fetch origin main

3. Guarda secretos en GitHub, no en el YAML

En GitHub, iría a Settings -> Secrets and variables -> Actions y crearía secretos como estos:

• SERVER_HOST: dominio o IP del servidor.
• SERVER_USER: usuario SSH.
• SERVER_PORT: normalmente 22, salvo que uses otro.
• SERVER_SSH_KEY: clave privada que permite entrar al servidor.

También puedes usar variables no sensibles para datos como REMOTE_PATH o DEPLOY_COMMAND, pero en un ejemplo sencillo prefiero dejar placeholders visibles para que se entienda qué debes cambiar.

4. Workflow básico que puede funcionar

Este ejemplo no depende de Astro. Sirve para cualquier proyecto que se despliegue con comandos de terminal: WordPress versionado parcialmente, una app Node, una web estática, Laravel, Symfony, etc. Solo hay que ajustar la ruta y los comandos finales.

name: Deploy web

on:
  push:
    branches: [main]

permissions:
  contents: read

concurrency:
  group: production-deploy
  cancel-in-progress: false

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - run: npm ci
      - run: npm run build

      - name: Deploy en servidor por SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SERVER_SSH_KEY }}
          port: ${{ secrets.SERVER_PORT }}
          script: |
            set -e

            cd /ruta/de/la/web

            git fetch origin main

            if [ -n "$(git status --porcelain)" ]; then
              echo "Hay cambios locales en el servidor. Deploy abortado."
              git status --short
              exit 1
            fi

            git pull --ff-only origin main

            npm ci --prefer-offline
            npm run build

La parte de npm ci y npm run build puede cambiar. En una web PHP quizá sea composer install --no-dev --optimize-autoloader. En una web estática puede ser copiar dist/ a una carpeta pública. En Plesk, muchas veces interesa llamar exactamente al binario de Node o npm que usa ese hosting, por ejemplo:

/ruta/al/npm ci --prefer-offline
/ruta/al/npm run build

No hace falta poner la ruta real en un artículo, pero en tu proyecto sí conviene usar la misma que ejecuta Plesk. Así evitas que GitHub Actions despliegue con una versión de Node y el servidor construya con otra.

5. Pide a GPT que revise riesgos concretos

Después de generar el YAML, no le preguntaría “¿está bien?”. Le haría preguntas más duras:

Revisa este workflow como si fuera para producción.

Busca:
- secretos escritos en claro;
- permisos excesivos;
- comandos que puedan pisar cambios del servidor;
- ausencia de parada si falla el build;
- dependencias de rutas o versiones no documentadas;
- acciones externas que convenga fijar o revisar.

Ese segundo paso es donde la IA suele aportar más. No solo escribe el archivo: te obliga a convertir una costumbre manual en un proceso explícito.

6. Qué haría antes de activarlo en producción

Mi checklist mínima sería:

• Probar primero en una rama o entorno de staging.
• Comprobar que el usuario SSH solo puede tocar la carpeta necesaria.
• Usar una clave distinta a tu clave personal.
• Confirmar que git pull --ff-only no pisa cambios locales.
• Subir antes los archivos ignorados por Git si el build los necesita.
• Revisar que los logs de Actions no muestran secretos.
• Documentar el comando de deploy en el README o en un archivo interno.

Para una pyme, la ventaja no es “automatizarlo todo”. La ventaja es reducir errores repetitivos: olvidarse de ejecutar el build, subir código antes que assets, lanzar comandos en orden distinto o desplegar una rama equivocada. La automatización buena no sustituye el criterio; lo convierte en pasos explícitos.

Mi recomendación: usa GPT-5.6 para crear y revisar el primer borrador, pero no le pegues credenciales ni datos sensibles. Sustituye rutas por placeholders, revisa cada comando, prueba en staging y solo después conecta producción. La IA puede acelerar mucho este trabajo, pero el despliegue sigue siendo infraestructura: mejor claro, pequeño y auditable.

Fuentes

• OpenAI: GPT-5.6
• OpenAI Developers: Codex Cloud y conexión con GitHub
• GitHub Docs: usar secretos en GitHub Actions
• GitHub Docs: gestionar deploy keys