Despliegue moderno de WordPress 2026: FTP vs SSH/Git | WPPoland

Mariusz Szatkowski

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

Última verificación: 12 de octubre de 2026

18 min de lectura

Guía

Si estás viendo “Error 29” en Total Commander o “Connection Timed Out” en FileZilla, el universo te está enviando un mensaje. Deja de usar FTP.

Conoce 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 tu internet se corta mientras subes functions.php?
Riesgos de seguridad: FTP envía contraseñas en texto plano (a menos que uses FTPS).
Sin historial: Quién cambio ese archivo? Cuando? ¿Por qué?

#Cómo configurar SFTP y claves SSH para WordPress

Si debes transferir archivos manualmente, usa SFTP (Protocolo de Transferencia de Archivos SSH). Se ejecuta sobre el puerto 22 y está completamente cifrado.

Mejor aun, usa claves SSH en lugar de contraseñas.

Generar una clave: ssh-keygen -t ed25519 -C "[email protected]"
Copiar al servidor: ssh-copy-id user@host
Configurar: Edita ~/.ssh/config para acceso fácil.

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

Ahora puedes simplemente escribir ssh misite o conectarse vía SFTP sin escribir una contraseña cada vez.

#Desplegar WordPress con git pull en el servidor

Deja de editar código en el servidor. Edita localmente, haz commit en Git y pull en el servidor.

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

Ventajas: Tienes historial de versiones. Puedes revertir cambios (git reset --hard). Desventajas: No es atómico. El sitio podría fallar durante unos segundos durante el git pull si los archivos no coinciden.

#Qué son los despliegues atómicos en WordPress

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

Como funciona:

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

Resultado: Cero tiempo de inactividad. El cambio ocurre en milisegundos. Si la construcción falla, el enlace simbólico nunca cambia y el sitio permanece activo.

#Herramientas para desplegar WordPress 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 qué FTP es inseguro frente a SSH y Git

La seguridad es una de las razones más convincentes para abandonar FTP. Cada vez que un desarrollador escribe una contraseña 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 criptografía asimétrica. La clave privada nunca abandona tu máquina local, y la clave pública en el servidor solo puede verificar, no revelar, tu identidad. Esto elimina por completo la superficie de ataque basada en contraseñas.

Además, los despliegues basados en Git proporcionan una pista de auditoría completa. Cada cambio está registrado con autor, fecha y mensaje de commit. Si algo sale mal, puedes identificar exactamente que cambio causó el problema y quién lo hizo.

Para sitios de comercio electrónico con WooCommerce, donde se manejan datos de pago y clientes, está trazabilidad no es un lujo sino un requisito de cumplimiento normativo.

#Desplegar WordPress con GitHub Actions

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

Pruebas automáticas: Ejecutar PHPUnit y linters antes del despliegue.
Construcción de assets: Compilar CSS/JS con Vite o webpack.
Despliegue: Subir archivos al servidor vía SSH.
Verificación: Comprobar que el sitio responde correctamente después del despliegue.

name: Deploy WordPress
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy vía 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 automatización elimina el error humano y garantiza que cada despliegue siga exactamente el mismo proceso, reduciendo significativamente el riesgo de errores en producción.

#Entornos local, staging y producción en WordPress

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

Desarrollo (local): Donde escribes y pruebas código nuevo.
Staging: Una copia del sitio de producción donde verificas 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 usas FTP y quieres migrar a un flujo basado en Git, sigue estos pasos:

Semana 1: Configura claves SSH y practica la conexión por terminal.
Semana 2: Inicializa un repositorio Git local con tu código actual.
Semana 3: Configura un repositorio remoto en GitHub o GitLab.
Semana 4: Practica el flujo push/pull entre tu máquina y el servidor.
Semana 5-6: Implementa despliegues automáticos con GitHub Actions.
Semana 7-8: Configura despliegues atómicos si tu hosting lo permite.

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

#Cómo hacer rollback de un despliegue en WordPress

Una de las mayores ventajas de los despliegues modernos es la capacidad de reversión instantánea. Si un despliegue introduce un error, puedes:

Con Git: git revert HEAD y hacer push nuevamente.
Con despliegues atómicos: Cambiar el enlace simbólico /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 tendrías que recordar que archivos cambiaste, buscar versiones anteriores (si las tienes) y subirlas manualmente, un proceso que puede tomar horas mientras tu sitio está caído.

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

#Qué revisar después de desplegar WordPress

Después 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 alertarte automáticamente si algo sale mal después de un despliegue.

#Dónde guardar las credenciales en un flujo con Git

