Markdown, MDX et YAML édités depuis la route /admin
TinaCMS est un CMS headless dont le contenu reste en fichiers : il lit et écrit le Markdown, le MDX, le JSON ou le YAML du dépôt Git du site. Les collections se déclarent dans tina/config.ts, dont Tina tire une API GraphQL et les types TypeScript. L'éditeur s'ouvre sur la route /admin.
En développement, tinacms dev lance ce serveur GraphQL en local et chaque modification s'écrit dans les fichiers du dépôt. En production, il faut un backend qui reçoit les modifications et les commite : TinaCloud, le service hébergé de l'éditeur, ou un backend auto-hébergé.
Strapi et StudioCMS gardent au contraire le contenu dans une base de données. Le comparatif des CMS headless open source détaille le cadre que chacun impose.
Chaque sauvegarde devient un commit Git
- Chaque sauvegarde est un commit : historique, diff et retour en arrière passent par Git. TinaCloud comme le backend auto-hébergé indexent les fichiers dans une base, que la documentation décrit comme « un cache éphémère » : le dépôt reste la source de vérité.
- Des types tirés du schéma : le client GraphQL généré renvoie des données typées, et une requête suit les références entre documents (
post.author.firstName). - Édition visuelle en React et en Astro : les champs se cliquent dans la page rendue, par le hook
useTinaen React ou par le paquet@tinacms/astro, qui se passe de React et, hors pages statiques, sert aux visiteurs le HTML d'un site sans Tina. Astro est le starter que la documentation recommande pour un nouveau projet.
TinaCloud limité à GitHub, auto-hébergement en trois modules
TinaCloud héberge le backend de production, pour GitHub seulement. Il fournit le point d'accès GraphQL, l'index des fichiers, la gestion des utilisateurs et les commits, et selon la FAQ ne s'intègre qu'à GitHub. La formule gratuite couvre deux utilisateurs. Au-delà, chaque projet se paie à l'année : 290 $ pour trois utilisateurs (Team), 490 $ pour cinq (Team Plus), 2 990 $ pour vingt (Business). Le SSO relève de l'offre Enterprise, sur devis.
La relecture par pull request est payante. Avec l'Editorial Workflow, une sauvegarde ne part plus sur la branche protégée : TinaCloud ouvre une branche et une pull request en brouillon. La grille tarifaire le réserve aux formules Team Plus et au-delà.
Se passer de TinaCloud demande trois modules. Le backend auto-hébergé est une fonction API Node.js, à déployer sur un environnement serverless comme Vercel ou Netlify. Elle assemble un fournisseur d'authentification (Auth.js, Clerk ou le sien), un adaptateur de base de données (Vercel KV ou MongoDB, les deux officiels) et un fournisseur Git. Seul celui de GitHub est fourni : pour une autre forge, il faut écrire le sien sur l'interface GitProvider.
L'auto-hébergement perd trois fonctions. La FAQ les nomme : les médias versionnés dans Git, servis par le CDN de TinaCloud ; le changement de branche à la volée, figé au build ; la recherche. Les médias passent alors par un fournisseur externe : le dépôt publie des paquets pour S3, DigitalOcean Spaces, Cloudinary et Azure.
Une v4 se prépare dans le même dépôt. Le README de packages/v4 place la v3 en « support mode », correctifs seulement, et annonce la v4 sous un nouveau nom npm, @tinacms/tinacms, absent du registre au 7 octobre 2026. @tinacms/datalayer y est déprécié : un backend auto-hébergé qui l'appelle directement devra passer à un adaptateur Level (MongoDB, SQLite ou Upstash Redis).
Les ruptures arrivent par les paquets voisins. Le paquet tinacms a publié 39 versions depuis janvier 2026, jusqu'à la 3.14.3 du 7 octobre. @tinacms/cli a sorti deux majeures en moins de trois semaines : la 3.0.0 (14 septembre) change le type des champs de texte riche et casse le code TypeScript qui comptait sur any, la 4.0.0 (1er octobre) retire la migration depuis Forestry.