CI/CD para agentes IA: GitHub Actions, Vercel, Railway y Docker

El agente ya está en producción. Cada commit a main ahora puede romperlo — o puede desplegarse solo si el pipeline está bien armado. La mayoría de builders no necesita un CI/CD elaborado: Vercel y Railway ya despliegan al push. El valor de GitHub Actions aparece cuando quieres tests, evals o un gate humano antes de Production. Esta guía te dice cuándo cada opción alcanza y te deja un workflow mínimo que no se rompe. Las fuentes oficiales fueron consultadas el 3 de septiembre de 2026.

Si aún no tienes plataforma de destino, empieza por la comparativa Vercel vs Workers vs VPS o Railway. Esta pieza cubre el cómo del pipeline, no la elección de host.

La regla de decisión

Situación	Pipeline que alcanza	Por qué
Agente en Vercel, sin tests	Autodeploy nativo de Vercel	Cada push a la rama conectada genera un Preview; main va a Production
Agente en Railway, sin tests	Autodeploy nativo de Railway	Un servicio ligado a un repo de GitHub despliega al push de la rama configurada; se puede desactivar y disparar a mano
Agente en Vercel/Railway con tests o evals	GitHub Actions + autodeploy condicionado	El test corre primero; el deploy nativo se desactiva o se dispara con un hook
Agente self-hosted en VPS	GitHub Actions + SSH o docker compose remoto	No hay autodeploy nativo; tú eres el orquestador
Production crítica (dinero, clientes)	GitHub Environments + aprobación	Un revisor aprueba el job de Production antes de que corra

La mayoría de agentes de un builder individual viven en las dos primeras filas. Añadir Actions "porque sí" es complejidad sin ganancia.

Autodeploy nativo: lo que ya tienes

Vercel. El Git integration despliega Preview en cada PR y Production en la rama de producción. Un Deploy Hook es una URL POST que dispara un deploy sin commit — útil cuando tu agente genera un artefacto (eval report, índice RAG) y quieres redeployar el frontend.

Railway. Un servicio ligado a un repo despliega automáticamente al push de la rama conectada. Se desactiva con un clic en Service Settings; para disparar a mano, Command Palette → Deploy Latest Commit. Requisito: el proyecto tiene los permisos de GitHub necesarios.

Si tu flujo es "push a main = producción" y no hay tests, para aquí. El resto de la guía es para cuando eso ya no alcanza.

GitHub Actions: el workflow mínimo que sí vale

Cuando el agente tiene tests (unitarios, evals, un pnpm test que no es teatro), el pipeline mínimo es:

name: ci
on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: pnpm
      - run: pnpm install --frozen-lockfile
      - run: pnpm test
      - run: pnpm build

El snippet usa @v4 para caber en una pantalla. En el workflow de prod, GitHub pide anclar actions al SHA completo de 40 caracteres: es la única forma que documentan como release inmutable. Un tag @v4 se puede mover. La guía de pin Docker cubre el mismo criterio para FROM y para uses:.

Nada más. Sin deploy. El autodeploy nativo de Vercel/Railway sigue siendo quien publica, y este job es el gate: si el test falla, el PR no se mergea, y Production no se toca. Para secretos del job (API keys de evals), usa secrets.NOMBRE — la guía de secretos cubre el resto.

Environments: el gate humano

GitHub Environments te deja proteger un job con revisores obligatorios. El patrón:

  deploy-prod:
    needs: test
    if: github.ref == 'refs/heads/main'
    environment: production
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
      - run: pnpm dlx vercel deploy --prod --token=${{ secrets.VERCEL_TOKEN }}

El job espera a que alguien apruebe en la pestaña Environments antes de correr. Úsalo cuando un deploy malo cuesta dinero o clientes; no lo uses para un agente interno de un solo usuario — es fricción.

VPS: el caso que sí necesita Actions

En self-hosting con Docker no hay autodeploy. El workflow que sí vale:

  deploy-vps:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.VPS_HOST }}
          username: deploy
          key: ${{ secrets.VPS_SSH_KEY }}
          script: |
            cd /opt/mi-agente
            git pull
            docker compose up -d --build
            docker image prune -f

La llave SSH vive en GitHub Secrets, no en el repo. El usuario deploy en el VPS tiene acceso solo a /opt/mi-agente, no a root.

Errores comunes

Síntoma	Causa típica	Fix
Production se actualiza aunque el test falle	Autodeploy nativo no espera a Actions	Desactiva autodeploy y dispara el deploy desde el job, o usa Environments
Secrets del agente aparecen en logs de Actions	echo $API_KEY o un SDK verboso	GitHub enmascara secrets.*; no imprimas el entorno
Deploy Hook de Vercel se dispara dos veces	Autodeploy + hook al mismo commit	Elige uno: o Git integration o hook, no ambos
Railway redeploya PRs a Production	La rama trigger apunta a * o a una rama equivocada	Fija la rama en Service Settings
VPS deploy falla por permisos	Usuario SSH es root o no tiene Docker	Usuario deploy en el grupo docker, directorio propio

Checklist

• Autodeploy nativo activo o Actions dispara el deploy, nunca los dos
• Tests corren en cada PR
• Production protegida con Environment si el agente atiende clientes
• Secretos del pipeline en GitHub Secrets, no en el YAML
• Rollback conocido: Vercel/Railway redeployan un deployment previo; en VPS es git checkout + compose up

---

Siguiente paso: combina este pipeline con sandboxing si el agente ejecuta código, y con secretos para las credenciales del job. El pipeline no reemplaza ninguna de las dos capas. Si aún no tienes el agente local, el curso gratuito es el punto de partida antes de cablear Actions.