Deja de usar FTP: Despliegue moderno de WordPress con SSH, Git y claves

Si esta viendo “Error 29” en Total Commander o “Connection Timed Out” en FileZilla, el universo le esta enviando un mensaje. Deje de usar FTP.

Conozca más sobre los servicios de desarrollo WordPress en WPPoland.

En 2010, FTP era el estándar. En 2026, arrastrar y soltar archivos a un servidor de producción es temerario. Esto conduce a:

• Tiempo de inactividad: Que ocurre si su internet se corta mientras sube functions.php?
• Riesgos de seguridad: FTP envia contrasenas en texto plano (a menos que use FTPS).
• Sin historial: Quien cambio ese archivo? Cuando? Por que?

#Nivel 1: SFTP y claves SSH (el minimo indispensable)

Si debe transferir archivos manualmente, use SFTP (Protocolo de Transferencia de Archivos SSH). Se ejecuta sobre el puerto 22 y esta completamente cifrado.

Mejor aun, use claves SSH en lugar de contrasenas.

1. Generar una clave: ssh-keygen -t ed25519 -C "su@email.com"
2. Copiar al servidor: ssh-copy-id user@host
3. Configurar: Edite ~/.ssh/config para acceso fácil.

Host misite
    HostName 192.168.1.100
    User wppoland
    IdentityFile ~/.ssh/id_ed25519

Ahora puede simplemente escribir ssh misite o conectarse via SFTP sin escribir una contrasena cada vez.

#Nivel 2: Git y “Git pull” (el paso intermedio)

Deje de editar código en el servidor. Edite localmente, haga commit en Git y pull en el servidor.

1. Local: git push origin main
2. Servidor: cd /var/www/html && git pull origin main

Ventajas: Tiene historial de versiones. Puede revertir cambios (git reset --hard). Desventajas: No es atomico. El sitio podria fallar durante unos segundos durante el git pull si los archivos no coinciden.

#Nivel 3: Despliegues atomicos (el estándar PRO)

Los hosts profesionales de WordPress (Kinsta, WPEngine, SpinupWP) o herramientas como DeployerPHP usan “Despliegues Atomicos”.

Como funciona:

1. El código se sube a una nueva carpeta: /releases/2026-12-23-0800/
2. Se instalan las dependencias (Composer, NPM).
3. Un enlace simbolico /current se cambia de la carpeta antigua a la nueva.

Resultado: Cero tiempo de inactividad. El cambio ocurre en milisegundos. Si la construccion falla, el enlace simbolico nunca cambia y el sitio permanece activo.

#Herramientas para usar en 2026

• Local: LocalWP o DDEV.
• Repositorio: GitHub / GitLab.
• Despliegue:
  • GitHub Actions: Pipelines CI/CD gratuitos.
  • DeployHQ: GUI simple para despliegues.
  • Buddy.works: Optimizado para WP.

#Por que los despliegues modernos son esenciales para la seguridad

La seguridad es una de las razones más convincentes para abandonar FTP. Cada vez que un desarrollador escribe una contrasena FTP, esa credencial viaja sin cifrar por la red. Un atacante con acceso a cualquier punto intermedio puede interceptarla fácilmente.

Las claves SSH, por otro lado, utilizan criptografia asimetrica. La clave privada nunca abandona su maquina local, y la clave pública en el servidor solo puede verificar, no revelar, su identidad. Esto elimina por completo la superficie de ataque basada en contrasenas.

Además, los despliegues basados en Git proporcionan una pista de auditoria completa. Cada cambio esta registrado con autor, fecha y mensaje de commit. Si algo sale mal, puede identificar exactamente que cambio causo el problema y quien lo hizo.

Para sitios de comercio electronico con WooCommerce, donde se manejan datos de pago y clientes, esta trazabilidad no es un lujo sino un requisito de cumplimiento normativo.

#Automatizacion con GitHub Actions

