Exponiendo APIs de Jupyter  Modelos: El flujo de trabajo de ciencia de datos en Python con Pagekite

La ciencia de datos y el desarrollo de aprendizaje automático ocurren principalmente en máquinas locales o estaciones de trabajo con GPU dedicadas. Ya sea que estés iterando en análisis exploratorios dentro de un cuaderno Jupyter, construyendo un prototipo con Streamlit, o sirviendo predicciones mediante FastAPI, tu entorno local es tu taller principal.

Un desafío recurrente surge en el momento en que necesitas compartir ese trabajo. Mostrar un modelo interactivo a un stakeholder remoto, probar un webhook entrante desde una pasarela de pago, o permitir que una app móvil acceda a un endpoint en tu portátil generalmente requiere desplegar en un servidor remoto — y el despliegue en la nube introduce fricciones: sobrecarga de contenedores, costo, retraso en el despliegue y deriva de configuración entre entornos.

Aquí es donde un túnel localhost entra en juego. Mientras ngrok domina en el desarrollo web general, Pagekite es un proyecto mucho más antiguo, aún mantenido, que vale la pena conocer, especialmente porque su cliente de referencia es un script Python simple y ligero en dependencias en lugar de un binario compilado — una propiedad que importa más de lo que parece en entornos regulados o con conciencia de seguridad.

La fricción del desarrollo local en la ciencia de datos moderna

+-----------------------------------------------------------------------+
|                         Estación de trabajo local                     |
|                                                                       |
|  +-------------------+    +--------------------+    +--------------+  |
|  | JupyterLab / Notebook | | Streamlit / Gradio | | FastAPI / ML |  |
|  |   (Puerto 8888)     | |    (Puerto 8501)   | |  (Puerto 8000)|  |
|  +---------+---------+ | +---------+----------+ | +-------+------+  |
|            |             |             |            |             |
+------------+-------------+-------------+------------+-------------+
                                      |
                           ( Bloqueado por NAT / Firewall )
                                      |
                                      x
                          [ Internet público / Clientes ]

Tres cuellos de botella en la compartición aparecen constantemente:

• Demostración de notebooks interactivos. Un archivo .ipynb compartido por email o GitHub solo renderiza salida estática. Dar a un cliente o PM una sesión en vivo e interactiva implica exponer tu servidor Jupyter en ejecución.
• Prueba de webhooks y callbacks externos. Bots de Slack, triggers de GitHub, integraciones con Stripe/Twilio, todos necesitan una URL pública que enrute solicitudes POST entrantes directamente a tu máquina.
• Integración API remota. Los ingenieros frontend que construyen contra un endpoint de modelo alojado localmente necesitan una URL accesible antes de que el modelo esté en staging.

Provisionar manualmente una instancia EC2, crear un túnel SSH inverso a mano, o instalar un binario compilado que active la lista blanca corporativa son fricciones reales que un túnel busca eliminar.

¿Qué es Pagekite? Arquitectura de un túnel en Python

Pagekite es un proyecto de tunneling de código abierto, originalmente escrito por Bjarni Rúnar Einarsson y mantenido por The Beanstalks Project ehf., una empresa islandesa — el proyecto ha estado en marcha desde aproximadamente 2010, siendo uno de los herramientas más antiguos en el espacio de túneles localhost, anterior al lanzamiento público de ngrok. Crea un túnel desde un servidor relay público (un “front-end,” comúnmente alojado en pagekite.net) a un servicio local detrás de NAT o un firewall restrictivo.

                                ARQUITECTURA DE PAGEKITE

 +------------------------+              +------------------------+
 |   Máquina local        |              |  Relay público de Pagekite |
 |                        |              |   (Front-end / Nube)       |
 | +--------------------+ |              |                        |
 | | App local          | |              |                        |
 | | (Jupyter/FastAPI)  | |              |                        |
 | +---------+----------+ |              |                        |
 |           | HTTP local |              |                        |
 | +---------v----------+ |  Encriptado  |                        |
 | | Cliente Pagekite   ||  Túnel       | Front-end receptor |
 | | (pagekite.py)      | |  seguro      |                        |
 | +--------------------+ |              +-----------+------------+
 +------------------------+                          |
                                                     |
                                            +--------v--------+
                                            | Cliente remoto / |
                                            | Navegador web  |
                                            +----------------+

