Después de investigar Sanity como forma de añadir un CMS a una web en Astro, encontré Keystatic. Los dos ofrecen un panel para editar contenido, pero parten de una idea muy distinta sobre dónde debe vivir ese contenido.
Sanity guarda los documentos en su propia plataforma y Astro los consulta. Keystatic se apoya en los archivos del proyecto y en Git. Puede dar a alguien un editor visual sin dejar de guardar Markdown, MDX, JSON o YAML en el repositorio.
Esa diferencia afecta a quién puede editar, cómo se revisan los cambios, qué se despliega y qué problemas aparecen meses después.
Qué es Keystatic
Keystatic es un CMS basado en archivos. En vez de enviar el contenido a una base de datos externa, trabaja con archivos del proyecto. En modo local los guarda directamente en el sistema de archivos. En modo GitHub, los cambios terminan como commits en un repositorio. También tiene un modo Cloud que simplifica la autenticación y puede ampliar la colaboración.
Para un desarrollador, el atractivo es inmediato. El contenido sigue versionado junto al código. Se puede revisar un cambio, volver atrás con Git y generar la web desde los mismos archivos que ya usaba Astro. No hace falta crear una API de contenido ni consultar otra base de datos para mostrar un artículo.
Eso no lo convierte en el CMS apropiado para cualquier cliente. Si se usa el modo GitHub, quien edita necesita acceso de escritura al repositorio. Keystatic Cloud reduce esa fricción, pero ya cambia el modelo y añade otro servicio. Un panel no elimina las decisiones sobre permisos, revisiones y publicación.
La diferencia con Sanity está en dónde vive el contenido
Sanity es un CMS headless. El contenido vive en su Content Lake y Astro lo recupera mediante consultas GROQ. Es una buena opción cuando varias personas necesitan editar desde un panel independiente del repositorio o cuando el contenido va a servir a más de un canal.
Keystatic no parte de una base de datos de contenido. Configuras colecciones y campos, pero el resultado se escribe en archivos. En la práctica, esta es la diferencia que miraría primero:
| Pregunta | Keystatic | Sanity |
|---|---|---|
| ¿Dónde queda el contenido? | En el proyecto o en su repositorio Git. | En la plataforma de Sanity. |
| ¿Cómo llega a Astro? | Astro puede leer los archivos con Content Collections. | Astro consulta documentos con GROQ. |
| ¿Qué deja en el historial? | Cambios de contenido y código en commits. | Cambios dentro del CMS, con sus propios estados y permisos. |
| ¿Qué encaja mejor? | Sitios con flujo Git y contenido relativamente cercano al código. | Equipos editoriales, contenido compartido o una separación clara entre edición y desarrollo. |
No hay una ganadora para todos. Si la prioridad es que el contenido sea un artefacto del repositorio, Keystatic tiene una ventaja clara. Si la prioridad es que un equipo editorial trabaje sin depender de permisos de GitHub ni de la estructura del proyecto, Sanity suele ser más natural.
En el artículo sobre Astro y Sanity explico las decisiones que introduce un CMS desacoplado. Keystatic responde a otra necesidad: conservar el flujo basado en archivos, pero evitar que editar un MDX implique abrir el editor de código.
No lo integraría tal cual en este portfolio
Este sitio parece un caso ideal para Keystatic porque ya guarda los artículos en MDX. Sin embargo, hay un límite real antes de instalar paquetes.
Cada artículo incluye español e inglés en el mismo archivo, dentro de bloques HTML con el atributo lang. El build elimina el bloque que no corresponde a cada ruta antes de publicar. El campo MDX de Keystatic puede leer y escribir MDX, pero su documentación indica que no admite etiquetas HTML dentro de ese contenido.
Por tanto, añadir Keystatic aquí sin cambiar el modelo rompería una convención importante del blog. No bastaría con crear un panel. Tendría que decidir una de estas alternativas:
- Usar archivos separados para español e inglés.
- Sustituir los bloques HTML por una estructura que el editor pueda representar.
- Mantener los artículos bilingües fuera de Keystatic y usarlo solo para otro tipo de contenido.
Ese tipo de comprobación es más importante que la demo inicial. Un CMS tiene que respetar cómo se publica el contenido real, no solo permitir crear una entrada de ejemplo.
Cómo empezaría en un proyecto nuevo
En un proyecto que no tenga esa limitación, comenzaría con una colección pequeña y almacenamiento local. Keystatic ofrece una integración para Astro y una configuración que describe dónde están los archivos y qué campos puede editar una persona.
import { collection, config, fields } from '@keystatic/core'
export default config({
storage: { kind: 'local' },
collections: {
posts: collection({
label: 'Artículos',
slugField: 'title',
path: 'src/content/blog/*',
format: { contentField: 'body' },
schema: {
title: fields.slug({ name: { label: 'Título' } }),
publishedAt: fields.date({ label: 'Fecha' }),
body: fields.mdx({ label: 'Contenido' }),
},
}),
},
})El siguiente paso sería configurar los campos para que coincidan con el esquema de Astro, no inventar dos modelos de contenido independientes. Si Astro exige título, resumen, etiquetas y fecha, Keystatic debe pedir los mismos datos. Así la validación de Content Collections sigue protegiendo el build.
La guía oficial de Keystatic para Astro también requiere sus integraciones de React y Markdoc en el ejemplo base. Si se quiere usar MDX, hay que adaptar la configuración y probar el renderizado con el contenido real. Su integración añade rutas de administración y usa APIs de Node, de modo que para publicar ese panel hace falta un adaptador de Astro y un host que pueda ejecutar código de servidor. Integrarlo cambia cómo se despliega una web que antes era completamente estática.
GitHub no es un detalle de implementación
El modo local resulta cómodo para probar o para una persona que trabaja en el proyecto. Para que alguien edite desde la web publicada, el modo GitHub exige crear y configurar una GitHub App, guardar secretos de entorno y dar acceso al repositorio a los colaboradores.
Eso puede encajar bien en un equipo técnico. Un redactor publica una rama, alguien revisa el cambio y el despliegue sale desde el flujo habitual. Pero no asumiría que una pequeña empresa quiere convertir cada cambio de texto en una operación ligada a GitHub.
Sanity separa mejor esos mundos. El equipo editorial entra en su Studio y el equipo de desarrollo mantiene el frontend. Keystatic mantiene los mundos juntos, lo que puede ser una ventaja o una fuente de fricción según quién use el panel.
Cuándo elegiría cada uno
Elegiría Keystatic cuando el contenido ya vive en archivos, Git es parte normal del trabajo y quiero dar un editor a pocas personas sin abandonar esa trazabilidad. Puede tener mucho sentido para documentación, un blog técnico, una web de producto mantenida por desarrolladores o un equipo que revisa cambios mediante pull requests.
Elegiría Sanity cuando los editores necesitan independencia del repositorio, el modelo de contenido es amplio, habrá varios canales o las previsualizaciones y los borradores son una parte importante del proceso editorial.
Y no añadiría ninguno de los dos a una web que cambia muy poco solo por tener un panel. En ese caso, MDX y Content Collections siguen siendo menos piezas que mantener.
La pregunta útil no es “Keystatic o Sanity”. Es quién va a cambiar el contenido, qué debe poder cambiar y qué prueba debe pasar ese cambio antes de llegar a producción. A partir de ahí, la herramienta deja de ser una tendencia y se convierte en una decisión de mantenimiento.