ngrok vs. sish (El Serveo Autoalojado): Cómo Crear Tu Propio ngrok Privado Usando sish y un VPS de $5

En el desarrollo de software moderno, exponer tu entorno local al internet público es una necesidad diaria. Ya sea para probar webhooks, mostrar un trabajo en progreso a un cliente o depurar una integración API compleja, necesitas un túnel confiable. Durante años, los desarrolladores usaron herramientas de terceros como ngrok o Serveo. Sin embargo, a medida que crecen los equipos y se fortalecen los requisitos de seguridad, depender de servicios gestionados puede generar cuellos de botella, costos y problemas de cumplimiento de seguridad.

Si los límites del nivel gratuito de ngrok, la limitación de tasa o la imprevisibilidad del tiempo de actividad de alternativas gratuitas como Serveo te han frustrado alguna vez, quizás sea momento de tomar el control de tu infraestructura. Aquí entra sish, una alternativa de código abierto, activamente mantenida, que te permite construir tu propia versión privada de localhost.run o Serveo — o, desde este año, simplemente usar su servicio gestionado oficial en lugar de alojarlo tú mismo.

En esta guía, revisaremos el estado actual del tunelizado SSH, compararemos ngrok y sish de manera precisa con la documentación de ambos proyectos, y ofreceremos un tutorial paso a paso para montar tu propio ngrok privado usando sish y un VPS de $5.

---

La Evolución del Túnel Localhost

El Dominio de ngrok

Cuando los desarrolladores piensan en túneles localhost, ngrok suele ser el primer nombre que viene a la mente. Revolucionó la forma en que exponemos servidores locales. Con un simple comando (ngrok http 8080), recibes instantáneamente una URL HTTPS pública que reenvía el tráfico a tu máquina local.

El nivel gratuito de ngrok es realmente limitado, pero no en la forma que la mayoría de los artículos comparativos describen. Según la documentación actual de precios y límites de ngrok, el plan gratuito incluye:

• Un crédito de uso único de $5
• Hasta 3 puntos finales en línea y 3 agentes concurrentes
• 1 GB de transferencia de datos por mes
• 20,000 solicitudes HTTP/S por mes, con un límite aproximado de 4,000 solicitudes/minuto
• 5,000 conexiones TCP/TLS por mes
• Un “dominio de desarrollo” asignado automáticamente (por ejemplo, your-name.ngrok-free.app)
• Una página de advertencia intersticial mostrada a los visitantes del navegador en puntos finales HTTP/S gratuitos (que se puede omitir enviando un encabezado ngrok-skip-browser-warning o un User-Agent no predeterminado — sin necesidad de actualizar)

Un mito común que vale la pena corregir: muchos blogs de marketing que promocionan alternativas a ngrok afirman que el nivel gratuito ahora impone un límite de sesión de 2 horas. La propia documentación de ngrok contradice esto — los puntos finales del nivel gratuito no tienen límite de tiempo y pueden funcionar indefinidamente como un servicio en segundo plano. Las restricciones reales son los límites mensuales de datos, solicitudes y conexiones mencionados arriba, además de la imposibilidad de reservar un dominio personalizado y la página intersticial. Desconfía de cualquier artículo que cite un “límite de 2 horas”.

Los niveles de pago también han sido reestructurados. La oferta actual (según las páginas de precios y límites de ngrok) es:

Plan	Precio	Transferencia de datos	Solicitudes	Puntos finales
Gratuito	$0	1 GB/mes	20k/mes	3
Hobbyist	$8/mes (anual) o $10/mes	5 GB/mes	100k/mes	3
Pago por uso	$20/mes base (incluye $20 en crédito de uso)	Medido ($0.10/GB)	Medido ($1/100k)	Ilimitado
Empresarial	Personalizado / solo cotización	Personalizado	Personalizado	Personalizado

Aparte del costo, algunas redes corporativas también restringen o marcan el tráfico de ngrok por defecto, ya que sus dominios compartidos han sido utilizados para phishing y malware, lo que representa un problema de seguridad independiente del precio.

La Ascensión y Caída de Serveo

Como alternativa al agente propietario de ngrok, los desarrolladores optaron por Serveo. Serveo era notable porque no requería instalación — aprovechaba el cliente SSH estándar ya instalado en casi todas las máquinas de los desarrolladores. Ejecutar ssh -R 80:localhost:8080 serveo.net devolvía instantáneamente una URL pública.

