Cómo sirvo mi web desde casa con una Raspberry Pi 5: Caddy + Cloudflare Tunnel

417 artículos, 58 cron jobs y cero puertos abiertos en el router. La infraestructura completa de La Frontera IA explicada paso a paso, con los errores que me costaron horas de sueño.

⭐ Experiencia real · Publicado el 6 de agosto de 2026 · Tiempo de lectura: 12 min

Esta web que estás leyendo no está en ningún hosting. No hay un VPS en Frankfurt, ni un plan compartido de 4 euros al mes, ni un panel de control con nombre de cohete. Está en una Raspberry Pi 5 que tengo encima de una estantería en mi habitación, al lado de un monitor que casi nunca uso.

Y lo mejor no es eso. Lo mejor es que no hay un solo puerto abierto en mi router. Ninguno. Cero. Si escaneas mi IP pública no vas a encontrar nada que apunte a esta web, porque el tráfico no entra en mi red: mi Pi sale hacia fuera. La diferencia parece un detalle técnico, pero es la razón por la que puedo dormir tranquilo con un servidor de producción dentro de mi casa.

Llevo desde el 19 de julio de 2026 con esta configuración funcionando sin que yo la toque, salvo cuando publico artículos. Hoy hace 17 días que no reinicio la Pi, la CPU está a 49,4 °C sin ventilador agresivo, y la carga media es de 0,10. Te voy a contar exactamente cómo lo monté, qué piezas uso, qué configuración tengo en producción y, sobre todo, qué se me rompió por el camino. Porque los tutoriales que hay por ahí te llevan hasta el "funciona" y luego se despiden. Yo te llevo hasta el "lleva un mes funcionando y ya no pienso en él".

Por qué no uso un hosting (y no es por postureo)

La respuesta corta es el dinero. La larga es que necesitaba ejecutar cosas que un hosting compartido no me deja: scripts de Python que publican artículos solos, un asistente de IA corriendo cron jobs cada pocos minutos, un boletín de correo propio, sincronización de archivos y un segundo cerebro en Obsidian que consulto desde el móvil. Todo eso son procesos vivos, no archivos estáticos.

Un VPS decente para esa carga ronda los 10-20 euros al mes. Son 120-240 euros al año, todos los años. La Raspberry Pi 5 de 8 GB me costó unos 80 euros una sola vez, y con ella también experimento con modelos de IA locales, que es otra de mis obsesiones. Al mes siguiente de comprarla, ya se había pagado sola solo en hosting que no contraté.

Pero hay una objeción legítima: montar un servidor en casa significa que tu web se cae si se va la luz, si tu operadora toca el CGNAT o si tu gato tira la estantería. Por eso la pieza clave del montaje no es la Pi. Es el túnel.

Las tres piezas del montaje

Toda la infraestructura son tres componentes, y cada uno hace una sola cosa:

1. Caddy v2 — mi servidor web. Es el equivalente moderno de Nginx pero con una filosofía que me encaja: HTTPS automático sin configurar nada, una sintaxis legible por humanos y recarga de configuración sin reinicios. Tengo la versión 2.11.4 corriendo como servicio del sistema. Mi Caddyfile tiene 156 líneas y lo entiendo entero, cosa que de mi antigua configuración de Apache no puedo decir.

2. cloudflared — el daemon de Cloudflare Tunnel. Este es el truco de magia. En lugar de abrir los puertos 80 y 443 en el router y apuntarlos a la Pi (lo clásico, lo peligroso), cloudflared establece conexiones de salida desde la Pi hacia la red de Cloudflare. El túnel se mantiene vivo con cuatro conexiones redundantes y, cuando alguien visita lafronteraia.com, Cloudflare enruta la petición por ese túnel hasta mi Caddy local. Sin puertos abiertos, sin IP pública expuesta, y funciona incluso si tu operadora te tiene detrás de CGNAT, como pasa con la mayoría de conexiones de fibra en España.

3. Cloudflare (plan gratuito) — hace de CDN, de terminación TLS y de escudo. Los bots, los intentos de fuerza bruta y el tráfico basura se quedan en su red antes de oler mi router. Yo solo veo el tráfico legítimo.

El dominio lo tengo registrado aparte y el DNS apuntando a Cloudflare, que es un requisito del túnel: el registro CNAME lo gestiona Cloudflare automáticamente cuando creas el túnel desde su panel. Un apunte: esto significa que dependo de Cloudflare. Lo asumí conscientemente y en la sección final te cuento los riesgos que eso implica, sin adornos.

Paso a paso: el montaje completo

Paso 1 — Instalar Caddy en la Raspberry Pi

En Raspberry Pi OS (Debian 12, mi caso), Caddy se instala desde su repositorio oficial:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update && sudo apt install caddy

La primera vez que Caddy sirve algo por el puerto 80 ya funciona. Literalmente. Con estas dos líneas tienes una web servida con HTTPS:

:80 {
    root * /var/www/lafronteraia
    file_server
}

Ese fue mi primer Caddyfile. El actual tiene 12 reglas de proxy inverso y redirección, redirección de www a dominio principal y cabeceras de control de caché, pero empezó exactamente así.