Con Git las contraseñas siguen existiendo: cambian de sitio. Hay tres lugares donde viven los secretos, y ninguno es el repositorio.

Clave privada SSH: se queda en tu máquina. En el servidor solo está la pública, dentro de authorized_keys, que verifica tu identidad pero no la revela. Si pierdes el portátil, retira esa clave del servidor y genera un par nuevo con ssh-keygen -t ed25519.
Secretos del pipeline: el flujo de GitHub Actions lee HOST, USER y SSH_KEY desde los secrets del repositorio. No escribas esos valores en el YAML, porque el archivo queda versionado.
Configuración de cada entorno: las credenciales de base de datos de desarrollo, staging y producción van en archivos .env que nunca entran en Git. Añádelos a .gitignore antes del primer commit, no después.

El motivo es el mismo historial que hace útil a Git. Cada versión queda registrada con autor y fecha, así que una contraseña subida por error sigue en el historial aunque la borres en el commit siguiente. Si ocurre, cambia la contraseña; quitarla del archivo no basta.

#Cómo desplegar WordPress con rsync sobre SSH

Mientras que Git gestiona el control de versiones y el historial del equipo, rsync es la herramienta de referencia para sincronizar archivos procesados o artefactos hacia los servidores de producción. Transfiere exclusivamente los bloques modificados entre origen y destino mediante sumas de verificación delta, reduciendo drásticamente el tiempo de transferencia y el consumo de ancho de banda respecto a SFTP o copias completas con SCP.

#Diferencias entre rsync, SCP y FTP

SCP transfiere siempre la totalidad de cada archivo, sin importar si solo se alteró una línea de código. FTP carece de algoritmos de sincronización incremental y no valida sumas de comprobación criptográficas durante la sesión. Por contra, rsync examina tamaños de archivo y marcas de tiempo, calcula bloques binarios modificados y transmite únicamente esas diferencias. Además, su ejecución sobre una capa de transporte SSH mantiene la sesión cifrada y autenticada mediante claves criptográficas.

#Comando de despliegue rsync con simulación previa

Antes de sincronizar cambios con un entorno en producción, es una buena práctica técnica ejecutar una simulación en seco con --dry-run para auditar la lista de archivos afectados y prevenir el borrado accidental de datos dinámicos:

rsync -avz --dry-run --delete \
  --exclude='.git' \
  --exclude='wp-config.php' \
  --exclude='wp-content/uploads' \
  --exclude='.env' \
  --exclude='node_modules' \
  ./dist/ user@servidor:/var/www/html/

Tras revisar la salida del comando y comprobar que las exclusiones protegen los directorios no versionados, retira la bandera --dry-run para aplicar los cambios en el servidor:

rsync -avz --delete \
  --exclude='.git' \
  --exclude='wp-config.php' \
  --exclude='wp-content/uploads' \
  --exclude='.env' \
  --exclude='node_modules' \
  ./dist/ user@servidor:/var/www/html/

El parámetro --delete elimina del servidor de destino los archivos que ya no existan en tu compilación local, garantizando que código desfasado o plugins retirados no permanezcan activos en producción. Las reglas --exclude aseguran que las subidas de medios de los usuarios (uploads), las variables de entorno (.env) y la base de datos de control de versiones (.git) no sufran sobrescrituras destructivas.

#Estructura de un repositorio Git para proyectos WordPress

Uno de los errores más frecuentes al migrar desde FTP a Git es intentar versionar la totalidad del directorio raíz de WordPress, incluyendo el núcleo descargado, las carpetas de subidas de imágenes y los volcados de bases de datos. Un repositorio limpio debe versionar únicamente el código personalizado desarrollado para el proyecto.

#Organización modular del repositorio

El repositorio versiona exclusivamente los temas propios, los plugins a medida y los plugins imprescindibles (mu-plugins). El núcleo de WordPress y los plugins de terceros se gestionan mediante Composer o se instalan como dependencias externas:

wordpress-project/
├── .gitignore
├── composer.json
├── wp-content/
│   ├── themes/
│   │   └── wppoland-theme/    # versionado
│   ├── plugins/
│   │   └── wppoland-custom/   # versionado
│   └── mu-plugins/            # versionado
└── wp-config.php              # no versionado

#Reglas esenciales en el archivo gitignore

El archivo .gitignore debe excluir explícitamente el núcleo de WordPress, los medios interactivos generados por los usuarios, las carpetas de dependencias y los archivos de configuración confidenciales:

/wp-admin/
/wp-includes/
/wp-content/uploads/
/wp-content/upgrade/
wp-config.php
.env
*.log
node_modules/
vendor/

