Sobrevivir al cambio en SaaS: Por qué los túneles de código abierto AGPL ganan

Los desarrolladores que exponen entornos locales a internet enfrentan una amenaza persistente: los proveedores comerciales de túneles que descontinúan las capas gratuitas, restringen el ancho de banda y bloquean funciones tras muros de pago empresariales. La traducción de direcciones de red (NAT) y NAT de grado carrier (CGNAT), ahora estándar en la mayoría de los ISP de consumo y móviles, significan que la mayoría de los desarrolladores ya no poseen una dirección IPv4 enrutables públicamente, haciendo que los túneles de proxy inverso sean una capa obligatoria en la pila moderna de desarrollo. Crear un receptor de webhooks, una interfaz de agente AI o un servidor de juegos multijugador local casi siempre requiere confiar en un daemon de tunneling para atravesar el firewall local y exponer un endpoint público.

Durante años, la industria optó por plataformas SaaS propietarias para resolver este problema de enrutamiento. A medida que el ecosistema madura y las demandas de beneficios obligan a esas plataformas a endurecer sus términos, la comunidad de código abierto ha migrado hacia “seguro de pivote de proveedor” — herramientas licenciadas estrictamente bajo la GNU Affero General Public License (AGPL) que permiten a los desarrolladores auto-hospedar la misma infraestructura si el proveedor comercial cambia sus términos o desaparece.

Por qué los niveles gratuitos están disminuyendo

El cambio de los planes freemium generosos en tunneling está impulsado por cambios reales y medibles en los dos defaults más populares.

ngrok, durante mucho tiempo la herramienta predeterminada para exposición local, ahora ofrece un plan gratuito realmente limitado: un crédito de uso único de $5, hasta 3 endpoints en línea, 1GB de transferencia de datos y 20,000 solicitudes HTTP/S por mes. Una vez agotado ese crédito o alcanzados los límites, los endpoints dejan de aceptar nuevo tráfico hasta el próximo reinicio mensual. Más allá de lo gratuito, el nivel Hobbyist de ngrok cuesta $10/mes ($8/mes facturado anualmente) para 3 endpoints y 5GB de ancho de banda, y el modelo Pay-as-you-go comienza en $20/mes más $0.10/GB y $1 por cada 100,000 solicitudes en exceso, con endpoints ilimitados y opción de dominio propio.

Cloudflare Tunnel se presenta frecuentemente como la alternativa sin costo, y en cuanto a ingreso HTTPS, en gran medida lo es — pero hereda restricciones reales de los términos de CDN de Cloudflare que toman por sorpresa a las personas. Aquí hay dos aspectos, y ambos son más específicos de lo que a menudo se describe:

• La restricción de video/archivos grandes. Esto se cita comúnmente (y ahora de forma desactualizada) como “Sección 2.8” de los términos de Cloudflare — pero esa sección fue retirada en mayo de 2023, cuando Cloudflare movió la restricción basada en contenido fuera de su Acuerdo de Suscripción de Autoservicio general y la colocó en una sección específica de sus Términos de Servicio. La restricción solo aplica a la CDN de Cloudflare — es decir, a las rutas de hostname públicas de un Tunnel (que proxy a través del borde de Cloudflare), pero explícitamente no a las rutas de la red privada del Tunnel accedidas vía WARP. También es más estrecha que una prohibición general de streaming: los videos y otros archivos grandes están permitidos en la CDN hoy en día siempre que se sirvan desde un servicio alojado por Cloudflare como Stream, Images o R2 — la restricción está en servir archivos grandes alojados fuera de Cloudflare a través de la CDN. Un servidor Plex o Jellyfin auto-hospedado expuesto mediante un hostname público de Tunnel aún enfrenta esto; el mismo servidor accesible solo a través de WARP privado no.
• El límite de cuerpo de solicitud de 100MB. Los planes gratuito y Pro limitan el tamaño máximo del cuerpo de solicitud HTTP (POST) proxyado a través de la CDN en 100MB — por encima de eso, Cloudflare devuelve un error 413 “Request Entity Too Large” en lugar de descartar silenciosamente los datos. El plan Business aumenta el límite a 200MB y el Enterprise a 500MB. Esto es real y debe considerarse para cargas de archivos grandes o herramientas de sincronización, pero es un límite en el tamaño del cuerpo del tráfico proxyado por la CDN, no una peculiaridad de corte de chunks específica de Tunnel.

La mecánica del seguro de pivote de proveedor

