Quería un blog, pero no quería un CMS. No quería aprender otra interfaz, no quería depender de una plataforma externa y tampoco quería que mi contenido viviera separado del resto de mis notas. La solución fue conectar directamente Obsidian con el blog.

Cómo construí mi blog con Next.js y Obsidian

Por qué Obsidian

Ya usaba Obsidian en todos mis dispositivos. Me acomoda escribir en Markdown — si llevas tiempo desarrollando apps, sabes que el formato está en todos lados: READMEs, documentación, comentarios. Escribir así se vuelve natural.

Además, tengo mi vault organizado con la metodología PARA y Zettelkasten, así que era cuestión de crear una carpeta y cualquier .md que ponga ahí se convierte en un post.

Stack tecnológico

• Next.js 15 con App Router
• Tailwind v4 para los estilos
• gray-matter para leer el frontmatter de los .md
• remark/rehype para convertir Markdown a HTML
• Vercel para el despliegue

Sin base de datos, sin CMS, sin nada extra. El contenido son archivos .md planos.

Cómo funciona la sincronización

El vault de Obsidian vive en su propio repo privado en GitHub. El blog lo referencia como un git submodule apuntando a la carpeta que tengo para el blog dentro del vault.

El problema con los submódulos es que el puntero no se actualiza solo — cada vez que agregas un post, tendrías que entrar al repo del blog y actualizarlo manualmente. Para resolver eso, configuré un GitHub Action en el vault.

Cuando hago push al vault con un post nuevo, el Action entra al repo del blog, actualiza el submódulo al commit más reciente y hace push. Vercel detecta el cambio y redespliega automáticamente.

El flujo completo

1. Escribo un .md en Obsidian con el frontmatter correcto
2. Obsidian Git hace push al vault en GitHub
3. El GitHub Action detecta el push y actualiza el submódulo en el repo del blog
4. Vercel detecta el nuevo commit y redespliega

Desde que termino de escribir hasta que el post aparece publicado, no tengo que tocar nada más. El contenido fluye solo.

Lo que habría hecho diferente

El submódulo funciona bien, pero tiene sus fricciones. Si empezara de cero, evaluaría usar la API de GitHub directamente desde el Action para leer los archivos del vault privado, en lugar de manejar permisos de submódulo entre repos. Más simple de mantener a largo plazo.

Si te interesa el detalle de la automatización, en este post explico el GitHub Action paso a paso. Y si querés ver cómo organizo el contenido antes de publicarlo, escribí sobre mi sistema PKM con Zettelkasten y PARA.