Excluir wp-content/uploads/ evita que el repositorio alcance gigabytes de tamaño con fotografías, vídeos o documentos que deben residir en almacenamiento de objetos (como Amazon S3 o Cloudflare R2) o mantenerse sincronizados fuera de Git.

#Gestión de dependencias de WordPress con Composer

El gestor de dependencias Composer y el repositorio comunitario WPackagist permiten declarar plugins y temas de WordPress como paquetes versionados con versiones exactas, garantizando reproducibilidad matemática en cada despliegue:

{
  "require": {
    "wpackagist-plugin/advanced-custom-fields": "^6.0",
    "wpackagist-plugin/wordpress-seo": "^22.0",
    "wpackagist-plugin/wp-super-cache": "^1.9"
  },
  "repositories": [
    {
      "type": "composer",
      "url": "https://wpackagist.org"
    }
  ]
}

Al ejecutar composer install --no-dev --optimize-autoloader durante el pipeline de integración o directamente en el servidor mediante SSH, se descargan las versiones exactas sin necesidad de ensuciar el árbol de Git con miles de archivos de terceros.

#Comandos WP-CLI esenciales para administración sobre SSH

La interfaz de línea de comandos de WordPress (WP-CLI) combinada con SSH permite ejecutar tareas administrativas complejas en segundos, eliminando la necesidad de acceder al panel de administración de WordPress a través del navegador.

#Actualizaciones y mantenimiento del núcleo

# Actualizar el código base de WordPress y ejecutar migraciones de base de datos
wp core update
wp core update-db

# Gestión de extensiones y plugins
wp plugin install wordpress-seo --activate
wp plugin update --all
wp plugin deactivate wordfence

# Optimización y mantenimiento de tablas MySQL
wp db optimize
wp db repair

# Regeneración de sales criptográficas en wp-config.php
wp config shuffle-salts

# Modo de mantenimiento para despliegues programados
wp maintenance-mode activate
wp maintenance-mode deactivate

#Sustitución precisa de URLs sin corromper datos serializados

El mayor riesgo técnico al migrar bases de datos de WordPress reside en las matrices serializadas (serialized PHP arrays) almacenadas en las tablas wp_options y wp_postmeta. Una búsqueda y sustitución directa con sentencias SQL altera la longitud de las cadenas serializadas, invalidando los objetos PHP y rompiendo widgets, configuraciones de temas o constructores visuales. WP-CLI resuelve este problema recalculando las longitudes de los datos serializados en tiempo real:

wp search-replace 'https://staging.wppoland.com' 'https://wppoland.com' --all-tables --precise

#Ejecución remota de WP-CLI mediante alias SSH

Es posible definir alias de conexión en el archivo ~/.wp-cli/config.yml en la máquina del desarrollador para interactuar con servidores remotos sin abrir manualmente una sesión interactiva de shell:

@prod:
  ssh: [email protected]/var/www/html
@staging:
  ssh: [email protected]/var/www/html

A partir de esta configuración, cualquier comando se puede ejecutar directamente desde el terminal local:

wp @prod plugin list
wp @prod cache flush
wp @prod cron event run --due-now

#Configuración desacoplada de entornos con phpdotenv

Mantener credenciales de base de datos incrustadas en wp-config.php impide versionar el archivo o compartir la configuración entre múltiples entornos. Una arquitectura moderna desacopla la lógica del framework de los secretos operativos mediante variables de entorno y librerías como vlucas/phpdotenv.

#Implementación del patrón de doce factores en WordPress

En la raíz del proyecto, el archivo .env almacena los parámetros específicos de cada entorno:

DB_NAME=wppoland_prod
DB_USER=wp_user
DB_PASSWORD=clave_aleatoria_muy_segura
DB_HOST=localhost
WP_HOME=https://wppoland.com
WP_SITEURL=https://wppoland.com
WP_ENVIRONMENT_TYPE=production

En wp-config.php, el cargador de Composer inicializa las variables de entorno de forma transparente:

<?php
require_once __DIR__ . '/vendor/autoload.php';

if ( file_exists( __DIR__ . '/.env' ) ) {
    $dotenv = Dotenv\Dotenv::createImmutable( __DIR__ );
    $dotenv->load();
}

define( 'DB_NAME', $_ENV['DB_NAME'] );
define( 'DB_USER', $_ENV['DB_USER'] );
define( 'DB_PASSWORD', $_ENV['DB_PASSWORD'] );
define( 'DB_HOST', $_ENV['DB_HOST'] ?: 'localhost' );
define( 'WP_HOME', $_ENV['WP_HOME'] );
define( 'WP_SITEURL', $_ENV['WP_SITEURL'] );
define( 'WP_ENVIRONMENT_TYPE', $_ENV['WP_ENVIRONMENT_TYPE'] ?: 'production' );