El bloqueo de proveedor en el espacio de tunneling ocurre cuando un desarrollador construye pipelines de CI, pruebas de webhooks o automatización alrededor de una API propietaria o un relay de código cerrado. Si la empresa que aloja ese relay cambia sus precios o cierra, el desarrollador debe reescribir toda su arquitectura de red desde cero. El seguro de pivote de proveedor es la garantía arquitectónica de que un desarrollador puede montar infraestructura idéntica en su propio hardware, usando el mismo software.

Este seguro está codificado por la GNU Affero General Public License v3.0 (AGPLv3). A diferencia de licencias permisivas como MIT o Apache 2.0, la AGPL cierra la “laguna SaaS” en la GPL regular: cualquier entidad que modifique el software y lo ejecute como un servicio en red debe poner ese código fuente modificado a disposición de los usuarios que interactúan con él a través de la red — no solo a quienes reciben un binario compilado. Para un relay de proxy inverso, eso significa que el servidor principal no puede ser modificado en secreto y convertido en propietario por un operador comercial. Si un servicio de tunneling licenciado bajo AGPL se degrada o cambia sus precios, un desarrollador puede provisionar un VPS de bajo costo, desplegar el mismo código relay y seguir funcionando sin cambios en su configuración local.

Evaluando el panorama moderno de tunneling

Herramienta	Licencia del servidor	Lenguaje principal	Protocolos soportados	Caso de uso ideal	Perfil de costo
ngrok	Propietario	Go	HTTP, TCP, TLS	Pruebas legacy de webhooks	Gratis (3 endpoints/1GB/20K req) → $10–20+/mes
rustunnel	AGPL v3.0	Rust	HTTP, TCP, UDP, P2P	Auto-hospedaje de reverse-proxy AGPL	$0 auto-hospedado / $3/mes+ PAYG
frp	Apache 2.0	Go	HTTP, HTTPS, TCP, UDP	Homelabs auto-hospedados intensivos	Costo VPS (~$4/mes)
Cloudflare Tunnel	Propietario en la nube	Go (cloudflared)	HTTP, HTTPS vía CDN; TCP/UDP en WARP	Webhooks sin estado, HTTPS sin costo	Gratis (dominio requerido)
rathole	MIT	Rust	TCP, UDP (sin routing HTTP)	Port forwarding en VPS de bajo recurso	Costo VPS (~$4/mes)
bore	MIT	Rust	Solo TCP	Port forwarding minimalista	Relay público gratis o VPS ~$4/mes
Tailscale Funnel	Propietario en la nube	Go	Ingreso HTTPS/TCP (puertos 443, 8443, 10000)	Compartir un servicio fuera de tu tailnet	Gratis (plan personal)

Algunas correcciones importantes respecto a cómo se suele presentar esta tabla en otros lados: rathole no realiza routing HTTP-aware — es un port-forwarder TCP/UDP genérico sin capa HTTP basada en subdominios o rutas, a diferencia de frp o ngrok. Y Tailscale Funnel no es una malla L3 de propósito general — la red Tailscale subyacente es la malla privada de WireGuard; Funnel es la función estrecha y explícita que saca un solo servicio fuera de esa malla privada hacia internet público sobre HTTPS o TCP en un conjunto reducido de puertos fijos.

El ecosistema impulsado por Rust

El rendimiento y la seguridad en memoria son cruciales para relays en el borde que manejan millones de conexiones multiplexadas de WebSocket y TCP, y la comunidad de código abierto ha migrado cada vez más de Go y Node.js a Rust para esta capa. rathole sacrifica la conciencia HTTP por rendimiento bruto y un tamaño mínimo — su binario puede ser tan pequeño como aproximadamente 500KB en una compilación sin símbolos, con una versión completa más grande. Autentica y encripta usando el Noise Protocol Framework, con el patrón Noise_NK (no autenticado Noise_NN que a veces se muestra en tutoriales), que requiere generar un par de claves con rathole --genkey y configurar el cliente con la clave pública del servidor. bore va aún más hacia el minimalismo: un solo binario en Rust, solo TCP, con un relay comunitario gratuito en bore.pub. Su flag --secret autentica el handshake del túnel, pero no encripta el tráfico del túnel por defecto — TLS aún debe ser gestionado por lo que esté detrás del túnel o añadido en otra capa.

Dentro de este campo centrado en Rust, rustunnel es un participante más reciente y con más funciones que apunta directamente al caso de uso de ngrok. Tiene licencia AGPL, expone servicios locales HTTP, TCP y UDP (más túneles P2P nativos con autenticación de secreto compartido) a través de un borde gestionado o un relay auto-hospedado, y actualmente tiene alrededor de 600–650 estrellas en GitHub con actividad constante hasta 2026.

