Moley: el tool que hace que Cloudflare Tunnels sea finalmente usable (y por qué lo necesitábamos) : AntonioCortes.com

El problema que todos tenemos (pero solucionamos mal)

Como DevOps Manager, paso más tiempo del que debería configurando formas para que el equipo pueda mostrar su trabajo en desarrollo. Demos para clientes, webhooks para testing, APIs temporales para integraciones… siempre necesitamos exponer localhost al mundo.

Las opciones tradicionales son un dolor:

ngrok: Funciona, pero URLs feas, límites en el plan gratuito, y cada reinicio genera una URL nueva
localtunnel: Inestable, URLs que expiran, y a menudo bloqueado por firewalls corporativos
SSH tunneling: Requiere servidores propios, configuración manual, y conocimiento de redes
Cloudflare Tunnels manuales: Potente pero… Dios, la configuración manual es infernal

Y entonces descubrí Moley.

Moley: Cloudflare Tunnels sin el sufrimiento

Moley es básicamente “Cloudflare Tunnels for humans”. Toma toda la potencia de los tunnels de Cloudflare (gratis, estables, con tu propio dominio) y elimina toda la fricción de configuración.

# moley.yml - Esto es TODO lo que necesitas configurar
zone: "micdominio.com"
apps:
  - target:
      hostname: "localhost"
      port: 3000
    expose:
      subdomain: "app-dev"
  - target:
      hostname: "localhost" 
      port: 8080
    expose:
      subdomain: "api-staging"

Un comando, múltiples servicios, dominios profesionales:

./moley tunnel run
# ✅ app-dev.micdominio.com → localhost:3000
# ✅ api-staging.micdominio.com → localhost:8080

Y cuando terminas, Ctrl+C y todo se limpia automáticamente. DNS records, tunnel config, certificados… desaparece como si nunca hubiera existido.

¿Qué son Cloudflare Tunnels? (El contexto necesario)

Para entender por qué Moley es brillante, necesitamos entender qué resuelve.

Cloudflare Tunnels es un servicio gratuito que crea conexiones seguras salientes desde tu máquina hacia la red de Cloudflare, sin abrir puertos en tu firewall:

[Tu App Local] ←→ [cloudflared] ←→ [Cloudflare Edge] ←→ [Internet]
     :3000              tunnel              HTTPS            usuarios

Beneficios vs. alternativas:

✅ Gratuito (a diferencia de ngrok Pro)
✅ Tu propio dominio (app.tuempresa.com vs. abc123.ngrok.io)
✅ Estable (misma URL siempre, no expira)
✅ Seguro (HTTPS automático, protección DDoS de Cloudflare)
✅ Sin puertos abiertos (todo saliente, firewall-friendly)
✅ Performance (red global de Cloudflare)

El problema tradicional:

# La forma manual (que nadie quiere hacer)
cloudflared tunnel login
cloudflared tunnel create my-tunnel
cloudflared tunnel route dns my-tunnel app.midominio.com
# Editar config.yml manualmente
# Configurar ingress rules
# Gestionar credentials
# Limpiar después...

Es potente, pero demasiado manual para desarrollo iterativo.

La comparativa que importa

Método	Setup Time	URLs Propias	Persistente	Múltiples Apps	Automático
ngrok	30 seg	❌ (Pro)	❌	❌	✅
localtunnel	15 seg	❌	❌	❌	✅
Cloudflare manual	15 min	✅	✅	✅	❌
Nginx Proxy Manager	30 min	✅	✅	✅	❌
Moley	2 min	✅	✅	✅	✅

Moley es el sweet spot: Toda la potencia de Cloudflare con la simplicidad de ngrok.

Casos de uso reales (desde las trincheras)

1. Demos de cliente con dominio profesional

# En lugar de: "Conectaos a https://f4b2c1d.ngrok.io"
# Ahora: "La demo está en https://demo-cliente.tuempresa.com"

Impacto: Los clientes confían más en URLs profesionales. He visto deals cerrarse más rápido cuando la demo usa el dominio de la empresa.

2. Webhooks para testing

# GitHub webhooks, Stripe webhooks, etc.
apps:
  - target:
      hostname: "localhost"
      port: 4000
    expose:
      subdomain: "webhooks-test"

Ventaja: URL estable que puedes configurar una vez en todos los servicios externos.

3. APIs para integraciones temporales