define( 'WP_DEBUG', $_ENV['WP_ENVIRONMENT_TYPE'] !== 'production' );
define( 'WP_DEBUG_LOG', $_ENV['WP_ENVIRONMENT_TYPE'] !== 'production' );
define( 'WP_DEBUG_DISPLAY', false );

Con este patrón arquitectónico promovido por proyectos como Bedrock, el archivo wp-config.php es completamente estático y seguro para versionar, mientras que las contraseñas reales residen únicamente en los servidores que las requieren.

#Arquitectura de despliegues atómicos con enlaces simbólicos

Un problema crítico del despliegue manual mediante FTP o la ejecución directa de git pull en la carpeta raíz pública es el estado inconsistente transitorio. Durante los segundos o minutos que tardan en descargarse los archivos PHP, un usuario o rastreador web que visite la página puede cargar una plantilla nueva que requiera una función aún no presente en un plugin a medio transferir, provocando errores fatales de PHP o pantallas en blanco.

#Estructura de directorios de tipo Deployer y Capistrano

Los despliegues atómicos resuelven este problema mediante una arquitectura inspirada en herramientas como Capistrano y Deployer:

/var/www/misitio/
├── current -> /var/www/misitio/releases/20261012120000/
├── releases/
│   ├── 20261012100000/
│   ├── 20261012110000/
│   └── 20261012120000/
└── shared/
    ├── .env
    └── wp-content/
        └── uploads/

#Mecanismo de conmutación atómica

Cada despliegue clona el código o transfiere los artefactos a una nueva carpeta dentro de releases/ identificada por la marca de tiempo de la versión (timestamp).
Se generan enlaces simbólicos relativos hacia los recursos compartidos persistentes ubicados en shared/, como la carpeta uploads y el archivo .env.
Se ejecutan las tareas de compilación y optimización: composer install, construcción de estilos CSS y scripts JS, y pruebas de humo.
Cuando todo el proceso finaliza con éxito, el enlace simbólico del directorio activo se actualiza en una única operación atómica a nivel del sistema de archivos POSIX:

ln -sfn /var/www/misitio/releases/20261012120000 /var/www/misitio/current_temp && mv -Tf /var/www/misitio/current_temp /var/www/misitio/current

La llamada al sistema rename() subyacente es atómica en sistemas operativos Unix. Para el servidor web Nginx o Apache, el cambio de versión ocurre en un microsegundo. Si la instalación de dependencias o la compilación fallan a mitad del proceso, la carpeta del nuevo release se descarta y el sitio web en producción continúa sirviendo la versión anterior sin sufrir una sola décima de segundo de interrupción.

#Reversión instantánea ante incidentes

Si tras activar el despliegue se detecta una regresión en producción, la reversión no requiere descargar copias de seguridad ni reconstruir paquetes. Basta con apuntar el enlace simbólico current a la carpeta del release anterior y vaciar la memoria caché de OPcache y Redis:

ln -sfn /var/www/misitio/releases/20261012110000 /var/www/misitio/current
wp cache flush
sudo systemctl reload php8.3-fpm

#Automatización con repositorios bare y hooks post-receive

Para proyectos que no requieren plataformas completas de integración continua en la nube como GitHub Actions o GitLab CI, es posible implementar un flujo de trabajo push-to-deploy nativo utilizando únicamente Git en el propio servidor Linux.

#Configuración de un repositorio bare en el servidor

En el servidor remoto, se crea un repositorio sin árbol de trabajo (bare repository):

mkdir -p /var/repo/misitio.git
cd /var/repo/misitio.git
git init --bare

#Creación del hook de despliegue post-receive

En /var/repo/misitio.git/hooks/post-receive, se define un script ejecutable que procesa cada push recibido:

#!/bin/bash
TARGET_DIR="/var/www/misitio/releases/$(date +%Y%m%d%H%M%S)"
SHARED_DIR="/var/www/misitio/shared"
CURRENT_LINK="/var/www/misitio/current"

echo "===> Iniciando despliegue de WordPress..."
mkdir -p "$TARGET_DIR"

# Extraer el árbol de trabajo desde la rama main
git --work-tree="$TARGET_DIR" --git-dir=/var/repo/misitio.git checkout -f main

