Guía de Producción — CreaRack Pro en Hetzner

Guía de Producción — CreaRack Pro en Hetzner

Última actualización: 07-04-2026 Servidor producción: Hetzner CCX (4 vCPU AMD, 16GB RAM, 160GB NVMe) IP producción: 116.203.31.166 Dominio: https://crearack.com

Servidores

Qué es cada cosa

El Servidor (Hetzner)

Hetzner es el proveedor de hosting. Tenemos un servidor dedicado (como un PC en un datacenter en Alemania) donde corre todo. Es un servidor Linux (Ubuntu) al que accedemos por SSH.

• Precio: ~30€/mes
• Consola Hetzner: https://console.hetzner.cloud — solo para gestionar el servidor (encender, apagar, reinstalar, ver facturación)
• No tocas Hetzner a diario — solo si necesitas reiniciar el servidor o cambiar su configuración

Dokploy (Panel de gestión)

URL: http://116.203.31.166:3000

Dokploy es un panel web que gestiona los contenedores Docker en el servidor. Piensa en él como el “mando a distancia” de tu aplicación. Desde aquí puedes:

• Deploy: Actualizar la app cuando hay cambios en GitHub
• Logs: Ver qué está pasando en la app (errores, peticiones)
• Monitoring: Ver uso de CPU, RAM, disco
• Environment: Cambiar variables de configuración (claves API, contraseñas)
• Domains: Gestionar dominios y certificados SSL

Protegido con: contraseña + 2FA (Google Authenticator)

Traefik (Proxy + SSL)

Traefik es invisible para ti — lo gestiona Dokploy automáticamente. Se encarga de:

• Redirigir https://crearack.com al contenedor de Django
• Gestionar el certificado SSL (Let’s Encrypt, se renueva solo cada 90 días)
• Redirigir HTTP → HTTPS automáticamente

No necesitas tocarlo nunca.

Cloudflare (DNS)

URL: https://dash.cloudflare.com

Cloudflare gestiona el dominio crearack.com. Solo hace una cosa: decir “cuando alguien escriba crearack.com, envíalo a la IP 116.203.31.166”.

• Registros DNS: crearack.com → 116.203.31.166 (nube gris, DNS only)
• No tocas Cloudflare a diario — solo si cambias de servidor o añades subdominios

Arquitectura de la App

Internet
    │
    ▼
┌─────────────┐
│  Cloudflare  │  DNS: crearack.com → 116.203.31.166
└──────┬──────┘
       │
       ▼
