Producción (Hetzner + Coolify) — acceso y ejecución

Verificado contra el servidor el 2026-08-12 en solo lectura. — Opix

Esta página sustituye a lo que dicen Infraestructura y Limitaciones-servidor-prod sobre producción: ambas describen el servidor anterior (cPanel/CDMON, 134.0.10.170, /web/wp-nuevo), retirado en el cutover a Hetzner del 2026-08-03.

SSH

ssh -i ~/.ssh/id_ed25519 rafa@188.40.120.157
# también por Tailscale:
ssh rafa@srv1.taild3aaf6.ts.net

⚠️ La clave es ~/.ssh/id_ed25519 (comentario claude-code@feadulta). La otra clave del directorio, ~/.ssh/feadulta_ed25519 (claude-code@wsl-feadulta-deploy, mayo 2026), da Permission denied: es de la etapa CDMON. Es un error fácil de cometer porque el nombre parece el correcto.

FEA_PROD_SSH_PASS en el perfil de Hermes está vacío a propósito: la autenticación es por clave. Los scripts sync_*_to_prod.py caen a ssh normal (sin sshpass) cuando esa variable está vacía. No es un valor que falte por rellenar.

El contenedor de WordPress


Contenedor	`wordpress-r2ssjifwj0r0ghyoqd528uaa`
Imagen	`wordpress:latest` — WordPress 7.0.3
PHP	8.3.31 (CLI) en `/usr/local/bin/php`
Docroot	`/var/www/html` (volumen persistente `r2ssjifwj0r0ghyoqd528uaa_wordpress-files`)
BD	contenedor `mysql-r2ssjifwj0r0ghyoqd528uaa` (MySQL 8)
Servicio Coolify	`feadulta-wp`, uuid `r2ssjifwj0r0ghyoqd528uaa`

En el mismo host conviven tres WordPress (feadulta, summaraise, aqtalent), el relay de Buzz, el CRM Relaticle, Beszel y el mirror estático de Joomla. Comprueba siempre el nombre completo del contenedor antes de un docker exec.

⚠️ No hay WP-CLI en el contenedor

command -v wp → nada. La imagen oficial wordpress:latest no lo incluye; no es un fallo de configuración ni algo que se haya perdido.

La vía correcta es php -r cargando wp-load.php — es lo que describe FEA_PROD_WPLOAD del perfil de Hermes.

ssh -i ~/.ssh/id_ed25519 rafa@188.40.120.157 \
  "docker exec wordpress-r2ssjifwj0r0ghyoqd528uaa php -r \
   'require \"/var/www/html/wp-load.php\"; echo home_url(),\"|\",get_bloginfo(\"version\"),\"|\",wp_count_posts()->publish;'"

Salida real del 2026-08-12:

https://www.feadulta.com|7.0.3|29435

Scripts largos

scp -i ~/.ssh/id_ed25519 script.php rafa@188.40.120.157:/tmp/script.php
ssh -i ~/.ssh/id_ed25519 rafa@188.40.120.157 \
  'docker cp /tmp/script.php wordpress-r2ssjifwj0r0ghyoqd528uaa:/tmp/script.php && \
   docker exec wordpress-r2ssjifwj0r0ghyoqd528uaa php /tmp/script.php'

⚠️ Para copiar directorios, usa docker cp origen/. <c>:/destino/ con el /. final. Sin él, si el destino ya existe, Docker crea destino/origen anidado — y WordPress no carga mu-plugins desde subdirectorios, así que el despliegue queda silenciosamente inactivo. Ver Trampas-del-entorno.

Verificación: Cloudflare sigue delante

curl -sI https://www.feadulta.com devuelve 403 con cf-mitigated: challenge, incluso desde el propio servidor. No se puede certificar nada con curl, Playwright, headless ni wp_remote_get. La verificación de producción es server-side (docker exec … php -r) o navegación humana real.

Desde dentro del servidor, curl -H 'Host: www.feadulta.com' http://127.0.0.1/ sí llega al origen (302), saltándose Cloudflare.

Credenciales

No están en esta wiki y no deben estarlo. Viven en:

~/.hermes/profiles/feadulta/.env (WSL) — host SSH, contenedor, wp-load.
~/.env (WSL, permisos 600) — tokens de Gitea.
~/.ssh/id_ed25519 — clave de acceso al servidor.

Local, para contraste

docker exec wordpress-web php -r 'require "/var/www/html/wp-load.php"; echo home_url();'
docker cp /tmp/x.php wordpress-web:/tmp/x.php && \
  docker exec wordpress-web wp eval-file /tmp/x.php --allow-root --path=/var/www/html

El local sí tiene wp-cli pero no cliente mysql: wp db query falla, hay que usar wp eval-file. QA visual siempre contra https://farmer.taild3aaf6.ts.net/fea/, que es el siteurl real — localhost:8081 sirve desde la raíz y las @font-face caen por CORS.