Todo el tráfico público de El Rack y Predify pasa hoy por nginx con TLS gestionado a mano, apuntando a los contenedores correspondientes en el VPS — funciona, pero cada servicio nuevo que quiero exponer es tocar configuración de nginx, certificados, y en algún caso abrir puertos que preferiría no tener abiertos innecesariamente. Pangolin apareció como la alternativa self-hosted más comentada para resolver justo eso: exponer servicios sin abrir puertos directamente, con gestión de acceso integrada.
Cómo funciona por dentro
Pangolin no reinventa la rueda — usa Traefik como proxy real por debajo, y WireGuard (a través de Newt, un cliente en espacio de usuario que no necesita permisos de superusuario) para el túnel. Es la misma filosofía que ya me convenció con NetBird: coger piezas ya probadas (Traefik, WireGuard) y ponerles una capa de gestión encima, en vez de construir un proxy desde cero.
Pangolin no sustituye a nginx porque sea mejor proxy — lo sustituye porque nunca más tengo que abrir un puerto en el router para exponer algo nuevo.
El día a día
Añadir un servicio nuevo es definirlo en el panel, y Pangolin se encarga de la ruta, el certificado y el túnel hasta el recurso interno, sin tocar ningún fichero de configuración de nginx a mano. Para quien ya gestiona varios servicios en el mismo VPS —mi caso exacto, con El Rack y Predify compartiendo infraestructura—, tener un panel central donde ver y gestionar todas las exposiciones públicas es mucho más cómodo que ir archivo por archivo.
Cosas a pulir
Migrar de una configuración de nginx ya funcionando y estable, como la que tengo hoy, no es trivial — implica repensar cómo entra el tráfico a cada servicio, y durante la transición hay riesgo de downtime si no se planea bien. Y aunque Pangolin resuelve el problema de exposición pública, sigue sin sustituir la necesidad de un proxy interno bien configurado para el tráfico que no sale a internet.