Características arquitectónicas clave

• Cliente de referencia en Python puro. pagekite.py es un script Python simple sin extensiones en C compiladas, Rust o Go necesarias para el rol de back-end/cliente. Nota: si usas tu propio relay front-end en lugar del servicio alojado en pagekite.net, terminar TLS en ese relay requiere OpenSSL y Python 3 moderno o el módulo pyOpenSSL — por lo que “sin dependencias” en realidad significa “sin dependencias para el caso de uso más común del cliente.”
• Python 3 soportado hoy. La página principal de pagekite.net indica cómo instalar con python3 pagekite.py 80 tu-nombre.pagekite.me. Algunas páginas antiguas del wiki aún indican instalar Python 2.x — esa documentación está obsoleta, no indica que la herramienta sea solo Python 2; el soporte para Python 3 llegó en una versión PyPagekite hace años.
• Versatilidad en protocolos. Además de HTTP/HTTPS, Pagekite puede tunelizar TCP en crudo, SSH y otros servicios TCP.
• Auto-hospedaje real y nativo. Puedes usar el relay en pagekite.net, o correr tu propio front-end (pagekitefront) en tu infraestructura — el código del relay es software libre, no una función de pago con licencia.
• DNS dinámico incorporado. El cliente soporta actualización nativa de proveedores DNS dinámicos (dyndns.org, no-ip.com, o un endpoint HTTP(S) personalizado), manteniendo un nombre público apuntando a tu IP actual.
• Un ecosistema más amplio que solo el script Python. Además de pagekite.py, el proyecto mantiene libpagekite, una implementación en C para alto rendimiento o uso embebido, y upagekite, una versión en MicroPython para microcontroladores ESP32 — relevante si tu “servicio local” es más un sensor que un portátil.

Corrección de la licencia: es AGPL, no GPLv2/Apache

pagekite.py se publica bajo la Licencia Pública General Affero GNU (AGPL), con copyright de Bjarni Rúnar Einarsson y The Beanstalks Project ehf. La documentación tiene licencia CC BY-SA 3.0, y los archivos de configuración de ejemplo son dominio público. La licencia dual Apache-2.0-o-AGPL que puedas ver referenciada corresponde a libpagekite, la biblioteca en C — no al cliente Python que usan la mayoría de los desarrolladores. Para revisión de seguridad, esta distinción importa: la cláusula de uso en red de AGPL es más estricta que una licencia permisiva como Apache, y es la que realmente aplica al script en tu máquina.

Ventajas de la pila nativa en Python

Característica	Beneficio para equipos de ML / Datos
Sin runtime compilado para instalar	El cliente es un .py único — colócalo en un venv, una imagen Docker, o junto a tus scripts de entrenamiento sin binario que verificar
Auditabilidad del código	Python en fuente sin compilar permite revisión de InfoSec antes de aprobar el túnel
Integración a nivel de subprocess	Lanzar y gestionar el túnel desde un script de entrenamiento o de servicio usando librerías estándar de procesos en Python
Compatible con entornos virtuales	El script no tiene sistema de empaquetado propio; funciona en cualquier venv/conda con Python 3

Corrección importante: no existe pip install pagekite

El borrador original de este artículo (y otros similares en la web) sugieren pip install pagekite. Hasta ahora, NO existe un paquete pagekite mantenido activamente en PyPI que corresponda a esta herramienta — el nombre más cercano en PyPI es un paquete estático llamado pagekit. La documentación del proyecto siempre indica una de estas rutas:

# Descargar el script directamente (método oficial documentado)
curl -O https://pagekite.net/pk/pagekite.py
chmod +x pagekite.py

