Hermes + Telegram vs. ngrok: ¿Cuál es la diferencia y cuándo usar cada uno?

Introducción: la pregunta que todo maker se hace

Estos días he estado aprendiendo sobre Ngrok y fue inicialmente difícil entender qué diferencia existía entre mi configuración actual de la Raspberry Pi+telegram y el uso de Ngrok.

Si tengo una Raspberry Pi y la controlo desde Telegram mediante un bot como Hermes,“¿Para qué necesitaría ngrok?”

Ambas soluciones parecen permitir acceso remoto a la Raspberry, así que es fácil pensar que compiten entre sí. Pero la realidad es otra:

Hermes + Telegram y ngrok resuelven problemas completamente distintos. No son alternativas, son herramientas complementarias que viven en categorías diferentes del stack de conectividad.

Hermes es un canal conversacional — un chat privado entre tú y tu Raspberry. ngrok es un túnel de red — convierte un servicio local en un endpoint público accesible desde internet.

En este artículo vamos a desarmar las dos tecnologías, mostrar la diferencia fundamental con diagramas, y dejar claro cuándo usar cada una (y cuándo usarlas juntas).

¿Cómo funciona Hermes con Telegram?

Hermes es un agente de IA open source que corre en la Raspberry Pi. Se conecta a Telegram mediante un bot, y desde ahí te permite:

• Ejecutar comandos en la terminal de la Pi
• Crear archivos y notas
• Programar tareas (cron jobs)
• Consultar modelos de IA locales como Ollama
• Integrarse con Home Assistant, n8n, GitHub, HubSpot y más

La arquitectura

La Raspberry Pi inicia una conexión saliente hacia los servidores de Telegram. Esto se llama “long polling” y es la clave de todo.

Ventajas de este enfoque

En resumen: Hermes + Telegram es ideal para administración personal y operativa. Es un canal de chat privado entre tú y tu máquina.

 ¿Qué hace realmente ngrok?

ngrok es una herramienta que crea un túnel seguro entre un servicio local (corriendo en tu Raspberry) y un endpoint público en internet.

El concepto de túnel

Imaginá que tienes una API REST corriendo en tu Raspberry en http://localhost:8000. El problema: nadie de afuera puede acceder a esa URL, porque vive solo dentro de tu red local.

ngrok resuelve esto exponiendo tu servicio local a través de una URL pública como:

https://a1b2c3d4.ngrok-free.app → http://localhost:8000

La arquitectura

El flujo es inverso al de Telegram:

1. La Pi inicia una conexión saliente hacia el cloud de ngrok (igual que Telegram)
2. ngrok asigna una URL pública que apunta a un servicio local
3. Cualquier persona o sistema en internet puede acceder a esa URL
4. ngrok reenvía las requests a tu servicio local a través del túnel cifrado

Casos clásicos de uso

• Recibir webhooks de servicios externos (GitHub, Stripe, HubSpot, Slack)
• Compartir una API en desarrollo con un cliente o compañero de equipo
• Demo en vivo de una app que corre en tu Pi
• Testing de integraciones que requieren una URL pública real

Nota: La diferencia crítica

A diferencia de Telegram, la URL de ngrok es pública y accesible por cualquiera que la conozca. No hay “chat_id autorizado” — cualquiera puede hacer requests a tu servicio.

Por eso ngrok es poderoso pero requiere que implementes autenticación en tu servicio (API keys, OAuth, JWT, etc.).

La diferencia fundamental

Después de explicar ambas arquitecturas, la diferencia queda clara:

Hermes + Telegram es un canal de comunicación bidireccional y autenticado por chat_id. Es conversacional, privado, y tú sos el único participante.

ngrok es un proxy reverso público que expone un servicio HTTP local a internet. Cualquier sistema puede consumirlo, y la autenticación la definís tú.

La diferencia no es únicamente “quién accede”, sino “cómo se establece la comunicación”:

Analogía simple: Telegram es como un walkie-talkie entre tú y tu Pi. ngrok es como abrir una ventanilla en tu casa para que el cartero pueda dejar paquetes.

Comparativa detallada

6. Ejemplos prácticos con Raspberry Pi

Veamos casos reales para entender cuándo usar cada uno.

Caso 1: Controlar Ollama desde Telegram (Hermes)

Quieres chatear con un LLM local (Llama 3, Mistral, etc.) desde tu celular.

# En tu Raspberry Pi
ollama serve  # corre en localhost:11434

# Hermes se conecta a Ollama y lo expone como chat en Telegram
# Tú escribís: /ollama ¿qué es un transformer?
# Telegram responde con la respuesta del modelo local

¿Por qué Hermes y no ngrok acá? Porque tú sos el único usuario, y la interfaz natural es un chat.

Caso 2: Recibir webhooks de HubSpot (ngrok)