• Arquitectura y encriptación: el tráfico cliente-servidor corre sobre conexiones WebSocket encriptadas y terminadas en TLS, con provisión automática de Let’s Encrypt para endpoints públicos generados.
• Alta disponibilidad: múltiples backends pueden estar detrás de un subdominio o puerto TCP personalizado, balanceados entre miembros sanos con sondas de salud TCP/HTTP configurables, de modo que un backend muerto se retire automáticamente.
• Observabilidad: un panel en terminal de pantalla completa muestra estado en vivo de sesiones, latencia por región y contadores de solicitudes por segundo, junto con salida en JSON legible por máquina. Los materiales del proyecto también listan métricas de Prometheus y registros de auditoría como funciones — útiles para telemetría a nivel de conexión y túnel (quién se conectó, cuándo, cuánto data movió), en lugar de inspeccionar el contenido real del payload del túnel, en línea con la postura de privacidad de rustunnel de no leer tráfico de capa de aplicación.
• Integración con agentes AI: incluye un servidor MCP nativo con guías de configuración con un clic para Cursor, Claude Code, Claude Desktop y Windsurf, distribuidos como binario nativo en lugar de paquete npm.
• Precios: auto-hospedaje gratuito (túneles ilimitados, código fuente AGPL), un nivel gratuito alojado (hasta 3 túneles, sin dominios personalizados), y un nivel de pago por uso con un mínimo de $3/mes más $0.10/GB adicional — sin medidor de uptime por hora, por lo que túneles inactivos no generan cargos más allá del mínimo fijo. El borde gestionado actualmente opera en tres regiones: Helsinki, Hillsboro (Oregón) y Singapur.

Si un nivel en la nube gestionado como este cambia sus términos o cierra, la misma lógica del AGPL arriba se aplica: el código del servidor exacto está disponible para auto-hospedaje de forma gratuita.

Identificando y evitando software en abandono

Evitar el bloqueo de proveedor solo ayuda si la alternativa de código abierto está realmente mantenida. La cantidad de estrellas puede ser engañosa, ya que reflejan popularidad histórica más que actividad actual.

frp (Fast Reverse Proxy) es el ejemplo más claro de infraestructura auto-hospedada duradera y activa en este espacio: tiene licencia Apache-2.0, está escrito en Go, y ha superado las 106,000 estrellas en GitHub con actividad continua, ofreciendo reenvío TCP, UDP, HTTP y HTTPS con enrutamiento por subdominios vhost y sin intermediarios en el camino del tráfico.

localtunnel, en contraste, es una historia de advertencia que vale la pena señalar aunque todavía aparece en tutoriales constantemente: el repositorio localtunnel/localtunnel tiene unas 22,000 estrellas en GitHub, pero su actividad de commits y estrellas se ha estancado — prácticamente sin nuevos commits o estrellas semana a semana hasta mediados de 2026. Un proyecto tan silencioso conlleva riesgos reales: dependencias sin parches, deriva en TLS/protocolos, y un servidor relay público sin mantenimiento que podría desaparecer sin aviso. Es razonable para una demo rápida de cinco minutos; pero una base pobre para algo en lo que planees confiar a largo plazo.

Desplegando un relay de código abierto

Pasar de un túnel SaaS propietario a un relay AGPL auto-hospedado es una lista corta de pasos, y tiene la misma estructura ya sea que elijas rustunnel, frp o rathole:

1. Provisionar un host. Un VPS Linux pequeño con IP pública es suficiente — presupuesto aproximadamente $4–6/mes; por ejemplo, el VPS más barato de DigitalOcean, actualmente, empieza en unos $4/mes.
2. Configurar DNS. Para herramientas de enrutamiento HTTP (rustunnel, frp), crea un registro A comodín (ej., *.tunnel.tudominio.com) apuntando a la IP pública del VPS, para que el relay pueda asignar subdominios dinámicamente. Herramientas solo TCP como rathole y bore no necesitan esto — se enlazan directamente a puertos.
3. Desplegar el relay. La mayoría de estos proyectos ofrecen imágenes Docker y/o archivos de servicio systemd, así que un docker-compose up o una instalación con gestor de paquetes inicia el servidor rápidamente.
4. Conectar desde tu máquina local. El cliente establece una conexión persistente y encriptada con el VPS, enlazando algo como localhost:8080 a un endpoint público en tu dominio.

El auto-hospedaje elimina límites arbitrarios de ancho de banda, evita completamente el CGNAT del ISP, y — dado que el código del relay es el mismo en ambos casos — que un proveedor comercial cambie sus precios o cierre, no obliga a reescribir. Con infraestructura licenciada bajo AGPL, el desarrollador, no el proveedor, controla finalmente las reglas de enrutamiento.