Serveo se convirtió en una opción popular para túneles SSH gratuitos, pero su naturaleza abierta y sin autenticación lo convirtió en un imán para abusos de phishing y malware. Esto llevó a listas negras recurrentes y caídas. La disponibilidad de Serveo hoy en día sigue siendo inconsistente — los monitores de terceros muestran que fluctúa entre “activo” y “caído” dependiendo de la región y el momento, en línea con un servicio gratuito de mantenimiento ligero en lugar de uno confiable. Aún es accesible de forma intermitente, pero no es algo en lo que confiar para algo cercano a producción.

La Entrada de sish: El Éxito de Código Abierto

sish, creado por el desarrollador Antonio Mika, es la respuesta de la comunidad de código abierto a la brecha que dejó Serveo. Es un proyecto activamente mantenido — actualmente en la versión v2.23.0 (junio 2026), con aproximadamente 4.6k estrellas en GitHub, 329 forks y 64 lanzamientos etiquetados — y ahora patrocinado por pico.sh, el proyecto de herramientas para desarrolladores basado en SSH que Mika también mantiene.

A diferencia de Serveo, que solo existía como un servicio público, sish está diseñado explícitamente para ser autoalojado en tu propia infraestructura. Funciona como un servidor SSH que reenvía el tráfico a los clientes conectados.

Una actualización importante desde los primeros días de sish: ya no tienes que alojarlo tú mismo si no quieres. El proyecto ahora ofrece un servicio gestionado oficial en tuns.sh, mantenido por el mismo equipo, como la forma más rápida de probar sish sin tocar un VPS:

ssh -R 80:localhost:8080 tuns.sh

Esto crea instantáneamente una URL pública para algo que corre en el puerto 8080 local — sin registro, sin instalar cliente. Sin embargo, alojarlo tú mismo sigue siendo la mejor opción para equipos que necesitan dominios personalizados, túneles privados o control total sobre la residencia de datos, que es lo que cubre el resto de esta guía.

El Superpoder de sish

¿Qué hace que sish destaque en el campo saturado de herramientas de túnel?

1. Soporte de protocolos: sish maneja conexiones HTTP, HTTPS, TCP, WS (WebSockets) y WSS, además de enrutamiento TLS basado en SNI sin terminar la conexión TLS.
2. Sin instalación de cliente: Igual que Serveo, sish usa el cliente SSH nativo (ssh -R). Tu equipo no necesita herramientas CLI propietarias ni agentes.
3. Certificados TLS: sish puede servir HTTPS con certificados propios, o solicitarlos bajo demanda de Let’s Encrypt (--https-ondemand-certificate), o — si usas el despliegue oficial con Docker Compose — certificados wildcard automáticos mediante desafíos DNS-01 con el contenedor dnsrobocert incluido.
4. Multiplexación: sish soporta subdominios comodín, permitiendo que múltiples desarrolladores soliciten sus propios subdominios en tiempo real (por ejemplo, dev1.tudominio.com, api-prueba.tudominio.com).
5. Seguridad y autenticación, activadas por defecto: Desde la versión actual, sish requiere autenticación SSH por defecto (clave pública o contraseña) — ya no es una herramienta “abierta por defecto, segura después”. Configuras quién puede acceder antes de abrir un túnel.
6. Alias TCP privados y balanceo de carga: Además de túneles públicos, sish soporta alias TCP internos (solo accesibles mediante acceso SSH autenticado), y modos opcionales de balanceo para que múltiples clientes compartan el mismo endpoint HTTP, TCP o SNI.
7. Inspección de tráfico: Una consola de administración y una consola de servicio por túnel permiten inspeccionar las solicitudes reenviadas — cerrando parte de la brecha con el inspector de tráfico de ngrok, sin enviar tu tráfico a terceros.

---

ngrok vs. sish: ¿Cuál es el adecuado para ti?