Cuando un lead nuevo se crea en HubSpot, quieres que tu Raspberry lo procese (por ejemplo, para llamar a un modelo de Ollama que clasifica el lead).

# Tu API Flask en la Pi corre en localhost:5000/hubspot-webhook
# ngrok lo expone públicamente
ngrok http 5000

# URL pública: https://a1b2c3d4.ngrok-free.app
# En HubSpot configuras el webhook:
#   https://a1b2c3d4.ngrok-free.app/hubspot-webhook
# HubSpot hace POST cada vez que hay un lead nuevo

¿Por qué ngrok y no Telegram acá? Porque HubSpot es el que inicia la comunicación, no tú. HubSpot no sabe hablar por Telegram — necesita una URL HTTP pública.

Caso 3: GitHub Webhooks (ngrok)

Cada vez que hacés git push a un repo, quieres que tu Raspberry corra tests automáticamente.

ngrok http 8080

# En GitHub repo Settings > Webhooks:
#   Payload URL: https://a1b2c3d4.ngrok-free.app/webhook
#   Content type: application/json
#   Events: push

Mismo patrón: GitHub inicia la conexión, necesita URL pública.

Caso 4: Stripe (ngrok)

Stripe te paga y manda un webhook de confirmación. Tu Raspberry lo recibe y marca la orden como pagada en una base de datos local.

Caso 5: Slack (ngrok)

Slack slash commands también necesitan URL pública para responder.

Caso 6: n8n con webhooks externos (ngrok)

n8n corre workflows automatizados. Si un workflow arranca con un webhook trigger, ese webhook necesita URL pública. ngrok resuelve eso perfecto.

Caso 7: App móvil consumiendo tu API (ngrok)

Estás desarrollando una app en React Native que consume una API que vive en tu Pi. ngrok le da URL pública para que la app pueda hacer requests durante desarrollo.

¿Cuándo usar ambos juntos?

Hay proyectos donde conviven perfectamente. Ejemplo real: un dashboard de monitoring para tu Raspberry.

• Telegram = tu interfaz conversacional para preguntar cosas (“¿Cuánta RAM está usando la Pi?”)
• ngrok = expone Grafana (u otro dashboard) para verlo desde el navegador de cualquier dispositivo
• Ollama = corre local y responde preguntas técnicas en lenguaje natural
• Home Assistant = integrado con ambos

Otro caso: un bot de Telegram que además expone una API REST para que otras apps lo consuman.

# Tu API en la Pi
@app.route("/ask", methods=["POST"])
def ask():
    question = request.json["question"]
    answer = ollama.generate(question)
    return {"answer": answer}

# ngrok expone /ask
# https://a1b2c3d4.ngrok-free.app/ask

Mientras tanto, tú seguís chateando con la Pi desde Telegram normalmente. Dos interfaces, una sola Pi.

Buenas prácticas de seguridad

Ambas herramientas requieren cuidados. La seguridad por defecto es alta en Telegram, baja en ngrok.

[Seguridad] Para Hermes + Telegram

• Restringí el chat_id: solo tu chat_id personal puede hablarle al bot. Esto cierra el 99% de los vectores de ataque.
• Usá tokens seguros: guardá el bot token en variables de entorno, nunca en el código.
• Limitá comandos sensibles: si la Pi hace cosas críticas (apagar servicios, deploys), pedí confirmación explícita.

ALLOWED_CHAT_ID = 123456789  # solo este chat_id puede usar el bot
if message.chat.id != ALLOWED_CHAT_ID:
    return "Acceso denegado"

[Seguridad] Para ngrok

• Implementá autenticación en tu servicio: API key, JWT, OAuth — lo que aplique
• Rate limiting: aunque ngrok no lo provee nativamente, tu servicio debería tener (ej: flask-limiter)
• HTTPS only: ngrok ya lo provee, pero verificá que tu servicio no acepte HTTP plano
• Whitelist de IPs: ngrok permite configurar ip_policy para que solo ciertas IPs consuman tu endpoint
• Logs y monitoring: revisá los logs de ngrok (ngrok.log) para detectar accesos sospechosos
• No expongas servicios innecesarios: si solo necesitás un webhook, exponé solo ese endpoint, no toda la Pi

# ngrok config.yml con autenticación básica
tunnels:
  hubspot-webhook:
    proto: http
    addr: 5000
    auth: "user:strong_password_here"
    ip_policy:
      allow:
        - "54.174.0.0/16"  # rangos de IP de HubSpot

[Seguridad] Principios generales

• Principio de mínimo privilegio: solo exponé lo que necesitás
• Tokens en archivos .env con permisos 600, nunca en el código
• Rotación periódica de tokens y API keys
• Monitoreo activo: alertas cuando algo raro pase
• No uses ngrok gratis para producción crítica: las URLs cambian cada vez que reiniciás. Para producción, usa un dominio custom o soluciones self-hosted

[Tabla] Cuándo usar cada alternativa