Cómo convertí mi PC de desarrollo en un servidor público (sin mover 50 GB de datos)

Todo el mundo me decía "sube los datos a un servidor". Lo resolví en 15 minutos, sin mover un solo byte. Te muestro exactamente cómo.

El problema que casi arruina mi demo

Tenía que mostrarle a un cliente —desde su casa, por internet— cuatro aplicaciones empresariales que corren en mi máquina de desarrollo. El detalle: esas apps se alimentan de una base de datos de prueba de más de 50 GB.

Mi primer instinto fue el obvio: "tengo que subir esos 50 GB a un servidor con IP pública para que el cliente los vea". Subir 50 GB por internet toma horas, y el día de la demo eso es una ruleta rusa.

Resulta que ese instinto estaba equivocado. Y la solución correcta tomó quince minutos, no horas.

La idea que lo cambia todo

"Hacer algo visible desde afuera" ≠ "mover los datos a donde está la IP pública".

Son dos cosas distintas y separables. Los datos pueden quedarse exactamente donde están. Lo único que necesita ser alcanzable desde internet es el puerto por donde la aplicación habla HTTP — nada más.

La herramienta que hace justo eso se llama túnel. Y la que usé, gratis y en minutos, es Cloudflare Tunnel.

¿Qué es un túnel, en cristiano?

Normalmente, para que alguien de afuera entre a tu máquina, tendrías que abrir puertos en tu router, exponer tu IP, pelearte con el firewall... un dolor de cabeza (y un riesgo de seguridad).

Un túnel le da la vuelta a todo eso: un pequeño programa en tu máquina (cloudflared) abre una conexión de salida hacia la red de Cloudflare y la mantiene viva. Cuando alguien visita tu dominio, Cloudflare empuja esa petición por el túnel ya abierto hasta tu app. Tu máquina nunca abre un puerto al mundo — es ella la que llama, no al revés. Más simple y más seguro.

El resultado: https://mi-app.midominio.com con candado, apuntando a una app que corre en localhost de mi PC, con sus 50 GB intactos al lado.

Los pasos (lo que de verdad hice)

1. Instalar cloudflared. En Windows, un comando:

winget install Cloudflare.cloudflared

2. Un dominio propio. Aquí aprendí la primera lección: Cloudflare, en su plan gratis, no acepta subdominios sueltos (te pide el dominio completo). Como no quería tocar el DNS de mis sitios de producción, registré un dominio nuevo y baratito directamente dentro de Cloudflare — así nace ya listo, sin configurar nameservers a mano.

3. Autorizar y crear el túnel:

cloudflared tunnel login          # autorizas en el navegador
cloudflared tunnel create monet   # crea el túnel

4. Rutear el dominio al túnel:

cloudflared tunnel route dns monet app.midominio.com

5. Un archivo de configuración que dice qué subdominio va a qué puerto local. Guárdalo en %USERPROFILE%\.cloudflared\config.yml:

tunnel: <id-del-tunel>
ingress:
  - hostname: app.midominio.com
    service: http://127.0.0.1:5001   # 127.0.0.1, NO localhost (el porqué, más abajo)
  - service: http_status:404         # todo lo demás

6. Correrlo:

cloudflared tunnel run monet

Y listo: la app ya estaba en internet, con HTTPS automático. Los 50 GB no se movieron ni un byte.

Que sobreviva a un reinicio (sin depender de mí)

Un túnel abierto a mano se cae cuando reinicias la máquina. Para que arranque solo, lo ideal es instalarlo como servicio de Windows — pero eso pide permisos de administrador. Como no siempre los tienes, hay un truco infalible y sin admin: la carpeta de Inicio de Windows. Cualquier lanzador que dejes ahí corre solo cuando inicias sesión. Un pequeño script arranca las apps y el túnel, y todo revive tras un reinicio sin que toques nada.

Segunda parte: cuando no quieres que ahogue tu máquina (IIS)