# Enlazar recursos compartidos
ln -s "$SHARED_DIR/.env" "$TARGET_DIR/.env"
rm -rf "$TARGET_DIR/wp-content/uploads"
ln -s "$SHARED_DIR/wp-content/uploads" "$TARGET_DIR/wp-content/uploads"

# Instalar dependencias de Composer si existe composer.json
if [ -f "$TARGET_DIR/composer.json" ]; then
    cd "$TARGET_DIR" && composer install --no-dev --optimize-autoloader --quiet
fi

# Migración de base de datos de WordPress si es necesario
wp core update-db --path="$TARGET_DIR" --quiet

# Conmutar enlace simbólico de forma atómica
ln -sfn "$TARGET_DIR" "${CURRENT_LINK}_temp" && mv -Tf "${CURRENT_LINK}_temp" "$CURRENT_LINK"

# Purgar caché de objetos y reiniciar OPcache
wp cache flush --path="$CURRENT_LINK" --quiet
sudo systemctl reload php8.3-fpm

echo "===> Despliegue completado con éxito."

Habilita los permisos de ejecución en el hook:

chmod +x /var/repo/misitio.git/hooks/post-receive

#Configuración del remoto local para despliegue

En la máquina local de desarrollo, agrega el servidor como un remoto de Git adicional:

git remote add production deploy@servidor:/var/repo/misitio.git
git push production main

Con este sencillo comando, Git transfiere los deltas de código comprimidos por SSH, el hook del servidor inicializa la carpeta de release, vincula los archivos compartidos, compila las dependencias y conmuta el enlace simbólico sin tiempos muertos.

#Endurecimiento de la seguridad del servidor tras el despliegue

Un canal de despliegue moderno es tan seguro como la configuración del servidor sobre el que opera. Una vez deshabilitado el acceso por contraseñas e instaurado el flujo automatizado, deben aplicarse medidas de fortificación adicionales.

#Desactivación de interfaces heredadas y XML-RPC

El protocolo XML-RPC es una interfaz histórica que suele ser explotada para ataques de amplificación de denegación de servicio (DDoS) y ataques de fuerza bruta contra el sistema de autenticación. A menos que se utilicen integraciones específicas de la aplicación móvil de WordPress o plugins como Jetpack, debe desactivarse completamente mediante un filtro en mu-plugins:

add_filter( 'xmlrpc_enabled', '__return_false' );

Adicionalmente, se puede bloquear el acceso a nivel de servidor web en Nginx:

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

#Permisos estrictos en el sistema de archivos POSIX

Los archivos de la aplicación nunca deben tener permisos de escritura global. En una arquitectura de despliegue profesional, el usuario que ejecuta los despliegues (por ejemplo deploy) es el propietario de los archivos de código fuente, mientras que el proceso del servidor web (por ejemplo www-data) solo necesita permisos de lectura para el código PHP y permisos de escritura limitados a la carpeta uploads:

# Permisos estándar para archivos y directorios
find /var/www/misitio/current -type f -exec chmod 644 {} \;
find /var/www/misitio/current -type d -exec chmod 755 {} \;

# Restricción máxima para configuraciones con secretos
chmod 600 /var/www/misitio/shared/.env

# Carpeta de subidas compartida con permisos de escritura para el servidor web
chown -R deploy:www-data /var/www/misitio/shared/wp-content/uploads
chmod -R 775 /var/www/misitio/shared/wp-content/uploads

#Prevención de intrusiones con fail2ban

Para proteger el puerto SSH contra escaneos automáticos de fuerza bruta, instala y configura fail2ban:

sudo apt update && sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban

En /etc/fail2ban/jail.local, configura la regla para el servicio SSH aumentando el tiempo de bloqueo y reduciendo los intentos permitidos:

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 1h
findtime = 10m

#Resumen técnico del flujo de despliegue moderno

“Error 29” no es un error sin sentido: es una señal que recuerda la urgencia de modernizar el flujo de trabajo técnico de tu equipo.

Abandona FTP y emplea SFTP exclusivamente para accesos interactivos manuales de emergencia.
Utiliza claves SSH basadas en ed25519 sin autenticación por contraseña.
Despliega mediante repositorios Git y automatizaciones de rsync con exclusiones estrictas de archivos generados por usuarios.
Adopta despliegues atómicos con enlaces simbólicos para eliminar ventanas de inconsistencia y permitir rollbacks en un solo comando.

Tu equipo de ingeniería y tus clientes valorarán la tranquilidad de saber que cualquier despliegue puede revertirse de forma fiable en milisegundos. Conoce más sobre la optimización de velocidad de WordPress y los servicios de seguridad WordPress en WPPoland.