# O, en Debian/Ubuntu, vía el repositorio apt del propio proyecto
echo "deb http://pagekite.net/pk/deb/ pagekite main" | sudo tee -a /etc/apt/sources.list
sudo apt-get update && sudo apt-get install pagekite

Debian y Ubuntu también incluyen pagekite en sus repos oficiales (sudo apt install pagekite), aunque el proyecto indica que su repositorio suele tener versiones más recientes que la del paquete de la distro.

Cómo exponer un cuaderno Jupyter con Pagekite

Exponer un entorno interactivo de Jupyter a colaboradores remotos requiere conectividad y control de acceso — una sesión Jupyter sin autenticar con URL pública da a cualquiera que la encuentre derechos de ejecución de código en tu máquina.

                  FLUJO SEGURO PARA TÚNEL JUPYTER

+----------------------+     +----------------------+     +----------------------+
| 1. Configura Pagekite |     | 2. Inicia servidor local|  | 3. Crea Pagekite     |
|    Establece token fuerte | |    Vincula a 127.0.0.1  | |    Túnel cifrado    |
|    o contraseña             | |    Puerto 8888        | |    https://...     |
+----------------------+     +----------------------+ +----------------------+

Paso 1: Obtén el cliente Pagekite

curl -O https://pagekite.net/pk/pagekite.py
chmod +x pagekite.py

Paso 2: Asegura Jupyter antes de tunelizar

jupyter notebook --generate-config
jupyter notebook password

O inicia con un token explícito y solo en loopback:

jupyter lab --ip=127.0.0.1 --port=8888 --NotebookApp.token='un_token_seguro_y_largo_12345'

Paso 3: Inicia el túnel

python3 pagekite.py 8888 mipaginatebook.pagekite.me

La primera vez te guiará para crear una cuenta gratuita (o iniciar sesión), y almacenará una clave de autenticación localmente en ~/.pagekite.rc. Al finalizar verás en la terminal la confirmación de que el puerto local ahora es accesible en https://mipaginatebook.pagekite.me/.

Paso 4: Protege aún más el túnel, correctamente

La versión anterior de esta guía inventó flags como --allow=<ip> y --opt/basicauth=usuario:contraseña. Esos no son flags reales de Pagekite. El mecanismo real y documentado de control de acceso son un par de flags + añadidos a la definición del kite:

# Solo permitir una IP específica (o subred /24)
python3 pagekite.py 8888 mipaginatebook.pagekite.me +ip/203.0.113.45=ok

# Requiere autenticación HTTP Basic además del token de Jupyter
python3 pagekite.py 8888 mipaginatebook.pagekite.me +password/admin=ContraseñaCompleja123!

Se pueden apilar múltiples flags +ip/ o +password/ para permitir varias direcciones o credenciales. Además, pagekite.py incluye desde la versión 0.5 un firewall básico que bloquea rutas comunes de ataque (como /wp-admin/) por defecto; puede desactivarse con --insecure globalmente o +insecure por kite, y se desactiva automáticamente si configuras +password/ o +ip/.

Exponiendo endpoints de modelos en FastAPI y Streamlit

Escenario A: Un dashboard en Streamlit

streamlit run app.py --server.port 8501 --server.address 127.0.0.1

Para forzar HTTPS en el lado público, antepone el protocolo al nombre del kite — no existe una bandera --service=https:

python3 pagekite.py 8501 https:mipaginate.pagekite.me

Escenario B: Un endpoint de inferencia en FastAPI, lanzado programáticamente

En lugar de dos ventanas de terminal, puedes lanzar el túnel como un subprocess junto a tu servidor ASGI:

import subprocess
import time
import uvicorn
from fastapi import FastAPI

app = FastAPI(title="API de inferencia de ML local")

@app.get("/")
def read_root():
    return {"status": "online", "model": "RandomForestClassifier_v2"}

@app.post("/predict")
def predict(features: dict):
    processed_val = sum(features.values()) if features else 0
    return {"prediction": processed_val * 1.5, "confidence": 0.94}

