StudioCMS is an Astro native headless CMS split into plugins

SSR is the design decision, not the admin panel

StudioCMS is described as a dedicated server side rendered headless CMS built for the Astro ecosystem, from the ground up for the Astro community and by Astro community members. The SSR part is the interesting constraint. A headless CMS that renders on the client can be bolted onto anything, and that generality is exactly what StudioCMS gives up. By requiring the rendering to happen on the server, the CMS can deliver an admin experience that writes into the same rendering pipeline the front end uses, and the docs site is the place to learn how to get started. The audience is a team that has already chosen Astro and wants content editing without choosing a different stack for the content, and the homepage is studiocms.dev with the documentation at docs.studiocms.dev.

The monorepo is the architecture, and the plugin list is the product

The README organises the repository into four tables, and reading them tells you what StudioCMS actually is. There are two Astro integrations, studiocms itself and @studiocms/devapps. There are plugins, and they are grouped by category: @studiocms/oauth under Authentication, @studiocms/html, @studiocms/markdoc, @studiocms/md, @studiocms/mdx and @studiocms/wysiwyg under Renderer, @studiocms/cloudinary-image-service under Image Service, and @studiocms/blog under Front-End. Then there are tools and utilities: @withstudiocms/auth-kit, buildkit, component-registry, config-utils, effect, internal_helpers, kysely and template-lang. Every package in the tables carries a codecov coverage badge, which is a small signal about how the project treats regression testing. The important structural point is that the renderers are separate packages. You do not get Markdown and MDX and a WYSIWYG editor by installing one thing.

Six renderers means you choose the authoring format

The renderer plugin list is the most concrete decision a new user makes, and the six options are html, markdoc, md, mdx and wysiwyg, five packages plus the core. They are not variations on a theme. MDX means content files that can import and render React components, Markdown is plain files, Markdoc is the tag based authoring format, HTML is raw markup, and the WYSIWYG plugin is a rich text editor rather than a file format at all. Because these are plugins rather than built in modes, a project that wants a visual editor for non technical authors installs @studiocms/wysiwyg, and a project with a developer audience installs @studiocms/mdx and lets authors write component rich content. The image service plugin, @studiocms/cloudinary-image-service, sits alongside as a separate concern, which tells you media handling is also a choice rather than an assumption.

The playground exists to develop StudioCMS, not to use it

The README is unusually careful about the development playground, and the warning is easy to misread. The StudioCMS Playground is intended for use when developing StudioCMS within the monorepo, and it should not be used to directly test or host StudioCMS. If your goal is to test the CMS, use the latest release from npm instead. The steps for a running playground are listed anyway: clone the repository, run the frozen lockfile install, change dbStartPage in the Node playground's StudioCMS config to true, make sure the .env variables are configured using .env.demo as the example, then run the build for the StudioCMS packages followed by the playground migration, in that order.

pnpm i --frozen-lockfile
pnpm build:studiocms

The build step is described as required to get the current table schema for the StudioCMS integration, which is a fair warning: the playground is a development harness with a moving schema, not a supported deployment.

The tooling bet is on pnpm workspaces, Biome and Vitest

The root package.json describes a pnpm workspace with [email protected] pinned and a Node requirement of >=22.20.0. The scripts show the working rhythm. Linting is biome check . and biome check --write . for the fix, with a Biome badge in the README confirming that choice. Tests are vitest run, wrapped in an Allure clean and serve pair so that the Allure report served at tests.studiocms.dev is generated from the same run. Changesets handle releases, with a status command that diffs against origin/main, and a patched dependency on @changesets/assemble-release-plan under a patches/ directory, which is a normal sign of a project that has needed to adjust a release tool's behaviour. There is also a knip configuration for unused code detection, a cspell dictionary, and a pkg.pr.new badge for continuous releases, so every merge produces a published preview build rather than waiting for a release.

Where a CMS built for one framework is the wrong choice

The limits follow from the framing. If your site is not Astro, StudioCMS does not apply, and there is no generic headless fallback in the package list. The second limit is ecosystem maturity, and the repository is candid about the shape of it: the plugin list is small, six renderer and feature plugins plus one OAuth plugin, and while the internal utilities are extensive, they are internal, so a project needing a capability nobody has packaged yet means writing a plugin against a young API. The third is the pre-1.0 version number. The current release is [email protected], and a 0.x version carries the usual expectation that interfaces can still move between minor releases, so the upgrade cost for a team with a lot of content and custom templates is higher than the version number suggests. The repository also carries AGENTS.md, CLAUDE.md and GEMINI.md at the root, which says the project expects agent authored contributions and therefore expects fast moving interfaces. For a documentation site that ships monthly and has one author, a file based approach is often less work than a CMS.

Editorial conclusion

StudioCMS suits a team already building on Astro that wants an editor and admin surface without giving up server rendered pages, and it suits a content site that needs more than Markdown files with a headless API in front of them. It is the wrong tool for a project on another framework, for a team that needs a mature plugin ecosystem with many third party extensions today, and for a static site that needs no admin interface at all. Before adopting it, read the package list rather than the marketing line, because the renderer plugins are separate packages you install individually, and try the playground first to see the authoring experience before wiring a database. The last push was on 2026-10-20 and the current release is [email protected] from 2026-10-19.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. withstudiocms/studiocms on GitHub