apps:
  - target:
      hostname: "localhost"
      port: 8080
    expose:
      subdomain: "api-integration-partner-x"

Benefit: El partner puede hacer su integración contra una URL profesional que funciona 24/7.

4. Multiple environments simultáneos

# Un developer trabajando en 3 features paralelas
zone: "dev.miempresa.com"
apps:
  - target:
      port: 3001
    expose:
      subdomain: "feature-auth"
  - target:
      port: 3002  
    expose:
      subdomain: "feature-payments"
  - target:
      port: 3003
    expose:
      subdomain: "feature-dashboard"

5. Colaboración en equipos remotos

# Desarrollador A en Barcelona
moley tunnel run  # → feature-x.dev.empresa.com

# Desarrollador B en México puede acceder inmediatamente
curl https://feature-x.dev.empresa.com/api/status

Implementación práctica: de cero a running

Setup inicial (una vez):

# 1. Instalar cloudflared
brew install cloudflare/cloudflare/cloudflared  # macOS
# Linux: wget + dpkg (ver docs)

# 2. Autenticar con Cloudflare
cloudflared tunnel login

# 3. Instalar Moley
git clone https://github.com/stupside/moley.git
cd moley
make build

# 4. Configurar API token
./moley config --cloudflare.token="tu-api-token"

Uso diario:

# 1. Crear config inicial
./moley tunnel init

# 2. Editar moley.yml según tus servicios
# 3. Ejecutar
./moley tunnel run

Config example para stack típico:

zone: "miempresa.dev"
apps:
  - target:
      hostname: "localhost"
      port: 3000        # React frontend
    expose:
      subdomain: "app"
  - target:
      hostname: "localhost"  
      port: 8080        # API backend
    expose:
      subdomain: "api"
  - target:
      hostname: "localhost"
      port: 5432        # PostgreSQL (TCP tunnel)
    expose:
      subdomain: "db"

Lo que me fascina técnicamente

1. Gestión automática de DNS

Moley usa la API de Cloudflare para crear/eliminar DNS records on-demand:

// Pseudo-código de lo que hace Moley internamente
func createDNSRecord(subdomain, zone string) {
    cloudflare.CreateRecord(DNSRecord{
        Type: "CNAME",
        Name: subdomain + "." + zone,
        Content: tunnelID + ".cfargotunnel.com"
    })
}

No más configuración manual en el dashboard de Cloudflare.

2. Cleanup automático

Cuando haces Ctrl+C, Moley:

✅ Elimina DNS records
✅ Termina el tunnel gracefully
✅ Limpia archivos temporales
✅ Revoca tunnel config

“Leave no trace” - exactamente lo que necesitas en desarrollo.

3. Configuración centralizada y validada

./moley --help
# Validación de config built-in
# Structured logging
# Error handling inteligente

4. Múltiples apps en un tunnel

En lugar de un tunnel por servicio (complejo), Moley configura ingress rules inteligentes:

# Internamente genera:
ingress:
  - hostname: app.miempresa.dev
    service: http://localhost:3000
  - hostname: api.miempresa.dev  
    service: http://localhost:8080
  - service: http_status:404  # catch-all

Casos de uso avanzados con Cloudflare Tunnels

TCP Tunnels para bases de datos

# Exponer PostgreSQL de desarrollo
apps:
  - target:
      hostname: "localhost"
      port: 5432
    expose:
      subdomain: "db-dev"
      # Internamente usa TCP tunneling

Ahora tu partner puede conectarse directamente:

psql -h db-dev.tuempresa.com -U postgres

SSH Tunneling para servidores

apps:
  - target:
      hostname: "localhost"
      port: 22
    expose:
      subdomain: "ssh-server"

Acceso SSH sin abrir puertos:

ssh user@ssh-server.tuempresa.com

RDP para Windows Servers

apps:
  - target:
      hostname: "192.168.1.100" 
      port: 3389
    expose:
      subdomain: "windows-dev"

Monitoring y logging

Todos los tunnels aparecen en el dashboard de Cloudflare con métricas:

✅ Requests per second
✅ Bandwidth usage
✅ Error rates
✅ Geographic distribution

Consideraciones de seguridad (importantes)

Puntos positivos:

✅ Tráfico encriptado (TLS end-to-end)
✅ Sin puertos expuestos (todo outbound)
✅ Cloudflare DDoS protection
✅ Autenticación con tokens (no passwords)

