Dev tunnel: el sitio en el móvil y desde cualquier red, sin desplegar

Ver el sitio en un móvil de verdad no debería costar un despliegue. Dev tunnel levanta el servidor de desarrollo de Astro escuchando en tu red local y le abre un túnel HTTPS hacia el mismo puerto: devuelve dos enlaces —uno para el móvil que está en tu WiFi, otro para cualquiera que esté fuera— y con ellos miras MarkeUP en el teléfono mientras el contenido sigue sin publicarse. Es la forma de revisar cómo respira una página en pantalla pequeña antes de que exista en internet.

Un comando, dos direcciones y cero despliegues:

npm run dev:tunnel

Mientras esté vivo, lo que ves en el móvil es tu carpeta de trabajo: los cambios que guardas en una nota aparecen al recargar. Nada de eso toca el vault, ni el repositorio, ni el sitio publicado.

Acceso	Quién entra	Qué hace falta
`http://<ip>:<puerto>`	el móvil en la misma WiFi	nada: la IP sale de la interfaz de la red por la que de verdad sales
`https://<algo>.<dominio>`	cualquiera, desde cualquier red	una herramienta de túnel instalada

El enlace de la WiFi es el más directo: mismo router, sin intermediarios. El público lo da el primer túnel disponible de la cadena —cloudflared, ngrok, localhost.run, localtunnel—, y si no hay ninguno utilizable el script lo dice con el comando para instalarlo y deja solo la LAN: nunca inventa una dirección pública.

Tres vías, la que te sea más cómoda. Las tres acaban en el mismo comando.

Cómo	Qué escribes
Hermes (app o Telegram)	`Levántame el server para probarlo en el móvil`
Cline (VS Code)	`Arranca dev:tunnel y mándame los enlaces`
Terminal	`npm run dev:tunnel`

Si quieres los enlaces en el chat en lugar de leerlos de la terminal, pídelo así: arráncalo y mándame los enlaces al Telegram (por debajo, --notify). En el móvil es la forma más cómoda, porque abres la dirección tocándola.

Pídelo (o escribe el comando). Tarda: primero abre el túnel y solo después arranca el servidor, porque el host público es un argumento con el que hay que permitir la entrada.
Lee la salida. Aparecen los dos accesos, el puerto y el comando para parar (las direcciones de abajo son un ejemplo):

🚀 markeup — dev server listo para testear (puerto 4321)

📶 Misma red WiFi (LAN):
http://192.168.1.42:4321

🌍 Desde fuera (localhost.run, HTTPS):
https://abc123def456.lhr.life

Para pararlo: npm run dev:tunnel:stop

Ábrelo en el móvil: el enlace de la WiFi si estás en casa; el del túnel si estás fuera o quieres enseñarlo.
Recarga para ver cambios. Lo que ves es la versión de tu carpeta, con la última nota que guardaste.
Comprueba que sigue vivo cuando dudes: npm run dev:tunnel:status contesta con el estado real de los dos procesos y de las direcciones.
Páralo al terminar: npm run dev:tunnel:stop.

Los dos enlaces sirven lo mismo; cambia a quién alcanzan. Merece la pena elegir con intención:

Situación	Qué abrir
Estás en casa, en tu WiFi	el enlace de LAN: más rápido y sin terceros
Estás fuera de casa (datos móviles)	el enlace del túnel
Quieres enseñarlo a alguien de otra red	el enlace del túnel: no instala nada
Quieres probar los avisos de HTTPS o el audio	el enlace del túnel

Cada proveedor tiene su pega, y conocerla ahorra preguntas: localhost.run cambia de dirección en cada arranque, localtunnel pide la IP pública como contraseña la primera vez y ngrok interpone una página de aviso. Si instalas cloudflared (brew install cloudflared) tienes el camino limpio: HTTPS sin cuenta y sin pantallas intermedias.

Diseño y movimiento. Una animación, un borde o una tipografía se juzgan con el dedo, no con el ratón; lo que en el monitor queda fino, en el móvil puede quedar apretado.
El grafo y los medios. El grafo se comporta distinto en pantalla pequeña, y los reproductores de los medios embebidos solo se prueban de verdad ahí.
Enseñar una versión en curso. El enlace público funciona sin que la otra persona instale nada ni esté en tu red.
Dejar un gate verificable. npm run dev:tunnel:status sale con código 0 solo si el servidor responde de verdad, así que sirve como comprobación automática de una tarea de Hermes.

El servidor y el túnel viven fuera de la terminal: cerrarla no los para. Por eso el script apunta su estado en cada fase, y npm run dev:tunnel:stop los recoge aunque el arranque se hubiera quedado a medias. Repetir el comando con algo levantado es deliberadamente inocuo: vuelve a decirte los enlaces en lugar de reiniciar; para reiniciar de verdad está npm run dev:tunnel -- --restart.

Un detalle de convivencia que conviene saber: mientras el dev server está vivo, el build no limpia su caché de render. Si vas a publicar, páralo antes de construir, o el sitio puede servir una versión con la caché vieja.

Síntoma	Qué hacer
La dirección pública responde 403 con `Blocked request`	el host permitido no era el del túnel: `npm run dev:tunnel -- --restart`
No aparece enlace de túnel	falta una herramienta: `npm run dev:tunnel:setup` te dice cuál y cómo instalarla
Dice «sin IP local» y no hay enlace de LAN	WiFi apagada o solo VPN: usa el enlace del túnel
El enlace de LAN no responde ni desde el propio Mac	cortafuegos de macOS (Ajustes → Red → Cortafuegos); el móvil tampoco entrará
La dirección pública deja de responder	el proveedor rotó el túnel: `npm run dev:tunnel -- --restart` toma la nueva
Quieres solo la WiFi, sin salir a internet	`npm run dev:tunnel -- --tunnel none`

Conviene decirlo para no pedirle lo que no es: no publica (eso es Publicar el sitio), no valida el contenido y no sirve la versión compilada. Si lo que quieres es ver la build que se va a desplegar, se usa npm run preview. El túnel solo levanta el servidor de desarrollo y lo deja a mano.

La ficha de la habilidad que hay detrás: Dev server y túnel.
El uso completo del sistema, en llano: la guía de las skills.
El detalle técnico (proveedores, trampas del 403, ficheros de estado y pruebas): docs/dev-tunnel.md, en el repositorio.

Dev tunnel

Dev tunnel: el sitio en el móvil y desde cualquier red, sin desplegar

Posts que enlazan a este artículo