Nginx Proxy Manager en un VPS: reseña y guía de configuración

NPM vs Caddy vs Traefik: qué proxy inverso encaja con tu VPS

Las tres herramientas se dividen a lo largo de cuatro ejes que determinan la elección: cómo se configuran, cómo gestionan HTTPS, cómo escalan con el número de servicios y cuánta RAM consumen en reposo. Aquí tienes la comparación.

Las cifras de RAM en reposo son observaciones aproximadas de una comparación de 2026, no requisitos fijos. El uso real varía según la versión de la imagen, las funciones habilitadas, el tráfico y el registro.

Los criterios para cambiar se derivan directamente de esa tabla. Si quieres un panel y ejecutas un puñado de servicios que no cambian a menudo, NPM es la herramienta adecuada. Si prefieres la configuración como código, quieres la menor huella posible o valoras el aprovisionamiento y renovación automáticos de HTTPS de Caddy sin configuración de ACME, usa Caddy. Yo mismo recurro a Caddy en despliegues de un solo sitio porque la gestión de SSL es automática y el Caddyfile es corto. Si añades, eliminas o redespliegas contenedores con frecuencia, el autodescubrimiento basado en etiquetas de Traefik hace que dejes de registrar a mano cada nuevo host.

También está Nginx puro con Certbot, que algunos administradores prefieren para un control preciso o despliegues sin Docker. Certbot puede automatizar la renovación de certificados, pero sigues gestionando tú mismo el enrutamiento de hosts virtuales y la configuración de Nginx. Si tu principal motivo para considerar NPM es evitar la configuración manual del proxy, es poco probable que Nginx puro sea la mejor opción.

Una nota sobre la elección: la comparativa de byte-guard sitúa a Caddy como la opción más ligera de esa comparación, y para un montaje nuevo de un solo host en 2026 esa es una elección razonable. Caddy gana por ser más ligero que NPM, pero si quieres específicamente una GUI, no es tu mejor apuesta.

Para una comparación más profunda de los motores subyacentes, consulta la comparación de Caddy vs Nginx en un VPS.

Requisitos previos: lo que necesitarás

Antes de desplegar, ten esto preparado. Es una lista corta, pero si te saltas cualquier elemento, el paso del certificado fallará más adelante.

• Un VPS con Docker y Docker Compose instalados (Ubuntu 22.04 LTS o Debian 12 sirven).
• Un nombre de dominio, con un registro DNS A (y AAAA si usas IPv6) apuntando a la IP pública de tu VPS.
• Acceso SSH al VPS.
• Los puertos 80 y 443 abiertos a Internet en tu firewall.
• El puerto 81 accesible solo por ti, no abierto al público (se trata en la sección de seguridad).

Configuración de Nginx Proxy Manager en tu VPS con Docker Compose

Esta sección despliega NPM usando Docker Compose. Una vez que tus registros DNS resuelven al VPS, la configuración del contenedor en sí es rápida, aunque la propagación de DNS y la emisión de certificados pueden tardar más.

La configuración usa un archivo de Docker Compose y un comando único para crear una red Docker compartida. Crea un directorio, crea la red, añade el docker-compose.yml archivo de abajo y levanta el contenedor.

Primero, crea la red Docker compartida:

docker network create proxy

Luego crea el siguiente docker-compose.yml archivo:

# docker-compose.yml
services:
  npm:
    image: 'jc21/nginx-proxy-manager:<PATCHED_VERSION>'
    restart: unless-stopped
    ports:
      - '80:80'                 # public HTTP
      - '443:443'               # public HTTPS
      - '127.0.0.1:81:81'       # admin UI, reachable only from the VPS itself
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    networks:
      - proxy
networks:
  proxy:
    external: true

Conecta cada contenedor de backend que NPM deba alcanzar por nombre de servicio a la misma red externa proxy . Esto permite que NPM resuelva el contenedor por su nombre de servicio sin publicar el puerto de la aplicación de backend en el VPS.

Haz una copia de seguridad de ambos ./data y ./letsencrypt antes de las actualizaciones. El directorio de datos contiene la base de datos de NPM y la configuración generada, mientras que el directorio de Let's Encrypt contiene su material de certificados.

Algunas cosas sobre este archivo. La imagen usa por defecto una base de datos SQLite almacenada en el ./data volumen. Ese es el backend predeterminado y es correcto para la mayoría de los despliegues en un solo VPS. Si necesitas una base de datos externa, NPM admite MariaDB/MySQL y PostgreSQL, lo que implica añadir un servicio de base de datos y las variables de entorno correspondientes. Para un solo VPS, SQLite sigue siendo la opción predeterminada más sencilla a menos que tengas una razón clara para sacar la base de datos del volumen de datos. La restart: unless-stopped política significa que NPM vuelve a levantarse si el VPS se reinicia, que es lo que quieres para un servicio que se sitúa delante de todo lo demás.

Levántalo y confirma que está en ejecución:

docker compose up -d
docker compose ps