def start_pagekite_tunnel(port: int, subdomain: str):
    """Lanza pagekite.py en segundo plano vinculado al puerto local."""
    cmd = ["python3", "pagekite.py", str(port), f"https:{subdomain}.pagekite.me"]
    print(f"[*] Iniciando túnel Pagekite en puerto {port}...")
    process = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
    time.sleep(2)  # dar tiempo a establecer el túnel
    print(f"[+] Túnel en línea: https://{subdomain}.pagekite.me")
    return process

if __name__ == "__main__":
    PORT = 8000
    SUBDOMAIN = "mi-modelo-ml-api"

    tunnel_process = start_pagekite_tunnel(port=PORT, subdomain=SUBDOMAIN)
    try:
        uvicorn.run(app, host="127.0.0.1", port=PORT)
    finally:
        print("[*] Terminando proceso de Pagekite...")
        tunnel_process.terminate()

Este ejemplo gestiona procesos, no es un SDK oficial — Pagekite no proporciona una librería Python importable aparte del script CLI, así que “integración programática” aquí significa lanzar y supervisar el mismo script que usarías manualmente, no llamar a una API diseñada específicamente.

Pagekite vs ngrok: Comparación para ciencia de datos

Métrica	Pagekite	ngrok
Lenguaje cliente	Python puro (rol cliente)	Go
Licencia cliente	GNU AGPL (pagekite.py); la librería C libpagekite es dual Apache-2.0/AGPL	Cerrada, SaaS
Instalación	curl del script, o paquete apt/rpm — sin paquete PyPI oficial	Binario precompilado
Auto-hospedaje del relay	Nativo — ejecuta tu propio front-end, el código del relay es software libre	No disponible en planes estándar de consumo/equipo
Dominios personalizados	Soporte directo para dominios CNAME; soporte para dominio raíz/apex no claramente documentado	Subdominios CNAME en plan de pago Pay-as-you-go; ngrok indica que dominios raíz no soportados en ningún plan
Protocolos soportados	HTTP, HTTPS, TCP en crudo, SSH	HTTP, HTTPS, TCP, túneles TLS
Modelo de precios	Pago lo que quieras (sugerido $3/mes), tier gratuito para uso no comercial/FOSS, planes de suscripción desde $5.99/mes, bulk de marca blanca desde $199.95/mes hasta 500 dispositivos	Gratuito (limitado), Hobbyist $10/mes ($8/mes anual), planes pagos escalan desde allí

Puntos comparativos que realmente valen

Binario vs. script. ngrok distribuye un binario compilado en Go; Pagekite tiene un script Python inspeccionable. En entornos donde la lista blanca bloquea ejecutables sin firmar, esa diferencia práctica importa.

Auto-hospedaje. Si tus datos incluyen PII o registros regulados de salud/finanzas, la capacidad de Pagekite de correr su relay en tu infraestructura es real y está documentada — no es un añadido de pago, es el mismo código abierto del relay que usa el servicio alojado.

Forma de precios, no solo el costo. Los tiers gratuitos y Hobbyist de ngrok se miden en ancho de banda y número de endpoints. Pagekite tiene un modelo “paga lo que quieras” con un mínimo sugerido, y tiers de suscripción fija mensual en lugar de cargos por GB adicional — una filosofía de precios diferente que vale la pena entender antes de asumir “más barato” o “más caro”.

Mejores prácticas de seguridad para un proxy inverso basado en Pagekite

+-------------------------------------------------------------------+
|                  ESTRATEGIA DE CAPA DE SEGURIDAD DEL TÚNEL        |
|                                                                   |
|  [ Internet público ]                                             |
|         |                                                         |
|         v                                                         |
|  +-------------------------------------------------------------+  |
|  | Capa 1: Encriptación de transporte (prefijo https:)        |  |
|  +------------------------------+------------------------------+  |
|                                 |                                 |
|                                 v                                 |
|  +-------------------------------------------------------------+  |
|  | Capa 2: Control de acceso (+ip/ y +password/ flags)        |  |
|  +------------------------------+------------------------------+  |
|                                 |                                 |
|                                 v                                 |
|  +-------------------------------------------------------------+  |
|  | Capa 3: Autenticación de aplicación (Token Jupyter / API Keys)| |
|  +------------------------------+------------------------------+  |
|                                 |                                 |
|                                 v                                 |
|  [ Aplicación local / Notebook / FastAPI ]                      |