Característica	ngrok (SaaS)	sish (Autoalojado o Gestionado)
Arquitectura	Servicio gestionado de terceros	Autoalojado en tu infraestructura, o usa el servicio gestionado tuns.sh
Software cliente	Requiere el agente CLI de ngrok	Usa SSH nativo (ssh)
Dominios personalizados	Requiere plan Hobbyist o superior	Gratis en autoalojado; trae tu propio dominio
Costo	Gratis (limitado) hasta $20/mes base + uso en pago por uso	~$5/mes VPS + dominio, o gratis con tuns.sh para pruebas rápidas
Privacidad de datos	El tráfico pasa por la nube de ngrok	El tráfico pasa por tu propio VPS (autoalojado)
Límites de tasa	1GB/20k solicitudes (Gratis), 5GB/100k (Hobbyist), medido más allá	Sin límites inherentes a sish; solo limitado por el ancho de banda de tu VPS
Timeout del endpoint	Ninguno (un mito común dice lo contrario)	Ninguno
Autenticación por defecto	Basada en cuenta (SaaS)	Se requiere autenticación SSH (clave o contraseña) por defecto desde versiones recientes
Tiempo de configuración	Instantáneo	Instantáneo con tuns.sh; aproximadamente 15–30 minutos para configurar en VPS propio
Mantenimiento	Ninguno (gestionado por ti)	Mínimo (actualizaciones del SO y contenedores) en autoalojado; ninguno con tuns.sh

Cuándo elegir ngrok: quieres una experiencia pulida y totalmente gestionada con inspección de tráfico integrada y no te importan los límites del nivel gratuito en datos/solicitudes, o necesitas funciones empresariales como SSO y registros de auditoría.

Cuándo elegir sish: tienes un equipo que quiere subdominios personalizados persistentes sin tarifas SaaS, manejas datos que no deben pasar por terceros, o quieres ancho de banda sin límites solo limitado por tu VPS.

---

Cómo Crear Tu Propio ngrok Privado Usando sish y un VPS de $5

Requisitos

1. Un VPS en la nube: una instancia básica de $5/mes de DigitalOcean, Linode, Vultr o Hetzner es suficiente. Elige Ubuntu 22.04 LTS o 24.04 LTS.
2. Un nombre de dominio (por ejemplo, mis-tuneles.com) para enrutar tráfico a tu VPS.
3. Conocimientos básicos de terminal con SSH y línea de comandos.
4. Tu clave pública SSH local (normalmente ~/.ssh/id_ed25519.pub) — la necesitarás desde el principio, ya que sish ahora requiere autenticación desde el inicio.

Paso 1: Configura tus registros DNS

Para que sish enrute tráfico dinámicamente a diferentes subdominios, crea un registro DNS comodín. En el panel DNS de tu registrador, crea dos registros A que apunten a la IP pública de tu VPS:

1. Registro principal: Host mis-tuneles.com (o @) → IP de tu VPS
2. Registro comodín: Host *.mis-tuneles.com → IP de tu VPS

La propagación DNS puede tardar desde unos minutos hasta unas horas.

Paso 2: Prepara tu VPS (Instala Docker)

Conéctate a tu VPS vía SSH:

ssh root@tu_ip_vps

Actualiza los paquetes:

sudo apt update && sudo apt upgrade -y

Instala Docker con el script oficial:

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
docker --version

Paso 3: Despliega sish, Seguro desde el Inicio

Las guías antiguas de sish te sugerían desplegar sin autenticación y bloquearlo después. Eso ya no es recomendable — las versiones recientes de sish requieren autenticación SSH por defecto, por lo que la configuración segura y la de trabajo ahora son el mismo paso.

Crea los directorios necesarios y copia tu clave pública antes de iniciar el contenedor:

mkdir -p ~/sish/ssl ~/sish/keys ~/sish/pubkeys
cp ~/.ssh/id_ed25519.pub ~/sish/pubkeys/

Descarga la imagen actual y ejecútala, reemplazando tu dominio:

docker pull antoniomika/sish:latest

docker run -itd --name sish \
  --restart always \
  -v ~/sish/ssl:/ssl \
  -v ~/sish/keys:/keys \
  -v ~/sish/pubkeys:/pubkeys \
  --net=host antoniomika/sish:latest \
  --ssh-address=:2222 \
  --http-address=:80 \
  --https-address=:443 \
  --https=true \
  --https-certificate-directory=/ssl \
  --authentication-keys-directory=/pubkeys \
  --private-keys-directory=/keys \
  --bind-random-ports=false \
  --domain=mis-tuneles.com

