He cerrado el repositorio del blog. Te explico por qué.

Si tenías el repositorio del blog en tus starred de GitHub, habrás notado que ya no puedes acceder. Lo he cerrado. Privado.

No es un descuido. Es una decisión.

Y como no me gusta cerrar cosas sin explicarme, aquí van los tres motivos.

El blog ya no vive en GitHub Pages

Durante años el flujo era el más sencillo del mundo: haces push a la rama correcta, GitHub Pages recoge el commit, genera el sitio y lo despliega. Punto. Para un blog estático con Jekyll era perfecto. No necesitabas nada más.

Pero el blog migró a Astro. Y con Astro vino la decisión de cambiar también el servidor de publicación. Ahora el blog vive en Cloudflare Workers.

El mecanismo es exactamente igual: haces push a master, Cloudflare detecta el cambio y despliega. La diferencia es que Cloudflare Workers puede conectarse a repositorios privados sin ningún problema, a través de su integración oficial con GitHub. No necesitas que el repo sea público para que funcione el deploy. GitHub Pages, en su versión gratuita, te obliga a tener el repositorio público. Cloudflare no pone esa restricción.

Eso era el único motivo por el que el repositorio había sido siempre público, a decir verdad. No porque me apeteciera especialmente abrir el código de un blog personal, sino porque era el precio a pagar por usar GitHub Pages gratis. Con el cambio a Cloudflare, ese precio desaparece.

Pero el cambio de plataforma no es solo una cuestión de dónde alojas el sitio. Cloudflare abre posibilidades que con GitHub Pages simplemente no existen.

Lo que Cloudflare Workers cambia

Cloudflare Workers son funciones JavaScript que se ejecutan en el edge, distribuidas en más de 330 ubicaciones alrededor del mundo. No en un servidor central: literalmente en el nodo más cercano al visitante. La latencia fría es inferior a un milisegundo en la mayoría de los casos porque el runtime de Workers no arranca un proceso nuevo por petición, sino que usa un modelo de isolates de V8, el mismo motor de Chrome.

La diferencia práctica con un sitio puramente estático: puedes ejecutar lógica de servidor real. Procesar formularios sin exponerlos al cliente, llamar a APIs externas con credenciales que nunca salen del Worker, generar respuestas dinámicas en tiempo real, gestionar redirecciones complejas, hacer reescrituras de URL que en un sitio estático requieren configuración de infraestructura.

Ya me peleé con esto migrando marcosramirez.dev de Pages a Workers, y fue más guerra de lo que esperaba: el salto de Cloudflare Pages a Workers con Astro SSR tiene sus particularidades. Pero para el blog, que es estático, la historia es diferente. No necesito SSR. Lo que me interesan son las posibilidades añadidas al stack que ya funciona.

Cloudflare D1 es una base de datos SQL en el edge, integrada directamente con Workers. Ligera, serverless, sin gestión. Para un blog personal hay cosas que tienen sentido guardar en una base de datos: contadores de lectura, un sistema de suscripción a la newsletter, respuestas a formularios de contacto, cualquier cosa que hoy estoy mandando a servicios externos de terceros.

Cloudflare KV es un almacén de clave-valor distribuido y con replicación global. Útil para cachear resultados de APIs, persistir configuración entre Workers, almacenar sesiones.

Email Routing permite recibir correos en tu dominio y procesarlos con Workers. Filtrar, reenviar, responder automáticamente, o lo que sea. Tengo el dominio en Cloudflare de todas formas, así que el coste de activarlo es cero.

AI Gateway es una capa de proxy entre tu aplicación y los proveedores de Inteligencia Artificial. Permite cachear respuestas, ver logs de todas las llamadas, gestionar rate limits y tener un punto único de control para los costes de API. Con la cantidad de automatización que ya hay en el blog, esto empieza a tener sentido.

La gracia de todo esto es que Cloudflare no cobra por la mayoría de estas herramientas hasta que el uso es considerable. El plan gratuito de Workers incluye 100.000 peticiones al día. D1 tiene 5 GB de almacenamiento y 25 millones de filas leídas al día sin coste. KV ofrece 100.000 operaciones de lectura diarias. Para un blog personal con automatización moderada, eso es prácticamente infinito.

Ya hay automatización activa: el sistema de informes de vigilancia semanales de Lucía con la API de Trakt y GitHub Actions lleva funcionando desde mayo. Los detalles técnicos de cómo está montado el blog por dentro dan para otro post. Este es para explicar por qué el repo es privado. Eso es solo el principio de lo que se puede montar encima de esta infraestructura.

Las API keys tienen mala memoria

Cuanto más automatización hay en un repositorio, más credenciales circulan por él.

