ngrok vs. zrok: La Alternativa Zero-Trust y Peer-to-Peer para Túneles de Ingreso Modernos

Durante casi una década, cuando un desarrollador necesitaba exponer instantáneamente una aplicación local o un webhook interno al internet público, simplemente escribía un comando en su terminal: ngrok http 8080.

Durante años, eso fue suficiente. Pero el panorama moderno de DevOps y seguridad ha cambiado. Con un énfasis creciente en la soberanía de datos, cumplimiento y defensa perimetral empresarial, enrutar APIs internas sensibles, conjuntos de datos locales o microservicios a través de un proxy en la nube de terceros ahora es una preocupación real de cumplimiento para equipos regulados. Sumemos los cambios en precios y cuotas de ngrok en febrero de 2026 — que redujeron significativamente la capa gratuita — y no sorprende que los desarrolladores busquen alternativas con más interés.

Aquí entra zrok. Construido sobre el framework open-source OpenZiti de NetFoundry, zrok es una plataforma de compartición peer-to-peer (P2P) y túneles de confianza cero. Soporta completamente el flujo de trabajo tradicional de “URL pública”, pero también invierte el paradigma de ingreso ofreciendo túneles privados y peer-to-peer que nunca tocan el internet público.

Esta guía desglosa las diferencias arquitectónicas, financieras y filosóficas entre ngrok y zrok — y actualiza algunas afirmaciones que ya no son válidas en 2026.

La Divergencia Arquitectónica Central

Proxy en la Nube Tradicional (ngrok)

El tunneling tradicional se basa en un modelo centralizado de relay cliente-servidor. Cuando inicias una sesión, se establece una conexión saliente persistente con un nodo relay público. El proveedor ofrece un dominio público, y todo el tráfico entrante dirigido a esa URL llega a los servidores en la nube del proveedor, se inspecciona y se enruta allí, y luego se canaliza hacia tu máquina.

Esta arquitectura tiene tres compromisos conocidos:

• Soberanía de datos: tu carga útil — una solicitud de autenticación, una consulta de base de datos en crudo, datos propietarios del cliente — pasa por un relay de terceros.
• Punto único de fallo: si la región en la nube del proveedor tiene una caída, tus endpoints externos dejan de funcionar, independientemente de la disponibilidad de tu máquina.
• Penalizaciones por latencia: el tráfico realiza múltiples saltos de ida y vuelta a una puerta de enlace centralizada.

Redes de malla Zero-Trust, Overlay (zrok)

zrok es una aplicación “nativa de ziti” — crea una red overlay basada en identidades usando OpenZiti en lugar de un simple túnel relay. Cada servicio, endpoint y dispositivo necesita una identidad verificada y firmada criptográficamente antes de que se pueda solicitar una conexión. Por defecto, zrok elimina los puertos entrantes en tu máquina local, usando conexiones salientes para enlazar nodos.

Compartición Pública vs. Túneles Privados Peer-to-Peer

Paradigma Público (Ambas Herramientas)

Ambas herramientas permiten crear una URL pública para compartir tu localhost con internet. Ejecutar zrok share public http://localhost:8080 provisiona una URL pública a través del proxy frontal de zrok, con TLS automático y defensas contra cargas útiles excesivas y inyección SQL en la app compartida.

Una corrección importante: zrok no es inmune a la fricción por la que ngrok suele ser criticado. Las cuentas gratuitas no verificadas de zrok también muestran una página intersticial anti-phishing en la primera visita a una compartición pública — el mismo mecanismo que ngrok. Verificar tu cuenta de zrok con una tarjeta de crédito (sin cargo) elimina esto, igual que actualizar un plan de ngrok.

Paradigma Privado Peer-to-Peer (Exclusivo de zrok)

Para microservicios corporativos sensibles, bases de datos internas de staging o datos clasificados de entrenamiento AI, exponer incluso una URL pública autenticada suele ser un riesgo inaceptable. Aquí es donde la compartición privada de zrok cambia las reglas — crea un túnel cifrado que nunca toca ni registra en internet público.