Puntos de atención:

⚠️ Servicios internos accesibles públicamente (configura authentication)
⚠️ API tokens son poderosos (scope minimo necesario)
⚠️ Logs en Cloudflare (data privacy considerations)

Best practices:

# Usa subdominios específicos, no wildcards
subdomain: "feature-123-dev"  # ✅
subdomain: "*"               # ❌

# Limita puertos
port: 3000  # ✅ App específica
port: 22    # ⚠️ Solo si necesitas SSH remoto

Añade autenticación en tu app si expones datos sensibles:

// Middleware de auth simple
app.use((req, res, next) => {
    if (process.env.NODE_ENV === 'tunnel') {
        // Require API key cuando está en tunnel público
        if (!req.headers['x-api-key']) {
            return res.status(401).send('Auth required');
        }
    }
    next();
});

¿Cuándo NO usar Moley/Tunnels?

Production workloads:

Para producción, usa infraestructura dedicated. Tunnels son perfectos para development/staging.

High-bandwidth applications:

Cloudflare tunnels añaden latencia mínima pero perceptible. Para streaming de video o gaming, mejor conexión directa.

Apps que manejan datos súper sensibles:

Si trabajas con PHI, PCI, o datos clasificados, considera si exponer via tunnel público cumple con compliance.

Debugging de network issues:

Tunnels añaden una capa de abstracción. Para debugging de network, a veces necesitas conexión directa.

Mi experiencia práctica

Antes de Moley (pain points):

15 minutos setup manual por cada demo
URLs que expiran en medio de presentaciones
Configurar DNS records manualmente en Cloudflare
Limpiar tunnels viejos a mano

Con Moley (happiness):

2 minutos de moley.yml edit + ./moley tunnel run
URLs estables que funcionan siempre
Cleanup automático
Multiple apps simultáneas sin conflictos

ROI claro: De 15 min → 2 min por deployment. Con 10+ demos al mes, son 2+ horas ahorradas.

Pero más importante: menos fricción = más iteraciones = mejor producto.

Alternativas y competencia

Bore (similar concept):

bore local 3000 --to bore.pub

✅ Simple
❌ URLs públicas, no dominio propio
❌ No persistent

Telebit:

✅ Dominio propio
❌ Configuración más compleja
❌ Menor adoption

Pinggy:

✅ Simple setup
❌ Freemium model
❌ URLs no customizables en free tier

Moley destaca por la combinación: Simplicidad + dominio propio + Cloudflare infrastructure + open source.

El roadmap que me gustaría ver

Features que añadiría:

Templates por stack: moley init --template=next-js
Team sharing: moley share --with=team@empresa.com
Load balancing: Multiple instances del mismo service
Custom headers: Añadir auth headers automáticamente
Integration con CI/CD: Deploy tunnels desde GitHub Actions

Monitoring mejorado:

moley status
# ✅ app.midominio.com → localhost:3000 (healthy)
# ⚠️ api.midominio.com → localhost:8080 (down)

Conclusión: Por qué esto importa

Como alguien que gestiona infrastructure daily, Moley resuelve un problema real que todos tenemos. No es revolutionary technology, es simplemente buena ingeniería: toma algo complejo (Cloudflare Tunnels) y lo hace simple sin sacrificar power.

El valor real no es técnico, es organizacional:

Developers más productivos (menos tiempo en setup)
Demos más profesionales (dominio propio)
Colaboración más fácil (URLs estables)
Menos dependency on DevOps para setups temporales

En un mundo donde el cost of infrastructure está bajando pero el cost of developer time está subiendo, tools como Moley optimizan lo correcto.

¿Vais a probarlo? ¿Qué usáis actualmente para exponer localhost? ¿Os parece que merece la pena el switch desde ngrok?

Mi predicción: Moley es el tipo de tool que se convierte en muscle memory. Una vez que lo pruebas, es difícil volver a configurar tunnels manualmente.

Next step: Download Moley, probarlo en un proyecto real, y ver si os ahorra el tiempo que me ahorra a mí.

PD: Si trabajáis en empresas que frecuentemente hacen demos de desarrollo, Moley puede ser un game-changer. La diferencia entre “conectaos a https://abc123.ngrok.io” y “la demo está en https://demo.vuestra-empresa.com” es… notable.

Moley: el tool que hace que Cloudflare Tunnels sea finalmente usable (y por qué lo necesitábamos)