Todo lo anterior deja las apps encendidas todo el tiempo. Para una demo de una tarde, perfecto. Pero yo cometí el error de dejar las cuatro apps corriendo en la misma máquina donde trabajo — y la sentí lenta. Cuatro apps + sus APIs = ocho procesos siempre vivos, compitiendo con mi desarrollo.

La pista me la dio una observación: "mi servidor corre 100 aplicaciones y nunca se pone lento; ¿por qué esta máquina con cuatro sí?". La respuesta: ese servidor usa IIS, y IIS apaga las apps que nadie está usando. Lo que no se usa, no consume. Reviven solas en el primer clic.

Así que "subí" la publicación a la Variante B: las mismas apps, el mismo túnel, pero hospedadas dentro de IIS con apagado por inactividad. Y lo bonito: si las montas en los mismos puertos, el túnel no cambia en absoluto. En el Administrador de tareas se ve la magia: de 1.3 GB de RAM permanentes… a casi cero cuando nadie entra. La máquina respira.

Los comandos de IIS, para copiar. Requisito previo (una vez): instala el .NET Hosting Bundle (el que le enseña a IIS a correr apps de ASP.NET Core). Luego, en PowerShell como Administrador, esto crea un App Pool sin código administrado, con apagado a los 20 minutos de inactividad, identidad LocalSystem (sin contraseña) y el sitio en el mismo puerto del túnel:

# 1) App Pool: sin código administrado + apagado por inactividad
New-WebAppPool "MiApp"
Set-ItemProperty IIS:\AppPools\MiApp -Name managedRuntimeVersion     -Value ""
Set-ItemProperty IIS:\AppPools\MiApp -Name startMode                 -Value OnDemand
Set-ItemProperty IIS:\AppPools\MiApp -Name processModel.idleTimeout  -Value "00:20:00"

# 2) Identidad SIN contraseña (0 = LocalSystem)  ->  evita el error 503
Set-ItemProperty IIS:\AppPools\MiApp -Name processModel.identityType -Value 0

# 3) El sitio, en el MISMO puerto del túnel (apunta a la carpeta publicada)
New-Website -Name "MiApp" -Port 5001 -PhysicalPath "C:\publicado\app" -ApplicationPool "MiApp"
Start-WebAppPool "MiApp"

Y en SQL Server, una sola vez, le das acceso a la identidad del pool sobre tu base:

-- El login de la máquina normalmente ya existe; si no:
CREATE LOGIN [NT AUTHORITY\SYSTEM] FROM WINDOWS;

-- Dentro de TU base de datos:
CREATE USER [NT AUTHORITY\SYSTEM] FOR LOGIN [NT AUTHORITY\SYSTEM];
ALTER ROLE db_owner ADD MEMBER [NT AUTHORITY\SYSTEM];

¿Cuál elegir? Para una demo puntual, la Variante A (manual) se monta en minutos y no pide instalar nada. Para una máquina que también usas, o para dejarlo semanas, la Variante B (IIS) es la buena: tu máquina vuelve a ser tuya y las apps reviven solas.

Seguridad: no dejes la puerta abierta

Un túnel expone tu app a todo internet. Dos reglas de oro:

La única letra pequeña honesta

Un túnel hace que la URL sea permanente, pero no puede servir una máquina apagada. Si tu app corre local, tu máquina tiene que estar encendida cuando el cliente entre. Para disponibilidad 24/7 real, eventualmente moverás todo a un servidor siempre encendido — pero para demos, pruebas y desarrollo compartido, esta técnica es oro puro.

Conclusión

No necesitas un servidor caro ni mover montañas de datos para enseñar lo que estás construyendo. Tu propia máquina, un dominio de diez dólares y un túnel gratis te ponen en internet en una tarde. La distancia entre "lo tengo funcionando aquí" y "míralo tú mismo desde tu casa" es mucho más corta de lo que crees.