+-----------------------+                    +-----------------------+
|  Host (Tu Máquina)    |                    | Invitado (Tu Peer)    |
|                       |                    |                       |
|  [App Local: 8080]    |                    |  [Proxy Local: 9090]  |
|          ^            |                    |          ^            |
|          |            |                    |          |            |
|   (zrok share private)|                    |   (zrok access private|
+----------+------------+                    +----------+------------+
           |                                            |
           v                                            v
     [OpenZiti Identity] <==================> [OpenZiti Identity]
                         Túnel cifrado de extremo a extremo

El flujo de trabajo:

1. Hospeda el recurso privado — el host ejecuta zrok share private http://localhost:8080. En lugar de una URL pública, zrok devuelve un token de acceso efímero y único.
2. Envía el token fuera de banda — por chat cifrado o gestor de secretos interno, nunca por el canal de compartición pública.
3. Vincula el cliente — el destinatario ejecuta zrok access private <token>.
4. Acceso vía bucle local — zrok inicia un proxy local en la máquina del destinatario, por ejemplo, http://localhost:9090.

Dado que nunca se crea un registro DNS público ni un nodo de enrutamiento en el borde público, el flujo de datos permanece oculto a escáneres y bots automatizados.

Comparación Detallada Característica por Característica

Dimensión	ngrok	zrok
Modelo de licencia	Propietario / comercial, cerrado	Open-source (Apache 2.0), mismo que OpenZiti
Arquitectura central	Relay en la nube HTTP/TCP centralizado	Overlay distribuido basado en identidades y confianza cero
Auto-hospedaje	No posible — limitado a la nube de ngrok	Totalmente soportado — Docker, binario para Linux, “desde Raspberry Pi hasta escala empresarial”
Compartición privada	No disponible — todos los endpoints son inherentemente públicos	Compartición privada P2P nativa, sin crear un endpoint público
URL gratuita persistente	Sí, desde 2023 — cada cuenta gratuita obtiene un “dominio de desarrollo” estático que sobrevive a reinicios	Sí, mediante comparticiones reservadas/nombreadas
Límites en capa gratuita	1 GB/mes transferencia, 3 endpoints en línea, 20,000 solicitudes/mes, 5,000 conexiones TCP/mes	5 GB/día transferencia, 25 entornos, 50 backends compartidos, 50 frontends de acceso privado
Intersticial en primera visita (cuenta gratuita no verificada)	Sí	Sí
Utilidades adicionales	Inspección de webhooks, reproducción de solicitudes, OAuth	Compartición de archivos/drive integrada, túneles HTTP/TCP/UDP, unidades de red WebDAV

Precios, Ancho de Banda y Corrección sobre la capa gratuita de ngrok

El borrador original repetía algunos mitos antiguos sobre la capa gratuita de ngrok — que los túneles “frecuentemente se agotan” y que las URLs “rotan en cada inicio”. Ninguno de estos es correcto ahora, y vale ser precisos sobre qué cambió y cuándo.

Lo que ya no es cierto: la documentación de ngrok indica explícitamente que la capa gratuita “NO tiene timeouts en los endpoints” — puedes mantener un endpoint gratuito funcionando indefinidamente como servicio en segundo plano. Y desde que ngrok lanzó dominios estáticos gratuitos (cambio introducido en 2023 y reforzado en 2026), cada cuenta gratuita recibe un subdominio persistente como tu-nombre.ngrok-free.dev que no cambia al reiniciar el agente. El problema clásico de que las URLs de webhook se rompen tras reiniciar ngrok ya no existe en el flujo gratuito por defecto.

Lo que sí es cierto y representa un problema en 2026: ngrok ajustó significativamente las cuotas de la capa gratuita en febrero de 2026. El plan gratuito actual limita a 1 GB de transferencia de datos por mes, 20,000 solicitudes HTTP, 5,000 conexiones TCP y solo 3 endpoints en línea simultáneos — sin dominios comodín ni personalizados, y sin endpoints TLS en la capa gratuita. Para un desarrollador individual que prueba webhooks ocasionalmente, esto es suficiente; para tráfico real, los equipos se mueven rápidamente a los planes Hobbyist ($8–10/mes) o Pay-as-you-go ($20/mes más uso).

La Libertad del Código Abierto con zrok

Por ser open-source bajo licencia Apache 2.0, zrok permite a los desarrolladores tener control total sobre su ruta de ingreso. La capa gratuita gestionada por NetFoundry en zrok.io actualmente incluye:

• 5 GB de transferencia diaria
• Hasta 25 entornos (un usuario o servicio en un dispositivo)
• 50 backends compartidos (efímeros o reservados)
• 50 frontends de acceso privado
• La página intersticial en primera visita eliminada tras verificar la cuenta con tarjeta (sin cargo)

Para entornos regulados — HIPAA, GDPR, SOC 2 Tipo II — el binario único de zrok permite ejecutar todo el plano de control en tu propio VPS o infraestructura privada, manteniendo la propiedad de las rutas de transmisión, métricas y almacenes de identidad.

zrok v2.0: Qué Cambió en marzo de 2026

zrok lanzó una importante versión 2.0 en marzo de 2026, y vale la pena destacarla ya que muchos tutoriales existentes (incluyendo partes del borrador original en que se basa este artículo) aún usan la sintaxis de comandos v1:

• El binario ahora es zrok2, no zrok. Ambos pueden correr en paralelo en la misma máquina — v2 usa su propio directorio de entorno (~/.zrok2), su propio prefijo de variables de entorno (ZROK2_*) y sus propias unidades systemd, por lo que actualizar no afecta una configuración v1 existente.
• Las comparticiones reservadas fueron reemplazadas por un modelo de namespace/names. Los comandos antiguos zrok reserve / zrok release / zrok share reserved desaparecieron; ahora zrok2 create share y zrok2 delete share pre-asignan y gestionan tanto comparticiones públicas como privadas, y zrok2 modify name -r puede promover una compartición efímera a una persistente sobre la marcha sin necesidad de eliminar y recrear.
• El modo backend VPN fue eliminado. La capacidad de VPN host-to-host mencionada en documentación antigua y en el borrador original fue retirada en v2 debido a conflictos de dependencias en las bibliotecas TUN. Si tu flujo dependía de zrok share private --backend-mode vpn, esa opción ya no está disponible — la guía de migración del proyecto cubre alternativas.

Nuevo en 2026: Infraestructura Zero-Trust para Agentes AI

Esto merece atención especial para equipos que ya piensan en tráfico MCP e infraestructura para agentes, ya que es una extensión natural de la discusión de túneles de ingreso:

• openziti/mcp-gateway agrega múltiples backends MCP — servidores stdio locales y comparticiones zrok remotas — en una única conexión con namespace para un cliente AI, con filtrado allow/deny por herramienta y aislamiento de sesiones por cliente (sin estado compartido entre clientes que usan el mismo gateway).
• ziti-mcp-server envuelve toda la API de gestión Ziti — 209 herramientas que cubren identidades, servicios, routers de borde, políticas y operaciones de la fabric — como un servidor MCP, permitiendo que un agente en Claude Desktop, Cursor o similares gestione una red OpenZiti de forma conversacional en lugar de por consola o llamadas REST en crudo.
• openziti/llm-gateway es un proxy compatible con OpenAI que realiza enrutamiento semántico entre OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex AI y Ollama, con el tráfico de enrutamiento e inferencia llevado sobre la capa de confianza cero en lugar del internet abierto.

Los tres son open-source y patrocinados por NetFoundry, y usan las mismas primitivas de compartición privada descritas arriba — un endpoint de herramienta MCP puede compartirse exactamente como un backend HTTP privado, sin puerto de escucha ni URL pública, en línea con el argumento de “oscuro por defecto” que hace este artículo sobre túneles en general.

La Decisión: ¿Cuándo Usar Cuál?

Elige ngrok si: - Estás creando un proyecto hobby rápido y no sensible, y quieres una plataforma estable y bien documentada. - Tu flujo ya está integrado con el panel de ngrok, inspección de tráfico o funciones de reproducción de solicitudes. - Tu uso se ajusta cómodamente a 1 GB/mes y 20,000 solicitudes/mes, o estás dispuesto a pagar por Hobbyist/Pay-as-you-go cuando deje de ser suficiente.

Elige zrok si: - La seguridad y privacidad son prioritarias — necesitas compartir APIs internas o métricas sin exponer un endpoint público. - Requieres soberanía de datos — una herramienta open-source que tu equipo puede auto-hospedar en una VPC privada. - Quieres una capa gratuita realmente generosa — 5 GB/día y sin timeouts forzados. - Quieres compartición de archivos/drive integrada o estás experimentando con infraestructura MCP/agente zero-trust junto con tus necesidades de túneles.

Al pasar de proxies en la nube centralizados a túneles de confianza cero y verificados por identidad, zrok ofrece a los equipos de ingeniería una solución auto-hospedada, compatible con cumplimiento, con la advertencia de que, como cualquier proyecto open-source en desarrollo activo, su superficie de comandos y conjunto de funciones (como la eliminación de VPN en v2.0) puede cambiar.

---

Registro de Cambios

Corregido: - Eliminada la afirmación de que los túneles en la capa gratuita de ngrok “frecuentemente se agotan” — la propia documentación de ngrok confirma que no hay timeouts en los endpoints. - Eliminada la afirmación de que las URLs gratuitas de ngrok “rotan en cada inicio” — desde 2023, cada cuenta gratuita tiene un dominio estático persistente, como tu-nombre.ngrok-free.dev. - Reemplazadas las expresiones vagas sobre límites en la capa gratuita por los límites reales publicados por ngrok (1 GB/mes, 3 endpoints, 20,000 solicitudes, 5,000 conexiones TCP), extraídos de la documentación de precios y límites. - Se señaló que zrok también muestra una página intersticial en la primera visita en cuentas gratuitas no verificadas — el borrador original implicaba que esto era exclusivo de ngrok. - Se indicó que el modo backend VPN de zrok, mencionado en la lista de utilidades del borrador original, fue eliminado en la versión 2.0 de marzo de 2026 por conflictos de dependencias.

Agregado: - Sección “zrok v2.0” que cubre el cambio de zrok a zrok2, el modelo de namespace/names en lugar de comparticiones reservadas, y la eliminación de VPN — dado que varias guías aún usan sintaxis de v1. - Sección nueva sobre infraestructura zero-trust en 2026 para agentes AI: openziti/mcp-gateway, ziti-mcp-server (209 herramientas de API de gestión Ziti expuestas vía MCP), y openziti/llm-gateway. - Confirmación y mantenimiento de los números del nivel gratuito de zrok (5 GB/día, 25 entornos, 50 backends compartidos, 50 frontends de acceso privado) directamente desde la página de precios de zrok — estos datos eran precisos en el borrador original.

Eliminado: - Enfoque de marketing exagerado (“último”, “Enter zrok”) que se suavizó donde sobreestimaba la certeza. - Artefactos de formato del borrador original (encabezados y listas pegados).