Paso 2 — Crear el túnel en Cloudflare Zero Trust

Aquí hay dos caminos y te recomiendo el panel web, que es el que uso yo:

1. Entras en Cloudflare Zero Trust (zero trust no significa pagar; el túnel es gratuito para uso personal).
2. En Networks → Tunnels creas un túnel con nombre. Cloudflare te genera un token larguísimo.
3. Instalas cloudflared en la Pi con ese token: sudo cloudflared service install <token>. Eso ya registra el servicio de systemd y arranca el daemon.
4. En el panel, sección Public Hostname, mapeas lafronteraia.com hacia #. Cloudflare crea el registro DNS CNAME él solo.

En mi Pi el proceso quedó así (dato real de mis logs, 19 de julio):

/usr/local/bin/cloudflared --no-autoupdate --protocol http2 tunnel run --token eyJ...

El flag --no-autoupdate lo puse yo a mano: no quiero que el daemon se reinicie solo a las 3 de la tarde mientras publico un artículo. Las actualizaciones, cuando yo diga.

Desde ese momento, el túnel registra cuatro conexiones con la red de Cloudflare. En mis logs de esta mañana (6 de agosto de 2026) las cuatro conexiones están repartidas entre centros de datos europeos, la más cercana en Madrid (mad06). Si una se cae, las otras tres siguen sirviendo. Eso es algo que ningún tutorial menciona y que descubrí leyendo logs a las tantas: el túnel no es un hilo, son cuatro hilos redundantes.

Paso 3 — El Caddyfile de producción

Esto es lo que de verdad diferencia un montaje de fin de semana de uno que llevas un mes sin tocar. Mi Caddyfile real, recortado a lo importante:

:80 {
    root * /var/www/lafronteraia
    file_server

    # URLs antiguas → nuevas (301)
    @tcl_old {
        path /articulos/tcl-x11l-review-2026.html
    }
    redir @tcl_old /articulos/tcl-x11l-review-mini-led-2026.html 301

    # www → dominio limpio
    @www { host www.lafronteraia.com }
    redir @www https://lafronteraia.com{uri} 301

    # El HTML nunca se cachea; los assets sí
    @not_asset {
        not path *.css *.js *.jpg *.png *.webp *.svg *.woff *.woff2 *.xml
    }
    header @not_asset {
        Cache-Control "public, max-age=0, must-revalidate"
    }
}

Tres decisiones de las que aprendí a golpe de problema:

La redirección www → apex (añadida por un aviso de Google Search Console): sin ella, Google veía www.lafronteraia.com y lafronteraia.com como dos sitios distintos y me marcaba páginas duplicadas. Una redirección 301 y se acabó.

Las cabeceras de caché (4 de agosto de 2026, hace dos días): los navegadores cacheaban la portada antigua y mis artículos nuevos "no aparecían" para los visitantes. Ahora todo el HTML obliga a revalidar y solo las imágenes y el CSS se cachean de verdad.

Una regla contra bots agresivos que no está en el fragmento de arriba pero sí en el archivo real: bloquea User-Agents que contienen curl/. Si estás probando con curl y te sale un 403, no es un bug: eres tú contra mi regla anti-bots. Añade -H "User-Agent: Mozilla/5.0" y pasa.

Lo que se me rompió (y cómo lo arreglé)

Esta es la parte que ningún tutorial te cuenta. Tres fallos reales de los últimos meses, con fecha:

27 de julio de 2026 — la doble extensión. Tenía una regla de rewrite para servir artículos: /articulos/XXX apuntaba a /data/articles/XXX.html. La regex capturaba con (.+) y, cuando la URL ya llevaba .html, acababa buscando articulo.html.html. Resultado: todos los enlaces de mis secciones, rotos durante horas. El fix fue un carácter y un modificador: (.+?)(?:\.html)?$. Ahora lo valida un script de vigilancia cada 30 minutos para que no vuelva a pasar jamás.

Permisos 403 en artículos nuevos. Caddy corre bajo su propio usuario (caddy) y mis scripts publican como luigy. Cada artículo recién publicado nacía con permisos 600: yo lo veía, el mundo veía un 403. Solución: chmod 644 obligatorio tras cada publicación y un watchdog que repasa todos los archivos cada media hora. Desde que lo monté no he vuelto a ver un 403 en producción.

El túnel no se cae, pero el router sí. Una tarde la web dejó de responder y la Pi estaba perfectamente. Se había reiniciado el router de la operadora y cloudflared tardó en renegociar. La solución no fue ninguna: aprendí que cloudflared reconecta solo, en menos de un minuto, y que lo que parecía una caída era yo mirando una página cacheada. Desde entonces, antes de tocar nada, espero dos minutos y compruebo los logs con journalctl -u cloudflared -f. Me ha ahorrado más de un "arreglo" que en realidad rompía cosas.

Lo que nadie te dijo

Después de casi un mes con esto en producción, esto es lo que no aparece en ninguna guía:

