Remnawave: panel de gestión VLESS/Reality para múltiples servidores

Qué configuramos y por qué

Remnawave es un panel de control self-hosted para infraestructura de proxy basado en Xray. Resuelve el problema que aparece inmediatamente tras pasar de un único servidor configurado manualmente a varios: los usuarios, las claves, los límites, las suscripciones, la configuración de los nodos y las estadísticas dejan de caber en un único archivo de configuración.

En lugar de editar manualmente las configuraciones JSON de Xray, el administrador obtiene un panel web y una API. En él se crean usuarios, se emiten subscription URL, se asignan límites de tráfico y períodos de validez, y los servidores de ejecución se conectan como nodos. El panel almacena el estado en PostgreSQL, mientras que los nodos aplican la configuración recibida y atienden las conexiones de los clientes.

Este artículo utiliza una arquitectura típica de tres roles:

• Control plane: VPS con Remnawave, PostgreSQL, Redis y Caddy. Contiene el panel, la API, las cuentas y los metadatos.
• Nodos edge: VPS en una o varias ubicaciones donde se ejecutan el agente del nodo y Xray Core.
• Clientes: aplicaciones compatibles con VLESS y suscripciones, que reciben la configuración actual mediante la URL de suscripción.

VLESS es un protocolo moderno de credenciales dentro del ecosistema Xray. Reality se utiliza junto con VLESS para organizar un transporte protegido sin necesidad de emitir un certificado TLS en cada puerto público de entrada del nodo. Sin embargo, el panel administrativo no debe estar disponible mediante HTTP: HTTPS es necesario para proteger contraseñas, tokens y enlaces de suscripción.

Qué funcionará después de la configuración

Después de completar todos los pasos, tendrá un dominio para el panel, por ejemplo panel.example.com, protegido por un certificado TLS. En el panel creará un administrador, añadirá uno o varios nodos, creará un usuario de prueba y obtendrá una suscripción. Añadir el siguiente servidor no requerirá copiar la base de datos ni sincronizar manualmente los usuarios: bastará con instalar el agente del nodo y vincularlo mediante un token.

Este enfoque es conveniente para un equipo de desarrollo, una infraestructura personal con varias regiones, una comunidad pequeña o un entorno de pruebas. También simplifica la sustitución de un nodo: si el servidor no está disponible o debe retirarse, los usuarios pueden reasignarse a nodos nuevos desde el panel.

Paneles self-hosted y en la nube

La opción self-hosted está justificada cuando son importantes el control, la independencia de un panel externo, las propias reglas de almacenamiento de datos y la posibilidad de utilizar nodos con distintos proveedores. La contrapartida es la necesidad de supervisar las actualizaciones y contar con un plan de recuperación funcional.

Utilice la infraestructura únicamente de acuerdo con la legislación del país donde se alojan los servidores, las condiciones del proveedor y las reglas de las redes por las que circula el tráfico. No publique el panel administrativo sin HTTPS ni deje la API accesible sin autenticación.

Qué configuración de VPS se necesita para esta tarea

La carga del panel Remnawave y la carga de los nodos de salida son diferentes. El panel almacena usuarios, estadísticas, configuraciones y el estado de la API; normalmente requiere más un disco estable y RAM disponible para PostgreSQL. Para los nodos son más importantes el ancho de banda de red, la calidad del enrutamiento, la CPU para el cifrado y un límite de tráfico suficiente.

Recursos mínimos para el panel

Para el servidor de gestión, una opción inicial práctica es 2 vCPU, 4 GB RAM, 40 GB NVMe y red de 1 Gbit/s. Este margen permite ejecutar simultáneamente Docker, PostgreSQL, Redis, Caddy y el panel sin encontrarse con OOM durante actualizaciones o migraciones de la base de datos. Como una de las opciones neutrales, puede elegir un VPS con las características indicadas, pero es más importante comprobar el límite de tráfico, la disponibilidad de IPv4 y la posibilidad de abrir los puertos TCP 80 y 443.

Recursos para un nodo VLESS/Reality