Algunas notas sobre estas banderas: * --net=host enlaza el contenedor directamente a las interfaces de red del host para un registro preciso de IPs. * --ssh-address=:2222 evita conflictos con el daemon SSH del VPS en el puerto 22. * --authentication-keys-directory=/pubkeys indica a sish dónde buscar las claves autorizadas; se recarga automáticamente al añadir o quitar archivos, sin reiniciar. * --bind-random-ports=false permite a los clientes solicitar puertos TCP específicos en lugar de uno aleatorio. * Este despliegue básico asume que ya tienes certificados en /ssl (por ejemplo, mediante certbot). Si quieres que sish obtenga certificados Let’s Encrypt bajo demanda, añade --https-ondemand-certificate --https-ondemand-certificate-accept-terms; para certificados wildcard automáticos mediante desafío DNS-01, usa el despliegue oficial con Docker Compose, que incluye el contenedor dnsrobocert para ello.

Verifica los logs para confirmar que inició correctamente:

docker logs -f sish

Paso 4: Prueba tu nuevo ngrok privado

Desde tu máquina local — no el VPS — con un servidor local en el puerto 3000:

ssh -p 2222 -R 80:localhost:3000 mis-tuneles.com

Como tu clave pública ya es confiable, conecta de inmediato y devuelve una URL HTTPS como:

Presiona Ctrl-C para cerrar la sesión.
Reenviando a:
https://aleatoriodecadena.mis-tuneles.com

Solicitar un subdominio personalizado

ssh -p 2222 -R nombre-personalizado:80:localhost:3000 mis-tuneles.com

Esto intenta enlazar https://nombre-personalizado.mis-tuneles.com, siempre que ese subdominio no esté ya en uso por otro usuario en tu servidor.

Gestionar acceso de desarrolladores

Como la carpeta pubkeys se monitorea continuamente, añadir o quitar acceso a un compañero es solo una operación de archivos — sin reiniciar:

nano ~/sish/pubkeys/nuevo-companero.pub
# pega su clave pública, guarda

Una forma sencilla de incorporar claves desde GitHub:

curl https://github.com/su-usuario-github.keys  ~/sish/pubkeys/su-usuario-github

---

Casos avanzados de uso de sish

1. Evitar firewalls con túneles TCP

sish no se limita a HTTP/HTTPS. Para exponer una instancia local de MySQL (puerto 3306) a un cliente remoto:

ssh -p 2222 -R 3306:localhost:3306 mis-tuneles.com

Tu cliente remoto se conecta a mis-tuneles.com:3306 y el tráfico se enruta de forma segura a tu base de datos local.

2. Alias TCP privados (sin exposición pública)

Para patrones de acceso que no deben ser accesibles desde internet ni siquiera tras autenticación, sish soporta alias TCP solo alcanzables mediante un salto SSH autenticado — nada expuesto públicamente:

ssh -p 2222 -R miportatil:22:localhost:22 mis-tuneles.com

Un compañero con acceso puede alcanzarlo así:

ssh -J mis-tuneles.com miportatil

3. Integración en equipo

Estandariza el comando de túnel en el package.json o Makefile de tu equipo:

"scripts": {
  "start": "react-scripts start",
  "tunnel": "ssh -p 2222 -R $(whoami)-dev:80:localhost:3000 mis-tuneles.com"
}

Cuando Alice ejecuta npm run tunnel, obtiene alice-dev.mis-tuneles.com; Bob obtiene bob-dev.mis-tuneles.com.

4. Pruebas en pipelines CI/CD

Dado que sish solo necesita un cliente SSH estándar, es fácil integrarlo en GitHub Actions o GitLab CI — inicia una instancia temporal, túnelalo a través de tu servidor sish, y realiza pruebas end-to-end contra la URL pública antes de eliminarlo.

5. Balanceo de carga y enrutamiento SNI

Si tu caso de uso crece más allá de un túnel de desarrollador, los modos opcionales de balanceo de carga (--http-load-balancer, --tcp-load-balancer, --sni-load-balancer) permiten que múltiples clientes compartan el mismo dominio, puerto o SNI — útil para failover básico sin montar un balanceador separado.

---

Resumen

El pulido y las herramientas de inspección de tráfico de ngrok siguen siendo útiles, y su nivel gratuito — aunque limitado en datos y solicitudes, no en duración de sesión — es una forma razonable de probar. Pero para equipos que quieren control, privacidad de datos y costos previsibles, el autoalojamiento se ha simplificado, no complicado: sish ahora viene con seguridad por defecto, ofrece una opción gestionada en tuns.sh para pruebas sin configuración, y ha añadido funciones (alias TCP, proxy SNI, balanceo, consolas de tráfico) que acortan la brecha con plataformas comerciales.