┌─────────────┐
│   Traefik    │  SSL (Let's Encrypt) + Proxy
└──────┬──────┘
       │ puerto 443 (HTTPS)
       ▼
┌─────────────┐     ┌──────────────┐     ┌──────────────┐     ┌─────────────────┐
│  Django/     │────▶│  pgbouncer   │────▶│  PostgreSQL   │     │ VictoriaMetrics  │
│  Daphne      │     │  (pool=30)   │     │  v18 (BD)     │     │ (Métricas tiempo)│
│  (puerto 8000)│     │  (puerto 6432)│    │               │     │                  │
└──────┬──────┘     └──────────────┘     └──────────────┘     └─────────────────┘
       │
       ├────▶ ┌──────────────┐
       │      │    Valkey     │  Cache en memoria (sesiones, datos temporales)
       │      │  (Redis)      │  NO es una consola — es un servicio interno
       │      └──────────────┘
       │
       └────▶ ┌──────────────┐
              │  Huey Worker  │  Tareas en segundo plano (Auto-Plan AI, backups, etc.)
              └──────────────┘

pgbouncer actúa como intermediario entre Django y PostgreSQL en modo transaction. Evita que picos de conexiones (ej: Sentinel con 200+ targets) saturen la base de datos. Django se conecta a pgbouncer:6432 en vez de directamente a PostgreSQL.

Staging replica el mismo stack (Django + PostgreSQL 18 + Valkey + VictoriaMetrics) en el servidor crearack-staging. Sirve para probar cambios de infraestructura antes de aplicarlos en producción.

Qué es cada servicio Docker

Operaciones Comunes

Actualizar la app (nuevo código)

Opción A — Automático (configurado):

1. Haces git push origin main desde tu PC
2. Dokploy detecta el push y despliega automáticamente

Opción B — Manual:

1. Haces git push origin main
2. Entras en Dokploy → proyecto crearack-pro → Deployments → Deploy

Ver logs (si algo falla)

1. Dokploy → crearack-pro → pestaña Logs
2. Ahí ves los logs de Django en tiempo real (errores, peticiones, etc.)

Cambiar variables de entorno

1. Dokploy → crearack-pro → pestaña Environment
2. Edita la variable (ej: cambiar GEMINI_API_KEY)
3. Guarda y haz Deploy para aplicar

Ejecutar comandos Django (migraciones, etc.)

1. Dokploy → crearack-pro → pestaña General → Open Terminal
2. En el terminal: cd /app && python manage.py <comando>

Comandos útiles:

cd /app && python manage.py migrate              # Aplicar migraciones
cd /app && python manage.py createsuperuser       # Crear admin
cd /app && python manage.py import_iana_vendors   # Importar vendors
cd /app && python manage.py collectstatic         # Regenerar archivos estáticos

Acceder al servidor por SSH

Desde PowerShell en tu PC:

ssh edu@116.203.31.166

Usa la SSH key (~/.ssh/id_ed25519). Para acciones de administración usa sudo.

Reiniciar servicios (si algo se cuelga)

Desde Dokploy: haz Deploy (reinicia todos los contenedores).

Desde SSH (avanzado):

docker ps                           # Ver contenedores corriendo
docker restart <nombre_contenedor>  # Reiniciar uno específico

Backups

El sistema tiene múltiples capas de backup automático. No requieren intervención manual.

Backups de base de datos (PostgreSQL)

Otros backups

Restaurar desde backup

En caso de emergencia, consultar: Documentation/guides/DISASTER_RECOVERY.md

Los pasos básicos son:

1. Instalar servidor nuevo en Hetzner + Dokploy
2. Descargar pg_dump desde Object Storage con rclone
3. Restaurar con pg_restore
4. Hacer git clone del código y configurar variables de entorno

Monitorización Externa

UptimeRobot

Monitor externo que comprueba si la app está funcionando cada 5 minutos desde fuera de la red de Hetzner.

Si recibes un email de UptimeRobot, la app no está respondiendo. Pasos:

1. Intenta abrir https://crearack.com en el navegador
2. Si no carga, revisa los logs en Dokploy
3. Si Dokploy tampoco carga, conecta por SSH al servidor

Firewall

Hay dos capas de firewall:

Hetzner Cloud Firewall (panel web)

Configurado en https://console.hetzner.cloud → Firewalls. Solo deja pasar el tráfico necesario al servidor:

El resto de puertos (incluido el 3000 de Dokploy) están cerrados desde fuera.

iptables DOCKER-USER (reglas locales)

Docker crea sus propias reglas de red que a veces bypasean el firewall de Hetzner. Para controlarlo se usan reglas en la cadena DOCKER-USER:

• Puerto 3000 (Dokploy): Solo accesible desde las IPs de GitHub (webhooks de auto-deploy) y desde tu IP
• GitHub webhook IPs: Subredes de GitHub añadidas explícitamente para que los deploys automáticos funcionen

Estas reglas se configuraron en /root/restore-firewall.sh y se restauran automáticamente en cada arranque del servidor gracias a un servicio systemd. No es necesario ejecutarlas manualmente.

Si el servidor se reinicia y el auto-deploy falla, puede ser que las reglas iptables no se hayan restaurado. Verificar:

ssh edu@116.203.31.166
sudo iptables -L DOCKER-USER -n

Credenciales y Accesos

Variables de entorno importantes (en Dokploy Environment)

Flujo de Trabajo Diario

1. Desarrollas en local (localhost:8000)
         │
         ▼
2. git push origin main
         │
         ▼
3. Dokploy detecta el push
         │
         ▼
4. Construye nueva imagen Docker
         │
         ▼
5. Reinicia contenedores con nuevo código
         │
         ▼
6. https://crearack.com actualizado

No necesitas tocar Hetzner ni Cloudflare en el día a día. Solo Dokploy si quieres ver logs o cambiar configuración.

Troubleshooting

La app no carga

1. Mira los Logs en Dokploy
2. Si dice “too many clients” → haz Deploy (reinicia pgbouncer y PostgreSQL)
3. Si dice “500 Internal Server Error” → busca el traceback en Logs

Certificado SSL no funciona

1. Cloudflare DNS debe estar en nube gris (DNS only), NO naranja
2. En Dokploy → Domains → debe decir “DNS Valid” en verde
3. Espera 2-3 minutos para que Let’s Encrypt genere el certificado

Cambios no se reflejan

1. Verifica que git push fue exitoso
2. En Dokploy → Deployments → verifica que el último deploy está en verde
3. Limpia caché del navegador (Ctrl+Shift+R)

Error de migraciones

1. Dokploy → General → Open Terminal
2. cd /app && python manage.py migrate

El auto-deploy no se dispara tras un push

• Causa posible (poco frecuente desde 30-04-2026): El commit message contiene [skip ci]. Dokploy interpreta esa etiqueta como señal de saltar el deploy. La política del equipo es nunca [skip ci] (Regla 16 CLAUDE.md), así que esto solo aparece si se añadió por emergencia explícita. Revisa el último commit en GitHub.
• Otra causa: Las IPs de GitHub para webhooks no están en las reglas iptables del servidor. Verificar con sudo iptables -L DOCKER-USER -n que las subredes de GitHub están permitidas en el puerto 3000.

El worker aparece como “unhealthy” en Dokploy

El healthcheck del worker usa pgrep run_huey para detectar si el proceso Huey está corriendo. No usa curl localhost:8000 (que es el healthcheck del contenedor web). Si el worker aparece unhealthy, verificar que el proceso Huey está activo:

ssh edu@116.203.31.166
docker exec crearack-pro-zcmvsl-worker-1 pgrep run_huey

Si no devuelve ningún PID, reiniciar el contenedor desde Dokploy.

Seguridad del Servidor SSH

Configuracion aplicada (19-02-2026)

Por que es importante

• root es el primer usuario que prueban los bots (millones de intentos diarios)
• SSH key es inmune a brute-force (no se puede adivinar una clave de 256 bits)
• fail2ban bloquea IPs que insisten con intentos fallidos
• sudo requiere contraseña — doble barrera incluso si alguien consigue la SSH key

Verificar estado de seguridad

# Conectar al servidor
ssh edu@116.203.31.166

# Ver intentos de login bloqueados por fail2ban
sudo fail2ban-client status sshd

# Ver configuracion SSH activa
sudo sshd -T | grep -E "permitrootlogin|passwordauthentication"
# Debe mostrar: permitrootlogin no / passwordauthentication no

# Ver ultimos intentos de login (exitosos y fallidos)
sudo journalctl -u ssh --since "1 hour ago" | tail -20

Si pierdes acceso SSH

1. Entra a Hetzner Console (https://console.hetzner.cloud) → tu servidor → pestaña Rescue
2. Activa modo rescate → te da una contraseña temporal de root
3. Reinicia el servidor → arranca en un Linux de rescate
4. Monta el disco del servidor:

   mount /dev/sda1 /mnt

5. Desde ahi puedes editar la config SSH:

   nano /mnt/etc/ssh/sshd_config    # Reactivar PermitRootLogin o PasswordAuthentication
   nano /mnt/etc/shadow              # Resetear contraseñas (avanzado)
   cp tu_key.pub /mnt/home/edu/.ssh/authorized_keys  # Añadir nueva SSH key

6. Desmonta y reinicia normal:

   umount /mnt && reboot

Alternativamente, puedes reinstalar el SO desde Hetzner Console (borra todo el disco, Dokploy se reinstala en ~15 min).

Que se puede y que NO se puede recuperar

Credenciales criticas — guardar en gestor de contraseñas

Guarda todo esto en un lugar seguro (Bitwarden, 1Password, KeePass):

Regla de oro: Si pierdes la cuenta de Hetzner, puedes recuperar todo lo demas. Es la credencial mas importante.

Mantenimiento del Servidor (Ubuntu)

Rutina semanal (~2 minutos)

Conecta al servidor y ejecuta:

ssh edu@116.203.31.166
sudo apt update && sudo apt upgrade -y

Si tras actualizar ves el mensaje “System restart required”:

sudo reboot

El servidor se reinicia en ~30 segundos. Dokploy y todos los contenedores arrancan automaticamente.

Que se actualiza

Estas actualizaciones son del servidor Ubuntu (el host), no de la app Django (que vive dentro de Docker y se actualiza con git push).

Automatizar actualizaciones de seguridad (opcional)

Si prefieres no hacer la rutina manual, Ubuntu puede aplicar parches de seguridad solo:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades
# Seleccionar "Yes"

Esto solo instala parches de seguridad automaticamente, no actualizaciones mayores. Es seguro dejarlo activado.

Calendario de mantenimiento completo

Mantenimiento y Limpieza (Docker)

Qué se limpia automáticamente

Qué puede acumularse

Tareas de limpieza recomendadas (cada 1-2 meses)

Desde Dokploy → Open Terminal, o por SSH (ssh edu@116.203.31.166):

# 1. Ver espacio en disco actual
df -h

# 2. Limpiar imágenes Docker sin uso (>7 días antigüedad)
#    Esto es lo que más espacio libera típicamente
docker image prune -a --filter "until=168h"

# 3. Limpiar build cache de Docker
docker builder prune -f

# 4. Ver qué ocupa más espacio en Docker
docker system df

# 5. Limpieza completa (imágenes + contenedores parados + cache)
#    ⚠️ Solo si necesitas liberar mucho espacio
docker system prune -a --filter "until=168h"

Monitorear espacio en disco

El servidor tiene 160GB NVMe. Señales de alerta:

Puedes ver el uso desde:

• Hetzner Console → servidor → Graphs → Disk
• Dokploy → Monitoring
• SSH: df -h

Cloudflare — Configuración recomendada

Costes Mensuales

Firewall iptables — Restaurar acceso Dokploy

Ambos servidores (PROD y STAGE) tienen reglas iptables manuales que restringen el acceso a los puertos 3000 (Dokploy) y 8000 (Django interno). Estas reglas son independientes del firewall de Hetzner y se pierden en un reboot.

Si no puedes acceder a Dokploy tras cambiar de IP publica:

1. Averigua tu IP publica actual

curl https://api.ipify.org

2. Conecta por SSH y ejecuta el script

Hay que hacerlo en ambos servidores:

# PROD
ssh root@crearack.com

# STAGE (en otra terminal o despues)
ssh root@178.104.131.173

Pega este script en cada servidor cambiando TU_IP por la IP del paso 1:

#!/bin/bash
# === restore-dokploy-access.sh ===
# Restaura acceso al panel Dokploy (puerto 3000) y Django staging (puerto 8000).
# Mantiene las IPs de GitHub webhooks para auto-deploy.
#
# Uso: bash restore-dokploy-access.sh 91.126.184.163

MY_IP="${1:?Uso: bash restore-dokploy-access.sh TU_IP_PUBLICA}"

echo "[1/5] Limpiando reglas antiguas de puerto 3000..."
while iptables -L DOCKER-USER -n --line-numbers | grep "tcp dpt:3000" | tail -1 | grep -q "dpt:3000"; do
  LINE=$(iptables -L DOCKER-USER -n --line-numbers | grep "tcp dpt:3000" | tail -1 | awk '{print $1}')
  iptables -D DOCKER-USER "$LINE"
done

echo "[2/5] Limpiando reglas antiguas de puerto 8000..."
while iptables -L DOCKER-USER -n --line-numbers | grep "tcp dpt:8000" | tail -1 | grep -q "dpt:8000"; do
  LINE=$(iptables -L DOCKER-USER -n --line-numbers | grep "tcp dpt:8000" | tail -1 | awk '{print $1}')
  iptables -D DOCKER-USER "$LINE"
done

echo "[3/5] Añadiendo reglas puerto 8000 (Django)..."
iptables -A DOCKER-USER -p tcp --dport 8000 -s 127.0.0.0/8 -j ACCEPT
iptables -A DOCKER-USER -p tcp --dport 8000 -s 172.16.0.0/12 -j ACCEPT
iptables -A DOCKER-USER -p tcp --dport 8000 -s "$MY_IP" -j ACCEPT
iptables -A DOCKER-USER -p tcp --dport 8000 -j DROP

echo "[4/5] Añadiendo reglas puerto 3000 (Dokploy)..."
iptables -A DOCKER-USER -p tcp --dport 3000 -s "$MY_IP" -j ACCEPT
# GitHub webhook IPs (necesarias para auto-deploy)
iptables -A DOCKER-USER -p tcp --dport 3000 -s 192.30.252.0/22 -j ACCEPT
iptables -A DOCKER-USER -p tcp --dport 3000 -s 185.199.108.0/22 -j ACCEPT
iptables -A DOCKER-USER -p tcp --dport 3000 -s 140.82.112.0/20 -j ACCEPT
iptables -A DOCKER-USER -p tcp --dport 3000 -s 143.55.64.0/20 -j ACCEPT
iptables -A DOCKER-USER -p tcp --dport 3000 -j DROP

echo "[5/5] Verificando..."
iptables -L DOCKER-USER -n | grep -E "dpt:(3000|8000)"
echo ""
echo "Hecho. Prueba Dokploy en el navegador."
echo "NOTA: Estas reglas se pierden en un reboot. Para persistir:"
echo "  iptables-save > /etc/iptables/rules.v4"

3. Hacer las reglas permanentes (opcional)

iptables-save > /etc/iptables/rules.v4

Reglas de referencia (ambos servidores)

Recuerda: al cambiar de IP hay que actualizar dos sitios: el firewall de Hetzner (panel web, para SSH) y las iptables del servidor (este script, para Dokploy y Django).

Última actualización: 16-04-2026 Mantenido por: Equipo CreaRack

Véase también

• [[crearack-tech—guides—deploy-checklist]] — checklist de deploy Golden Path
• [[crearack-tech—admin—hetzner-ssh-setup]] — acceso SSH a Hetzner
• [[crearack-tech—admin—dokploy-guide]] — guía de Dokploy
• [[crearack-tech—admin—dokploy-internals]] — internals de Dokploy
• [[crearack-tech—guides—disaster-recovery]] — procedimiento de disaster recovery
• [[crearack-tech—guides—docker-guide]] — guía de Docker Compose
• [[crearack-tech—guides—asgi-server-configuration]] — configuración de Daphne ASGI
• [[decision—20251201—dokploy-vs-kubernetes]] — ADR Dokploy vs Kubernetes