Para un nodo con decenas de usuarios activos, normalmente bastan 1–2 vCPU y 1–2 GB RAM si el servidor no ejecuta otros servicios pesados. Con una velocidad agregada alta, un gran número de conexiones simultáneas o un uso intensivo de tráfico de vídeo, elija 2–4 vCPU, 2–4 GB RAM y un puerto de 1 Gbit/s. Xray normalmente no requiere mucho disco: 20 GB son suficientes si los registros rotan y no hay un archivo local de estadísticas en el servidor.

No evalúe el servidor solo por el número de usuarios registrados. Son más críticos el número de clientes simultáneos, la velocidad media y el volumen mensual de tráfico. Por ejemplo, 30 usuarios que se conectan ocasionalmente pueden consumir menos recursos que cinco usuarios permanentes con descargas intensivas.

Cuándo se necesita un dedicated en lugar de un VPS

Un servidor dedicated tiene sentido cuando el nodo está constantemente cargado cerca del ancho de banda del puerto, se requiere un rendimiento de CPU predecible, se necesitan 5–10 Gbit/s, un límite de tráfico mayor o un perfil de red garantizado. También es adecuado para un nodo grande con varios cientos de clientes simultáneos.

Para el panel, normalmente no se necesita un dedicated: la base de datos y la API consumen considerablemente menos recursos que la transmisión del tráfico de usuarios. Un esquema racional consiste en un panel pequeño y fiable en un VPS independiente y nodos más potentes donde las estadísticas lo justifiquen.

Cómo elegir una ubicación

La ubicación del panel afecta a la latencia al gestionar los nodos, pero casi no afecta a la velocidad del usuario: el tráfico útil pasa por los nodos edge. Elija para el panel una región con acceso estable a sus nodos y soporte predecible para el dominio.

Las ubicaciones de los nodos se eligen según la latencia hacia los usuarios, la calidad de las rutas, el límite de tráfico, la política de uso permitido y la disponibilidad de IPv4. No aloje todos los nodos con un solo operador y en un mismo país si la tolerancia a fallos es importante para usted. Un esquema geográfico mínimamente razonable consiste en un panel en una región y dos nodos en centros de datos diferentes.

Preparación del servidor

A continuación se asume un VPS limpio con Ubuntu Server 24.04 LTS x86_64. Para 2026, esta es una base LTS conveniente para infraestructura Docker: recibe actualizaciones de seguridad, incluye un kernel actual y cuenta con buen soporte de la mayoría de las imágenes. Si utiliza Debian 12 o 13, la lógica de los pasos es la misma, pero los nombres de los paquetes pueden diferir ligeramente.

Primero inicie sesión en el servidor como usuario root con la contraseña proporcionada por el proveedor. Cree inmediatamente un administrador independiente: trabajar permanentemente como root aumenta las consecuencias de un error en un comando o de la vulneración de una clave SSH.

Creación de usuario y acceso SSH mediante clave

adduser deploy
usermod -aG sudo deploy
mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
nano /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

Inserte en authorized_keys el contenido de su clave pública SSH, por ejemplo, una línea que comience con ssh-ed25519. Compruebe el acceso en una segunda ventana de terminal sin cerrar la sesión actual de root:

ssh deploy@SERVER_IP

Desactive la autenticación por contraseña de root solo después de iniciar sesión correctamente. Abra la configuración de SSH:

sudo nano /etc/ssh/sshd_config.d/99-hardening.conf

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3

Compruebe la sintaxis y reinicie SSH. Si el comando de comprobación devuelve un error, no reinicie el servicio hasta corregir el archivo.

sudo sshd -t && sudo systemctl restart ssh

Actualización del sistema y herramientas básicas

Realice la actualización antes de instalar Docker. Tras actualizar el kernel, reinicie el VPS si el sistema lo indica.

sudo apt update && sudo apt full-upgrade -y
sudo apt install -y ca-certificates curl gnupg git jq nano unzip \
  ufw fail2ban chrony logrotate
sudo reboot

Después del reinicio, vuelva a conectarse como usuario deploy. Compruebe la sincronización de hora: una hora correcta es necesaria para los certificados TLS, los tokens y los registros.

timedatectl status
chronyc tracking