1. Forzar HTTPS. Prefija el nombre del kite: python3 pagekite.py 8888 https:mipaginate.pagekite.me.
2. Restringe por IP donde puedas. +ip/203.0.113.45=ok (una sola dirección) o +ip/203.0.113=ok (subred /24).
3. Agrega autenticación HTTP Basic en el túnel. +password/admin=ContraseñaCompleja123! — útil como segundo factor frente a una app con autenticación débil o nula.
4. Ejecuta el servicio local sin privilegios. Mantén procesos de Jupyter/FastAPI sin privilegios de root, y fuera de directorios con .env o claves SSH — Pagekite reenvía lo que el puerto local sirva, así que la higiene del proceso en local sigue siendo importante.

Manejo de cargas de datos grandes

Si FastAPI devuelve payloads grandes en JSON o imágenes, habilita compresión de respuesta antes de que los datos crucen el túnel:

from fastapi import FastAPI
from fastapi.middleware.gzip import GZipMiddleware

app = FastAPI()

# Nota: es GZipMiddleware, no GzipMiddleware
app.add_middleware(GZipMiddleware, minimum_size=500)

Mantenimiento de túneles persistentes en segundo plano

nohup python3 pagekite.py --logfile=/var/log/pagekite.log 8888 mipaginatebook.pagekite.me &

Para que sobrevivan a reinicios, envuélvelo en una unidad systemd en lugar de solo usar nohup.

Solución de problemas comunes de conexión

Síntoma	Causa probable	Solución
“Conexión rechazada”	El servicio local no escucha en el puerto especificado	Confirma con curl http://127.0.0.1:PORT o netstat antes de culpar al túnel
“Subdominio no disponible”	El name.pagekite.me solicitado ya está en uso	Escoge un prefijo diferente, o verifica que tus credenciales en ~/.pagekite.rc sean correctas
Respuestas lentas	Tamaño de payload o desajuste NAT/MTU	Habilita compresión (ver arriba) o reduce tamaño del payload

Integrando Pagekite en pipelines de MLOps

                        PIPELINE DE INTEGRACIÓN MLOps

 +-------------------+     +--------------------+     +---------------------+
 | Acciones en GitHub / |   | Crear modelo efímero |   | Ejecutar túnel Pagekite |
 | CI local             |--->| en contenedor        |--->| para exponer webhook |
 +-------------------+     +--------------------+     +----------+----------+
                                                                 |
                                                                 v
 +-------------------+     +--------------------+     +---------------------+
 | Destruir túnel     |     | Verificar webhook  |<---| Enviar carga útil  |
 | y reportar resultados | | disparado externamente | | de prueba        |
 +-------------------+     +--------------------+     +---------------------+

En pruebas end-to-end que verifican que un servicio externo puede acceder a un webhook interno, crear un kite de nombre único (test-run-$GITHUB_RUN_ID.pagekite.me) dentro del entorno de prueba, activar la llamada externa, verificar que la carga llegó, y cerrar el túnel evita pagar por un entorno de staging permanente solo para pruebas de webhook.

Más allá del cliente en Python: libpagekite y upagekite

Dos componentes menos conocidos del proyecto Pagekite que valen la pena si tu trabajo va más allá de notebooks y APIs hacia dispositivos embebidos o con recursos limitados:

• libpagekite es una implementación en C del mismo protocolo, pensada para despliegues de alto rendimiento o embebidos donde correr un intérprete Python no es práctico.
• upagekite es una versión en MicroPython para microcontroladores ESP32, permitiendo que un sensor o dispositivo IoT tenga su propio kite sin un sistema operativo completo.