Dependes de Cloudflare, y no solo para lo bueno. Si Cloudflare tiene una incidencia, tu web se cae aunque tu Pi esté perfecta. Ha pasado, pasa y pasará. También significa que tu tráfico pasa por su red: para una web personal es un precio que pago encantado, pero si montas algo con datos sensibles, piénsalo antes.

El túnel añade latencia pequeña, pero real. Cada petición va de tu Pi al edge de Cloudflare y vuelve. En mi caso, con el edge en Madrid, estamos hablando de 10-20 ms. Nadie lo nota en una web de artículos. Lo notarías en una API de alta frecuencia.

Caddy no es el más rápido, y no me importa. Nginx exprimiría mejor cada ciclo de la Pi, y hay quien lo documenta bien. Pero mi web sirve HTML estático a unos pocos cientos de visitantes al día y la Pi va al 1% de CPU. Prefiero una configuración que entiendo a una que exprime.

El silencio absoluto da miedo las primeras semanas. Cuando todo funciona y nadie se queja, una parte de ti está esperando la caída. Monté una comprobación externa (un servicio que hace ping a la web cada 5 minutos y me avisa por Telegram si no responde) y solo entonces dejé de mirar el servidor cinco veces al día.

La electricidad. La Pi 5 consume entre 3 y 6 vatios según la carga. A 0,15 €/kWh, eso son unos 7 euros al año. Comparado con 120-240 euros de VPS, no hay discusión posible. Y eso sin contar que la misma máquina me sirve para los modelos de IA locales, el boletín y la sincronización de archivos: el coste marginal de cada servicio extra es prácticamente cero.

El ancho de banda de subida es tu techo real. En España, la mayoría de conexiones de fibra ofrecen mucha más bajada que subida. Mi túnel no sufre porque el HTML pesa poco y Cloudflare cachea las imágenes, pero si algún día sirvo vídeo pesado desde la Pi, la subida de la fibra será el límite antes que la CPU de la placa. Es un dato que conviene comprobar antes de montar nada: speedtest-cli un sábado por la noche, que es cuando la red está congestionada de verdad, no un martes a las tres de la mañana.

Qué hardware uso exactamente

Por si quieres replicar el montaje, esto es lo que tengo en la estantería (agosto de 2026):

• Raspberry Pi 5 de 8 GB — el servidor. Con 4 GB sobraría para una web, pero los 8 GB los aprovecho para los modelos de IA locales.
• SSD NVMe de 1 TB con el HAT oficial de Raspberry Pi — la microSD la uso solo de arranque; todo el contenido vive en el NVMe. De 75 GB usados de 916 GB, y la diferencia de velocidad con la tarjeta es abismal.
• Disipador con ventilador — la Pi mantiene 49 °C con throttling en 0x0. En verano sin ventilador pasaba de 65 °C y bajaba frecuencias.
• Un SAI barato de segunda mano, porque en esta casa los cortes de luz existen.

Cuándo sí tiene sentido un VPS

No quiero venderte la moto. Hay casos donde la Pi en casa es peor idea que un VPS, y los digo claros: si necesitas disponibilidad del 99,9% con penalizaciones contractuales; si tu web crece a decenas de miles de visitas al día y el ancho de banda de tu fibra se queda corto (recuerda que la subida de las conexiones españolas suele ser muy inferior a la bajada); o si simplemente no quieres mantener nada y prefieres pagar para no pensar. Un VPS de 5 euros cubre esos casos dignamente.

Pero para una web personal, un blog, un proyecto de IA, un home lab con servicios para ti y tu familia: la combinación Pi + Caddy + túnel es más barata, más divertida y, con el túnel bien montado, más segura que abrir puertos como se hacía antes.

El montaje, en una lista

1. Caddy instalado como servicio de systemd, sirviendo el directorio de la web.
2. Túnel creado en el panel de Cloudflare Zero Trust, con su token.
3. cloudflared instalado como servicio con ese token, protocolo http2, sin auto-actualización.
4. Hostname público mapeado a localhost:80, DNS automático.
5. Caddyfile de producción: redirecciones 301, cabeceras de caché, reglas anti-bots.
6. Permisos: todo lo que Caddy lee, en 644, con watchdog de respaldo.
7. Monitorización externa con aviso por Telegram cuando algo no responde.

Todo eso junto me llevó una tarde la primera vez. Hoy, si tuviera que hacerlo desde cero, lo hago en una hora. Los 45 minutos extra que invertí en documentar cada paso fueron los que me permitieron escribir esto sin abrir casi nada.

Si lo montas y te atascas, el 90% de las veces la respuesta está en journalctl -u caddy o journalctl -u cloudflared. El otro 10% son los permisos. Siempre son los permisos.

Y una última cosa que aprendí tarde: documenta mientras montas, no después. Yo recuperé este montaje para escribir este artículo gracias a que anoté cada comando en mi segundo cerebro el mismo día que lo ejecuté. Si no, hoy estaría mirando la Pi con cara de "¿cómo era esto?" y fingiendo que lo tenía todo bajo control. La memoria del sysadmin casero caduca más rápido que un yogur abierto.