Salida esperada: el npm contenedor con estado Up, los puertos 80 y 443 mapeados públicamente, y el puerto 81 vinculado solo a 127.0.0.1. El primer arranque tarda un par de minutos mientras NPM genera una clave JWT, inicializa la base de datos y crea el usuario administrador predeterminado. Los documentos de configuración oficiales describen esta secuencia de primer arranque.

Crea un túnel SSH desde tu ordenador local antes de abrir la interfaz de administración:

ssh -L 8181:127.0.0.1:81 user@your-vps

Luego abre http://127.0.0.1:8181 en tu navegador. En una instalación nueva, inicia sesión con [email protected] y changeme, luego reemplaza de inmediato el correo electrónico y la contraseña predeterminados. No hagas que el panel sea accesible públicamente mientras las credenciales predeterminadas estén activas.

Una vez que hayas cambiado las credenciales de administrador, añade tu primer host proxy:

1. En el panel, ve a Hosts, luego Proxy Hosts, luego Add Proxy Host.
2. Configura el Domain Name a tu subdominio (por ejemplo cloud.example.com).
3. Establece Forward Hostname / IP al nombre o IP del contenedor de backend, y Forward Port al puerto en el que escucha.
4. Guarda. El host proxy aparece en la lista, y el tráfico a ese subdominio ahora llega a tu contenedor.

Si ejecutas una interfaz de gestión de Docker junto a esto, se aplica el mismo patrón: apunta un subdominio hacia la herramienta de gestión de contenedores de la misma forma, y haz lo mismo para un stack de monitorización con Prometheus y Grafana que quieras situar detrás del proxy.

Configuración de HTTPS automático para un subdominio

Esta sección te consigue un certificado de Let's Encrypt válido y de renovación automática para tu subdominio. El requisito previo es el que suele pillar a la gente: el registro DNS A de ese subdominio ya tiene que apuntar a tu VPS, y el puerto 80 tiene que ser accesible desde Internet, porque Let's Encrypt verifica el dominio conectándose de vuelta a él.

Con el host proxy creado, solicita el certificado:

1. Edita el host proxy, abre la SSL .
2. En Certificado SSL, elige Request a new SSL Certificate.
3. Activar Force SSL y HTTP/2 Support. Activa HSTS solo después de confirmar que HTTPS funciona correctamente, porque los navegadores pueden almacenar en caché la política y dificultar la recuperación de un error de certificado o de configuración del proxy.
4. Acepta los términos de Let's Encrypt y guarda.

Por defecto, NPM usa el desafío HTTP-01 para nombres sin comodín, validando cada nombre de host solicitado a través del puerto 80. Un certificado puede contener varios nombres sin comodín, pero HTTP-01 no puede emitir certificados comodín. Los nombres comodín como *.example.com requieren el desafío DNS-01 con un proveedor de DNS compatible. Para un montaje normal de un subdominio por servicio, HTTP-01 es todo lo que necesitas, y las renovaciones son automáticas.

Dimensionamiento de tu VPS para Nginx Proxy Manager

NPM en sí es ligero; la cuestión del dimensionamiento tiene que ver en realidad con NPM más los servicios que hay detrás. La huella en reposo del proxy rara vez es la restricción. Una instancia de Nextcloud o un blog de Ghost usarán más recursos que el propio proxy.

Así funcionan los niveles en la práctica:

• Base práctica mínima: 1 GB RAM, 1 vCPU y 10 GB de almacenamiento. Uno guía de dimensionamiento de terceros usa la misma base, pero tómala como orientación de planificación en lugar de como un requisito oficial de NPM. Es suficiente para NPM, el sistema operativo y unos pocos servicios ligeros, pero deja un margen limitado.
• Cómodo: 2 GB RAM, 1 vCPU, 20 GB de almacenamiento. NPM más tres a cinco servicios con espacio para respirar. Este es el punto óptimo para la mayoría de quienes se autoalojan.
• Un nivel más: 4 GB RAM, 2 vCPU. Para ocho a doce servicios, o un montaje con tráfico significativo donde quieres margen de CPU para la terminación de TLS.

La cifra sobre la que dimensionas es la suma de las aplicaciones tras el proxy, no NPM. Suma las huellas de RAM de los servicios que piensas ejecutar, añade encima la pequeña sobrecarga en reposo del proxy y elige con margen el nivel superior a eso.

Dimensionar el servidor es la parte fácil. Poner NPM en marcha sigue implicando aprovisionar el VPS, instalar Docker, descargar la imagen y recorrer esa configuración de primer arranque. Si prefieres saltarte los pasos de aprovisionamiento, el marketplace de Cloudzy tiene un despliegue de un clic de Nginx Proxy Manager en un VPS con NVMe. Levanta el contenedor en un servidor nuevo, así que vas directo al panel y a tu primer host proxy. En cualquier caso, los niveles de dimensionamiento de arriba son sobre los que aprovisionas.

Preguntas frecuentes