Firewall y Fail2ban

En el servidor del panel debe abrir SSH, HTTP y HTTPS. No publique PostgreSQL, Redis ni los puertos internos de Docker. Si cambia el puerto SSH, primero abra el nuevo puerto y asegúrese de poder conectarse.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP for ACME'
sudo ufw allow 443/tcp comment 'HTTPS panel'
sudo ufw enable
sudo ufw status verbose

Fail2ban en Ubuntu ya incluye un filtro SSH básico. Cree una configuración local con un tiempo de bloqueo razonable:

sudo tee /etc/fail2ban/jail.d/sshd.local >/dev/null <<'EOF'
[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h
EOF

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Si el panel aceptará conexiones de nodos mediante un puerto API independiente, no lo abra a todo Internet. Utilice una dirección HTTPS protegida del panel y un token de nodo, o añada reglas UFW específicas con las direcciones IP de los nodos. El mecanismo concreto depende de la versión de Remnawave y del modo de conexión seleccionado.

Instalación del software — paso a paso

Para 2026, una forma práctica de ejecutar Remnawave es Docker Engine y Docker Compose Plugin. La contenerización aísla PostgreSQL, Redis, el panel y el proxy inverso, mientras que la actualización se reduce a descargar nuevas imágenes y reiniciar el stack de Compose.

A continuación se utilizan Docker Engine 28.x y Docker Compose v2.x. Las versiones menores exactas cambian regularmente, por lo que tras la instalación compruebe obligatoriamente las versiones reales con los comandos docker version y docker compose version. Para production, no fije servicios críticos en imágenes latest sin soporte y sin un proceso de pruebas.

Instalación de Docker Engine

Añada el repositorio oficial de Docker para Ubuntu 24.04 e instale el motor, CLI, Buildx y Compose Plugin.

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin

Permita al usuario deploy gestionar Docker sin sudo y vuelva a conectarse a la sesión SSH. Este cambio concede de facto al usuario permisos administrativos en el servidor, por lo que no añada usuarios normales al grupo docker.

sudo usermod -aG docker deploy
exit

ssh deploy@SERVER_IP
docker version
docker compose version
docker run --rm hello-world

Creación del directorio del proyecto

Guarde todos los archivos del panel en un único directorio con permisos predecibles. El ejemplo utiliza /opt/remnawave. El propietario será el usuario deploy, y solo él tendrá acceso al archivo de secretos.

sudo mkdir -p /opt/remnawave/{data,backups,caddy}
sudo chown -R deploy:deploy /opt/remnawave
cd /opt/remnawave
umask 077

Obtención de la configuración oficial del proyecto

Remnawave se desarrolla activamente, por lo que los nombres de las variables y la composición de los contenedores pueden cambiar entre versiones. Antes del despliegue, utilice el repositorio oficial del proyecto y su archivo .env.example como fuente de referencia. No copie archivos Compose de mensajes aleatorios de Telegram ni de vídeos antiguos.

cd /opt
sudo git clone https://github.com/remnawave/backend.git remnawave-source
sudo chown -R deploy:deploy /opt/remnawave-source
cd /opt/remnawave-source
git tag --sort=-version:refname | head -n 10

Elija la etiqueta de la última versión estable, no una rama de desarrollo aleatoria. En el ejemplo siguiente, la variable se establece manualmente: sustituya el valor por una etiqueta mostrada por el comando anterior. Este enfoque permite actualizar y revertir de forma reproducible.

export REMNAWAVE_VERSION="v0.0.0"
git checkout "$REMNAWAVE_VERSION"
find . -maxdepth 3 -type f \( -name 'compose.yml' -o -name '.env.example' \) -print

cd /opt/remnawave-source
cp .env.example /opt/remnawave/.env
find . -maxdepth 3 -iname 'compose.yml' -print

cp docker-compose.yml /opt/remnawave/compose.yml
cd /opt/remnawave
chmod 600 .env
nano .env

docker compose --env-file .env -f compose.yml config > /tmp/remnawave-resolved.yml
less /tmp/remnawave-resolved.yml

Copias de seguridad y mantenimiento

La copia de seguridad del panel no consiste en copiar un solo contenedor Docker. Los datos críticos se encuentran en PostgreSQL, y la posibilidad de descifrar o conectar el sistema después de la restauración depende del archivo .env, las claves de la aplicación y la configuración de Compose. Una copia de seguridad sin secretos puede resultar inútil.

Qué se debe guardar

• Volcado lógico de PostgreSQL: usuarios, nodos, configuraciones, estadísticas y suscripciones.
• Archivo /opt/remnawave/.env con contraseñas y claves de la aplicación.
• compose.yml, Caddyfile y archivos de configuración adicionales.
• Datos de Caddy de /opt/remnawave/data/caddy: los certificados se pueden volver a emitir, pero su copia de seguridad acelera la restauración.
• Documento con registros DNS, lista de nodos, puertos abiertos y versión de Remnawave.

No confíe en un snapshot de VPS como única copia de seguridad. Un snapshot es útil antes de una actualización importante, pero se almacena con el mismo proveedor y no sustituye una copia periódica en otra ubicación.

Volcado local de PostgreSQL

Primero encuentre el nombre exacto del servicio PostgreSQL en Compose. En el ejemplo se llama postgres. El comando crea un volcado comprimido en el directorio backup.

cd /opt/remnawave
docker compose ps
mkdir -p backups
docker compose exec -T postgres pg_dump \
  -U "$POSTGRES_USER" \
  -d "$POSTGRES_DB" \
  --format=custom \
  | gzip > "backups/remnawave-$(date +%F-%H%M).dump.gz"

Compruebe que el archivo no esté vacío. Para la primera comprobación, es útil realizar una restauración en un servidor de prueba independiente, en lugar de limitarse a verificar que se creó el archivo.

ls -lh backups/
gzip -t backups/remnawave-.dump.gz

Copia de seguridad automática con restic

Restic admite cifrado del lado del cliente y almacenamientos compatibles con S3. Esto es conveniente porque el almacenamiento externo recibe datos ya cifrados. Cree un bucket independiente y claves de acceso independientes solo para las copias de seguridad; no utilice claves de la cuenta principal de la nube con permisos completos.

Instale restic:

sudo apt install -y restic
sudo install -d -m 700 /root/.config/restic
sudo nano /root/.config/restic/remnawave.env
sudo chmod 600 /root/.config/restic/remnawave.env

No guarde el archivo de entorno en Git y rellénelo con los valores reales de su almacenamiento compatible con S3:

export RESTIC_REPOSITORY="s3:https://s3.example.net/remnawave-backups"
export RESTIC_PASSWORD="REPLACE_WITH_LONG_UNIQUE_BACKUP_PASSWORD"
export AWS_ACCESS_KEY_ID="REPLACE_WITH_BACKUP_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="REPLACE_WITH_BACKUP_SECRET_KEY"

Inicialice el repositorio una sola vez. La contraseña RESTIC_PASSWORD debe almacenarse separadamente del VPS: si se pierde, no será posible descifrar los archivos.

sudo bash -c 'source /root/.config/restic/remnawave.env && restic init'

Cree un script que genere un volcado de la base de datos, archive la configuración, envíe los datos a restic y aplique la política de retención.

sudo nano /usr/local/sbin/backup-remnawave.sh
sudo chmod 700 /usr/local/sbin/backup-remnawave.sh

#!/usr/bin/env bash
set -euo pipefail

APP_DIR="/opt/remnawave"
BACKUP_DIR="${APP_DIR}/backups"
STAMP="$(date +%F-%H%M%S)"

source /root/.config/restic/remnawave.env

mkdir -p "${BACKUP_DIR}"

cd "${APP_DIR}"

docker compose exec -T postgres pg_dump \
  -U "${POSTGRES_USER}" \
  -d "${POSTGRES_DB}" \
  --format=custom | gzip > "${BACKUP_DIR}/postgres-${STAMP}.dump.gz"

tar -C "${APP_DIR}" -czf "${BACKUP_DIR}/config-${STAMP}.tar.gz" \
  .env compose.yml Caddyfile data/caddy 2>/dev/null || true

restic backup "${BACKUP_DIR}" --tag remnawave --tag postgres
restic forget --prune \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6

find "${BACKUP_DIR}" -type f -mtime +3 -delete

Ejecute el script diariamente durante un periodo de baja carga. Cron es conveniente para una infraestructura pequeña:

sudo crontab -e

17 3   * /usr/local/sbin/backup-remnawave.sh >> /var/log/backup-remnawave.log 2>&1

Compruebe la ejecución manualmente y el contenido del repositorio:

sudo /usr/local/sbin/backup-remnawave.sh
sudo bash -c 'source /root/.config/restic/remnawave.env && restic snapshots'
sudo tail -n 100 /var/log/backup-remnawave.log

Actualizaciones sin pérdida de datos

Para un solo panel, es mejor utilizar una ventana de mantenimiento. La actualización del backend puede incluir una migración de la base de datos, por lo que primero cree una copia de seguridad verificada, lea las release notes y registre la versión actual. No actualice el backend y todos los nodos al mismo tiempo si no ha comprobado la compatibilidad entre versiones.

cd /opt/remnawave
sudo /usr/local/sbin/backup-remnawave.sh
docker compose ps
docker compose pull
docker compose up -d
docker compose logs --tail=100
docker compose ps

Para varios nodos, utilice un enfoque rolling: actualice el panel, luego un nodo con poca carga, compruebe la creación de un usuario de prueba y la conexión, y después actualice los demás nodos uno por uno. Antes de actualizar un nodo, exclúyalo temporalmente de la emisión de nuevas configuraciones o espere a que disminuya el número de sesiones activas.

Una vez al mes, compruebe el espacio en disco, el estado de Docker, el tamaño de PostgreSQL y la fecha de caducidad del certificado TLS:

df -h
docker system df
docker compose exec -T postgres psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" \
  -c "SELECT pg_size_pretty(pg_database_size(current_database()));"
sudo fail2ban-client status sshd
docker compose logs caddy --tail=50

Solución de problemas + FAQ

¿Por qué Caddy no obtiene un certificado y aparece un error ACME en los registros?

Primero compruebe el DNS: el registro A del dominio del panel debe apuntar al IPv4 público actual del VPS. Después asegúrese de que los puertos 80 y 443 estén abiertos tanto en UFW como en el firewall externo del proveedor. El error suele producirse debido a un registro AAAA antiguo: la comprobación ACME intenta utilizar IPv6, que no está configurado en el servidor. Compruebe dig A y dig AAAA, y luego revise docker compose logs caddy.

El panel se abre por IP, pero no funciona por dominio. ¿Qué comprobar?

Compruebe si APP_URL coincide con el dominio HTTPS real y reinicie Compose después de modificar .env. En Caddyfile el dominio debe indicarse sin el esquema https:// y sin una ruta adicional. Asegúrese de que el reverse proxy apunte al nombre correcto del servicio backend y a su puerto interno. El comando docker compose config ayudará a ver la configuración final y detectar variables de entorno no resueltas.

El contenedor backend se reinicia constantemente. ¿Cómo encontrar la causa?

Comience con docker compose logs --tail=200 backend. Las causas más frecuentes son una contraseña de PostgreSQL incorrecta, un inicio de la base de datos no completado, una variable de entorno obligatoria omitida o una migración incompatible con el esquema antiguo de la base de datos. Compruebe el estado de la base mediante docker compose ps y los registros del servicio PostgreSQL. No elimine volumes al intentar «arreglar» el inicio: esto eliminará usuarios y configuraciones. Primero guarde un volcado de la base de datos y compare .env con el ejemplo oficial de su versión.

El nodo está creado, pero sigue apareciendo offline en el panel. ¿Qué hacer?

Compruebe la URL del panel en la variable del nodo: debe comenzar con https:// y utilizar un dominio con un certificado válido. Asegúrese de que el registration token se haya copiado sin espacios y corresponda exactamente a este nodo. Revise los registros del contenedor del nodo y compruebe el acceso saliente desde el nodo al TCP 443 del panel con el comando curl -I https://panel.example.com. Si hay reglas estrictas de firewall entre los servidores, permita conexiones HTTPS salientes desde el nodo y conexiones entrantes al 443 en el panel.

El usuario importó la suscripción, pero la conexión no se establece. ¿Qué comprobar?

Compruebe si el usuario tiene asignados un inbound activo y un nodo online. Luego asegúrese de que el puerto inbound esté abierto en UFW en el nodo y no esté ocupado por otro servicio: utilice ss -lntup. Revise los registros del nodo durante el intento de conexión; mostrarán si el tráfico llegó a Xray. Compruebe también la fecha de caducidad del usuario, el límite de tráfico y la corrección de la hora del sistema. No cambie manualmente el UUID, las claves Reality ni los parámetros inbound en el contenedor del nodo: el panel debe seguir siendo la fuente de configuración.

¿Qué configuración mínima de VPS es adecuada?

Para un panel de prueba con uno o dos nodos, será suficiente un VPS con 1 vCPU, 2 GB de RAM, 25 GB SSD o NVMe y una red de 100 Mbit/s o más. Para uso real, es mejor elegir de inmediato 2 vCPU, 4 GB de RAM y 40 GB NVMe, porque PostgreSQL, Docker y las actualizaciones consumen memoria adicional. Para cada nodo pequeño bastan 1 vCPU, 1–2 GB de RAM y 20 GB de disco, pero seleccione el ancho de banda y el límite mensual de tráfico según el uso real.

¿Qué elegir: VPS o dedicated para esta tarea?

Para el panel de administración, casi siempre basta con un VPS: no transmite el tráfico principal de los usuarios y normalmente está limitado al funcionamiento de la base de datos, la API y las estadísticas. Un VPS también es adecuado para nodos pequeños o medianos con decenas de clientes activos. Elija dedicated para un nodo edge grande con carga alta constante, requisito de 1–10 Gbit/s, gran volumen de tráfico o rendimiento de CPU predecible. Una estrategia práctica es colocar el panel en un VPS y añadir dedicated solo después de confirmar la carga mediante métricas.

¿Se puede mantener el panel y el primer nodo en un mismo servidor?

Para un entorno de laboratorio o uso personal, esto es aceptable y reduce el coste. Sin embargo, ese servidor se convierte en un único punto de fallo: si hay problemas de red, carga o actualización, el panel y las conexiones de los usuarios dejarán de funcionar al mismo tiempo. Además, una velocidad alta en el nodo puede ralentizar PostgreSQL y la interfaz web. Para producción, es mejor separar el control plane del nodo edge en al menos dos VPS. Esto también simplifica la migración y el diagnóstico.

¿Cómo restaurar el panel después de perder el VPS?

Cree un nuevo VPS, instale Docker y despliegue la misma versión compatible de Remnawave. Restaure .env, los archivos Compose y luego PostgreSQL desde el volcado. Es importante utilizar los mismos secretos de la aplicación; de lo contrario, algunos datos cifrados pueden quedar inaccesibles. Tras la restauración, cambie el DNS a la nueva IP, espere a que se emita el certificado TLS y compruebe la conexión de los nodos. Pruebe regularmente este procedimiento en una máquina independiente: una copia de seguridad se considera funcional solo después de una restauración satisfactoria.

Conclusiones y próximos pasos

Ahora dispone de una infraestructura básica self-hosted de Remnawave: un panel protegido con HTTPS, PostgreSQL, copias de seguridad y la posibilidad de conectar varios nodos VLESS/Reality. El principio principal de operación es separar el panel de administración de los servidores de salida y no almacenar secretos en texto plano.

1. Añada un segundo nodo en otro centro de datos y compruebe que los usuarios reciban una suscripción actualizada después de cambiar la asignación.
2. Configure una monitorización externa de la disponibilidad del panel, la fecha de caducidad del certificado TLS, el uso del disco y el estado de los nodos.
3. Realice una restauración de prueba de PostgreSQL y la configuración en un VPS independiente antes de la primera actualización importante.

A medida que aumente la carga, recopile métricas reales de conexiones simultáneas, tráfico, CPU y RAM. En función de ellas, escale específicamente los nodos, no el panel de administración sin necesidad.