Si ya usas Pagekite para una API de ciencia de datos y luego necesitas extraer telemetría de una placa ESP32, es la misma infraestructura subyacente, no un proveedor diferente.

¿Sigue siendo Pagekite una buena opción en 2026?

Es importante ser honestos, para no vender humo: el blog de pagekite.net no ha publicado actualizaciones públicas desde octubre de 2021, y el repositorio en GitHub del cliente en Python tiene una nota de que “está en desarrollo activo” y “puede ser algo inestable en ocasiones.” Es un ritmo más lento que ngrok o herramientas más nuevas como zrok o Pinggy, que publican cambios regularmente.

Dicho esto, al momento de esta revisión, el servicio principal sigue activo, las descargas y el proceso de registro funcionan, Python 3 está documentado, y las páginas de precios/FAQ están actualizadas — esto parece más un sistema maduro y de bajo cambio, mantenido por un equipo pequeño. Para entornos corporativos que requieren un túnel auditable, auto-hospedado y basado en scripts, esa estabilidad puede ser una buena compensación. Para equipos que necesitan soporte activo, un panel pulido, o lanzamientos frecuentes, las herramientas más nuevas mencionadas en esta serie son una opción más adecuada.

Simplificando la pila de tunneling en Python

Un túnel localhost resuelve un cuello de botella real: conectar desarrollo local con la web pública sin desplegar infraestructura en la nube solo para demostraciones. La propuesta de Pagekite — un cliente basado en scripts, auto-hospedado, con licencia AGPL, respaldado por un operador islandés desde 2010 — es realmente diferente del modelo SaaS cerrado de ngrok, y esa diferencia es real incluso tras corregir las afirmaciones específicas que no se sostenían. La elección correcta depende más de si priorizas auditabilidad y auto-hospedaje o velocidad de características y pulido.

---

Registro de cambios editorial (verificado al 6 de septiembre de 2026)

Correcciones al borrador original:

• Licencia: corregido de “GPLv2/Apache” inventado a la verdadera GNU AGPL bajo la cual se publica pagekite.py (la licencia dual Apache-2.0/AGPL aplica solo a la biblioteca en C, libpagekite, no al cliente Python).
• Instalación: eliminado el comando ficticio pip install pagekite — no hay un paquete PyPI activo para esta herramienta; reemplazado por las rutas de instalación documentadas del proyecto (descarga directa del script con curl, repositorio apt del proyecto, o paquetes de distro).
• Python 2 vs 3: añadido que algunas páginas antiguas del wiki aún indican Python 2.x, pero la página principal y las notas de versión de PyPagekite confirman soporte para Python 3.
• Sintaxis CLI para HTTPS: eliminado el flag inventado --service=https; reemplazado por el prefijo real en el nombre del kite (ejemplo: https:nombre.pagekite.me).
• Sintaxis CLI para seguridad: eliminado el flag inventado --allow=<ip> y --opt/basicauth=usuario:contraseña; reemplazados por los flags documentados +ip/ y +password/, y añadido que desde la versión 0.5 el firewall básico bloquea rutas comunes de ataque, que puede desactivarse con --insecure o +insecure.
• Corrección de código: GzipMiddleware corregido a GZipMiddleware en FastAPI.
• Precios reales: se añadió la estructura de precios de Pagekite: modelo “paga lo que quieras” con mínimo sugerido, suscripciones mensuales, y precios por volumen en bulk, comparando con ngrok.
• Atribución: se nombró a Bjarni Rúnar Einarsson y The Beanstalks Project ehf. (Islandia) como creadores.
• Contexto del ecosistema: se mencionan libpagekite © y upagekite (MicroPython/ESP32).
• Estado de mantenimiento: se advierte que el blog de la compañía está inactivo desde 2021 y que el repositorio advierte posibles inestabilidades, aunque el servicio sigue activo.
• Revisión de soporte de dominios raíz: se corrigió la afirmación de soporte completo a “no claramente documentado” respecto a dominios raíz.
• Meta descripción: se ajustó para ser concisa y natural.

---