Invertiendo unos $5 al mes y 20 minutos de configuración, puedes gestionar un servidor de túneles privado, personalizado y controlado por tu equipo.

---

Registro de cambios

Este artículo fue reescrito a partir de un borrador enviado y verificado contra fuentes principales el 18 de julio de 2026.

Correcciones: 1. Se eliminó completamente la afirmación de que el nivel gratuito de ngrok tiene un timeout de sesión de 2 horas y se añadió una corrección explícita. La propia documentación de límites y precios de ngrok indica que los puntos finales gratuitos no tienen timeout y pueden funcionar indefinidamente en segundo plano; las restricciones reales son los límites mensuales de datos, solicitudes y conexiones. Fuente: ngrok.com/docs/pricing-limits/free-plan-limits. 2. Se actualizó la estructura de precios de ngrok, que en el borrador original solo se describía en términos generales. Los niveles actuales según la documentación de precios y límites de ngrok: Gratuito ($0, crédito único de $5, 3 puntos finales, 1GB/20k solicitudes mensuales), Hobbyist ($8/mes anual o $10/mes, 5GB/100k solicitudes, aún 3 puntos finales), Pago por uso ($20/mes base con $20 en crédito, sin límite de puntos finales, medido en exceso), Empresarial (personalizado / solo cotización). Fuente: ngrok.com/docs/pricing-limits. 3. Se corrigió el flujo de despliegue en Docker. La antigua recomendación de desplegar sin autenticación y bloquear después ya no es válida — las versiones recientes de sish requieren autenticación SSH por defecto, por lo que la configuración segura y la de trabajo ahora son iguales. La guía fue reestructurada para colocar tu clave pública en ~/sish/pubkeys antes del primer despliegue en lugar de desplegar un relé abierto primero. Fuente: docs.ssi.sh/cli y docs.ssi.sh/getting-started. 4. Se actualizó el comando Docker para coincidir con el ejemplo actualmente documentado, añadiendo las banderas --private-keys-directory=/keys y --bind-random-ports=false que no estaban en el borrador original. Fuente: github.com/antoniomika/sish (README) y docs.ssi.sh/getting-started. 5. Se corrigió la afirmación sobre la automatización de Let’s Encrypt. La implementación simple con docker run no provee certificados Let’s Encrypt automáticamente — espera que los certificados ya estén en /ssl, a menos que añadas la bandera --https-ondemand-certificate, o uses el despliegue oficial con Docker Compose, que incluye el contenedor dnsrobocert para certificados wildcard automáticos mediante DNS-01. Fuente: docs.ssi.sh/getting-started.

Adiciones (no en el borrador original): 6. Se añadió el servicio gestionado oficial de sish, tuns.sh, como opción sin configuración para probar sish sin VPS. Fuente: github.com/antoniomika/sish, docs.ssi.sh/getting-started. 7. Se añadieron las estadísticas y estado actual del proyecto: sish está en la versión v2.23.0 (junio 2026), con aproximadamente 4.6k estrellas en GitHub, 329 forks y 64 lanzamientos etiquetados, patrocinado por pico.sh. Fuente: github.com/antoniomika/sish. 8. Se incluyó la funcionalidad de alias TCP privados (acceso por salto SSH sin exposición pública) y modos opcionales de balanceo de carga (--http-load-balancer, --tcp-load-balancer, --sni-load-balancer), que no estaban en el borrador original. Fuente: docs.ssi.sh/cli, github.com/antoniomika/sish. 9. Se añadió la consola de administración y servicio para inspección de tráfico, como alternativa autoalojada a la inspección de ngrok. Fuente: docs.ssi.sh/cli. 10. Se suavizó la afirmación sobre la disponibilidad de Serveo, reflejando informes de monitoreo de uptime que muestran que es accesible de forma intermitente en lugar de estar completamente caído, dado que los monitores de terceros muestran que fluctúa entre “activo” y “caído” dependiendo de la región y el momento. Fuente: monitoreos de uptime de terceros (isitdownorjustme.net, notopening.com), verificado en julio de 2026.