Por qué creamos Osprey, nuestro CMS headless

La mayoría de los CMS headless obligan a elegir: una herramienta con editor visual que trata el esquema como un blob de base de datos generado una vez, o una configuración casera en la que cada carga de página llama en vivo al CMS. Creamos Osprey, nuestro CMS headless, para eliminar esa elección: un esquema de contenido versionado como código y un sitio que se publica como archivos estáticos. Esto es lo que hace realmente el código, no solo lo que dice la presentación.

Los esquemas son código, no un blob de base de datos

En Osprey, una colección se define en TypeScript y vive en el mismo repositorio que el resto de la aplicación. Eso significa el mismo control de versiones, la misma revisión de código y los mismos tipos de extremo a extremo que un equipo ya aplica a su código de aplicación, extendidos al modelo de contenido. La interfaz de administración es una comodidad para editar entradas; nunca es la fuente de verdad del esquema.

El contenido se entrega en tiempo de build, no en cada solicitud

El loader @osprey/astro obtiene las entradas publicadas desde el endpoint REST público de Osprey durante el build y las entrega a las content collections de Astro, sin necesitar una clave de API para esa lectura pública. El sitio publicado es HTML estático puro: Osprey es una dependencia de build, no de runtime. Si un build se ejecuta mientras el CMS está lento o inaccesible, el loader conserva las entradas ya cacheadas en lugar de fallar.

Privado por defecto, invisible cuando se deniega

Una colección solo se expone en la API pública cuando su propia regla access.read admite explícitamente a un llamante anónimo; todo lo demás permanece privado. Una solicitud contra una colección privada, o contra un documento no publicado, responde con un 404 en lugar de un error de permisos, de modo que la API nunca confirma que exista una colección privada.

Los metadatos SEO viajan con cada entrada

Cada entrada que devuelve la API pública lleva un objeto SEO combinado: el título, la descripción, las etiquetas Open Graph y Twitter y la URL canónica propios de la entrada tienen prioridad, y los valores predeterminados del workspace completan lo que falta. El mismo payload incluye la directiva robots resuelta y los enlaces hreflang a cada traducción publicada de esa página, de modo que un frontend puede renderizar sus metaetiquetas sin reconstruir esa lógica.

Un solo despliegue, muchos tenants

Osprey es multi-tenant: un único despliegue puede servir más de un sitio, cada uno delimitado a su propio tenant. En las rutas de contenido público, el tenant del que leer se resuelve a partir de la cabecera host de la propia solicitud y no de una proporcionada por el cliente, de modo que una solicitud anónima no puede leer el contenido de otro tenant enviando un id distinto. Cada consulta a la base de datos que ejecuta la API queda delimitada al tenant internamente, sin depender de que cada handler lo recuerde.

Mecánica de RGPD, no solo una afirmación

Osprey incluye un endpoint de derecho al olvido que redacta datos personales —envíos de formularios, autores del registro de auditoría, cuentas de usuario— para un correo o id dado, delimitado a un tenant. Un endpoint de exportación aparte genera un manifiesto completo del contenido de un tenant para solicitudes de portabilidad de datos. El gestor de consentimiento de cookies integrado trata como siempre activas solo las cookies estrictamente necesarias y pone el resto de categorías en denegado por defecto hasta que el visitante da su consentimiento, con «rechazar todo» con el mismo peso visual que «aceptar todo». Como Osprey es autoalojado, un equipo también puede ejecutarlo íntegramente en infraestructura europea; las garantías dedicadas de residencia de datos en la UE forman parte del plan enterprise del producto, no de cada instalación por defecto.

Headless por diseño

Osprey almacena el contenido y lo sirve como JSON; no tiene opinión sobre el aspecto de un sitio. Un equipo puede construir el frontend en Astro, Next.js o cualquier generador de sitios estáticos que pueda llamar a una API REST, y usar Osprey solo como capa de contenido detrás de él. Los planes actuales, incluidas las versiones autoalojada y enterprise, están en la página del producto Osprey.

Qué hacer

• Define tu modelo de contenido como colecciones de TypeScript y versiónalo junto al código de tu aplicación.
• Establece una regla access.read explícita en cada colección que quieras servir desde la API pública; déjala sin definir para mantenerla privada.
• Añade el loader @osprey/astro, o llama directamente a la API REST, para que el contenido se cargue en tiempo de build y no en cada solicitud.
• Define los campos SEO por entrada solo donde deban diferir de los valores predeterminados del sitio, y deja que estos completen el resto.
• Usa los endpoints integrados de exportación y derecho al olvido para las solicitudes de portabilidad y borrado de datos, en lugar de construir los tuyos.
• Si el alojamiento exclusivamente en la UE importa para tu cumplimiento normativo, aloja Osprey en infraestructura europea o pregunta por las garantías de residencia del plan enterprise.

Fuentes: página del producto Osprey, getosprey.dev.