El blog ya tiene varios flujos con claves: la API de Trakt, tokens de GitHub para que Actions pueda hacer push, claves de acceso a servicios de generación de imágenes. Y eso va a crecer. La Inteligencia Artificial entra más en el flujo editorial, los scripts se multiplican, los workflows de GitHub Actions se vuelven más complejos.

En un repositorio público, un commit descuidado es suficiente para que una API key quede expuesta. Y no hace falta ni que sea un commit que añades tú conscientemente: un archivo de configuración que tiene un valor por defecto con credenciales reales, un script de pruebas que alguien escribió rápido, un .env.example que en algún momento dejó de ser un ejemplo. Hay docenas de formas de meter la pata.

Con el repositorio privado, el riesgo no desaparece, pero la superficie de exposición se reduce radicalmente. Si se cuela una clave, al menos no está indexada por Google ni accesible para cualquiera que pase por el repositorio.

Y que conste que no hablo en abstracto. He visto esto pasar, en proyectos propios y ajenos, más veces de las que me gustaría contar. Un desarrollador con prisa sube un commit de prueba con credenciales reales porque “lo quito luego.” Lo quita, sí, pero el historial de git es permanente, y hay bots que indexan GitHub en tiempo real buscando exactamente eso. En menos de cinco minutos tienes la clave comprometida.

La solución correcta siempre es variables de entorno, secrets de GitHub Actions, y nunca valores reales en el código. Eso lo sé. Lo hago. Pero cuando el repositorio es público hay una presión extra que con el repositorio privado sencillamente no existe.

Es el tipo de cosa que solo te preocupa cuando tienes algo que perder. Y ahora hay suficiente infraestructura como para que valga la pena preocuparse.

Los drafts ya no son públicos

Este es el motivo más sencillo, y el más agradecido.

En el repositorio público, los borradores vivían en una carpeta llamada _drafts. Cualquiera que visitara el repositorio podía ver qué estaba escribiendo, en qué estado estaba, qué ideas tenía a medias. El blog no era solo un sitio web publicado, era también un panel de control del proceso editorial en tiempo real.

Eso tiene algo de interesante, reconozco, pero también tiene algo de incómodo. Los borradores a veces son malos. A veces empiezo algo que no termino. A veces cambio de idea a mitad. A veces hay cosas que prefiero que no se vean hasta que están terminadas.

Ahora los drafts son privados. Solo los veo yo, y el asistente con el que trabajo para editarlos. Nadie más puede saber qué está en el horno antes de que salga.

Si eras de los que miraban la carpeta _drafts para ver qué venía, lo siento. Toca esperar como todo el mundo.

Qué no cambia

El blog sigue funcionando exactamente igual para cualquiera que lo lea.

El deploy es automático. Cuando hago push a master, Cloudflare detecta el cambio y genera el sitio en cuestión de minutos. Los posts se publican solos, los informes de Lucía se generan solos, las imágenes están donde tienen que estar.

No hay ninguna diferencia visible desde fuera. El repositorio cerrado es una decisión de infraestructura, no una decisión sobre el contenido.

Lo único que ya no puedes hacer es curiosear el código del blog, ver cómo está montado, forkear el tema si te gustaba. Si eso te interesaba, lo entiendo. Pero el equilibrio entre apertura y control ha cambiado, y el control gana.

Preguntas frecuentes

¿Puedo seguir leyendo el blog si el repositorio es privado?

Sí. El sitio web sigue siendo completamente público y funciona igual que siempre. Lo único que ha cambiado es el acceso al código fuente del repositorio, no al contenido publicado.

¿Por qué Cloudflare Workers y no GitHub Pages?

Porque Workers permite conectar repositorios privados sin coste, ejecutar lógica de servidor en el edge y apoyarse en herramientas como D1, KV o AI Gateway. GitHub Pages gratuito obliga a tener el repositorio público y no ofrece nada de eso.

¿Es seguro guardar API keys en un repositorio privado?

Más seguro que en uno público, pero no es la solución de fondo. Las credenciales deben ir siempre en variables de entorno o secrets, nunca en el código. El repositorio privado solo reduce la superficie de exposición si algo se cuela por error.

¿Puedo seguir forkeando el tema del blog?

No. Al cerrar el repositorio, el código deja de estar disponible para clonar o forkear. Es la contrapartida de la decisión: se gana control y privacidad a cambio de cerrar el acceso al código.

---

Compártelo si te ha resultado útil.

¿Tú también tienes el código de algo personal abierto por razones históricas más que por convicción? Cuéntame.

Y… a veces cerrar una puerta es la mejor forma de abrir otras.