Actualiza la web de tu cliente desde el móvil: Claude + GitHub + deploy automático

Por Juan — Founder de c6n Actualizado: 25 junio 2026 Lectura: 8 min

Las 3 piezas del sistema

Mientras la gente normal a tu alrededor se drena el alma viendo Reels en la fila del banco, tú puedes estar enviándole cambios en vivo a un cliente desde el bus. No es magia: es una tubería sencilla con tres componentes.

• Tu servidor (cPanel / hosting con FTP). Donde vive la web del cliente, en public_html. Solo necesita aceptar conexiones FTP o, mejor, FTPS.
• GitHub. Un repositorio con el código de todos tus proyectos en desarrollo. Cada cliente, su carpeta. Es la fuente de la verdad y el historial de todo lo que cambia.
• Claude. Conectado a ese repositorio. Le pides los cambios en lenguaje natural y él escribe el código, hace commit y abre el pull request por ti.

Cómo se conecta: la GitHub Action de deploy

El pegamento es una GitHub Action: un pequeño archivo YAML en .github/workflows/ que se dispara cada vez que llega un cambio a la rama main y sube los archivos por FTP a tu servidor. La acción más usada para esto es SamKirkland/FTP-Deploy-Action. Este es, casi literal, el workflow con el que se despliega c6n.eu:

name: Deploy website

on:
  push:
    branches: [main]      # se dispara al fusionar en main
    paths:
      - "site/**"          # solo si cambió la carpeta del sitio

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy por FTPS a cPanel
        uses: SamKirkland/FTP-Deploy-Action@v4.3.5
        with:
          server:   ${{ secrets.FTP_SERVER }}
          username: ${{ secrets.FTP_USERNAME }}
          password: ${{ secrets.FTP_PASSWORD }}
          protocol: ftps                 # FTP sobre TLS, nunca plano
          local-dir: site/
          server-dir: ./
          dangerous-clean-slate: false   # no borra lo que no esté en el repo
          exclude: |
            api/config.php               # protege archivos sensibles del server

Traducción: cada vez que un cambio aterriza en main, GitHub levanta una máquina, coge tu carpeta y la sube al servidor. dangerous-clean-slate: false garantiza que nunca borra archivos que no estén en el repo (como el config.php que subiste a mano), y exclude protege lo que no debe tocarse. Lo configuras una vez por proyecto y se olvida.

El flujo desde el móvil, paso a paso

La magia real pasa cuando estás apretado en el metro y el cliente te escribe: «Oye, cámbiame el texto de los precios y arregla el botón de pago que se ve raro». En vez de estresarte o sacar el portátil en medio de la calle:

1. Abres la app de Claude en el móvil.
2. Le pones el encargo: «Claude, entra a la carpeta de este cliente, cambia el texto de precios por este y arregla el diseño del botón de pago». (Cuanto más concreto seas, mejor sale — ver cómo darle contexto sin que salga genérico.)
3. Claude hace el cambio de código, hace commit y abre un pull request a main.
4. Fusionas el pull request desde el propio móvil. Ese merge dispara la GitHub Action y el servidor se actualiza solo en segundos.
5. Le respondes al cliente: «Listo, revisa la web».

¿Por qué pull request a main y no editar en producción?

Podrías editar el archivo directo en el servidor por FTP, sí. Pero entonces no tienes historial, ni revisión, ni vuelta atrás. Pasar siempre por un pull request a main te da tres seguros: ves el diff exacto antes de publicar, queda registrado quién cambió qué y cuándo, y si algo sale mal reviertes el commit y el servidor vuelve al estado anterior en el siguiente deploy. La rama main es, por definición, lo que está publicado.

Buenas prácticas y errores comunes

• Credenciales en GitHub Secrets, nunca en el repo. Servidor, usuario y contraseña van en Settings → Secrets and variables → Actions, cifrados y fuera de los logs.
• FTPS, no FTP plano. El FTP sin cifrar manda tus credenciales en texto claro. Usa protocol: ftps siempre que el hosting lo permita.
• Excluye lo sensible y lo ajeno. Con exclude protege config.php, claves y subdirectorios que gestione otra cuenta o pipeline.
• Filtra por paths. Que la Action solo se dispare cuando cambia la carpeta relevante evita deploys innecesarios y minutos gastados.
• Un repo, muchas carpetas de cliente. Centralizar los proyectos en desarrollo facilita que Claude «entre a la carpeta de este cliente» sin perderse.

Este tipo de tuberías —que un cambio se publique solo, sin tocar nada a mano— es el corazón de la automatización y del diseño web que montamos para clientes: webs que no solo se ven bien, sino que se mantienen sin fricción.

"La próxima vez que te toque perder la mañana en un trámite o atrapado en el tráfico, no llores: pon a Claude a trabajar desde el bolsillo. El servidor se actualiza solo mientras tú haces la fila." — Juan Camilo Calderón, fundador de c6n