GitHub Actions permite configurar pipelines de despliegue que se ejecutan automáticamente cada vez que hace push a una rama específica. Un flujo de trabajo tipico incluye:

1. Pruebas automáticas: Ejecutar PHPUnit y linters antes del despliegue.
2. Construccion de assets: Compilar CSS/JS con Vite o webpack.
3. Despliegue: Subir archivos al servidor via SSH.
4. Verificación: Comprobar que el sitio responde correctamente despues del despliegue.

name: Deploy WordPress
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy via SSH
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.HOST }}
          username: ${{ secrets.USER }}
          key: ${{ secrets.SSH_KEY }}
          script: |
            cd /var/www/html
            git pull origin main
            composer install --no-dev
            wp cache flush

Esta automatizacion elimina el error humano y garantiza que cada despliegue siga exactamente el mismo proceso, reduciendo significativamente el riesgo de errores en producción.

#Gestión de entornos multiples

En un flujo de trabajo profesional, necesita al menos tres entornos:

• Desarrollo (local): Donde escribe y prueba código nuevo.
• Staging: Una copia del sitio de producción donde verifica cambios antes del despliegue.
• Producción: El sitio en vivo que ven los visitantes.

Git facilita este flujo con ramas:

• develop → se despliega automáticamente a staging
• main → se despliega automáticamente a producción

Cada entorno tiene su propia configuración de base de datos y variables de entorno, gestionadas a través de archivos .env que nunca se incluyen en el repositorio Git.

#Migración de FTP a Git: Plan paso a paso

Si actualmente usa FTP y quiere migrar a un flujo basado en Git, siga estos pasos:

1. Semana 1: Configure claves SSH y practique la conexión por terminal.
2. Semana 2: Inicialice un repositorio Git local con su código actual.
3. Semana 3: Configure un repositorio remoto en GitHub o GitLab.
4. Semana 4: Practique el flujo push/pull entre su maquina y el servidor.
5. Semana 5-6: Implemente despliegues automáticos con GitHub Actions.
6. Semana 7-8: Configure despliegues atomicos si su hosting lo permite.

No necesita hacer todo de golpe. Cada paso individual ya mejora su flujo de trabajo comparado con FTP.

#Rollback y recuperacion ante desastres

Una de las mayores ventajas de los despliegues modernos es la capacidad de reversión instantanea. Si un despliegue introduce un error, puede:

• Con Git: git revert HEAD y hacer push nuevamente.
• Con despliegues atomicos: Cambiar el enlace simbolico /current a la carpeta de la versión anterior.
• Con GitHub Actions: Volver a ejecutar un despliegue anterior desde el historial de acciones.

En contraste, con FTP tendria que recordar que archivos cambio, buscar versiones anteriores (si las tiene) y subirlas manualmente, un proceso que puede tomar horas mientras su sitio esta caido.

Para sitios críticos que requieren mantenimiento profesional de WordPress, tener una estrategia de rollback solida es absolutamente esencial.

#Monitoreo post-despliegue

Despues de cada despliegue, es importante verificar que todo funciona correctamente:

• Verificación de salud: Comprobar que las páginas principales responden con código 200.
• Core Web Vitals: Asegurarse de que el rendimiento no se ha degradado.
• Logs de errores: Monitorear debug.log durante las primeras horas.
• Funcionalidad crítica: Verificar formularios, carrito de compras y páginas de pago.

Herramientas como UptimeRobot o Pingdom pueden alertarle automáticamente si algo sale mal despues de un despliegue.

#Resumen

“Error 29” no es un bug. Es una señal recordandole que actualice su flujo de trabajo.

1. Abandone FTP por SFTP.
2. Use claves SSH.
3. Migre a despliegues basados en Git.

Su yo futuro (y sus clientes) le agradeceran cuando pueda revertir una actualización rota en 3 segundos.

Conozca más sobre la optimización de velocidad de WordPress y los servicios de seguridad WordPress en WPPoland.