StudioCMS is an SSR (server-side-rendered) headless content management system built natively for the Astro ecosystem, aimed at Astro developers and teams who want to author and manage content for a server-rendered Astro site without leaving Astro's own tooling.

What it is

StudioCMS is a TypeScript project, MIT licensed, developed in the withstudiocms/studiocms repository and published to npm as the studiocms package. It is distributed as a set of Astro integrations rather than as a standalone application: the core integration is studiocms, supported by @studiocms/devapps, with additional capability supplied through plugins such as @studiocms/oauth for authentication, @studiocms/md, @studiocms/mdx, @studiocms/markdoc, @studiocms/html and @studiocms/wysiwyg as renderers, @studiocms/cloudinary-image-service for images and @studiocms/blog as a front-end package. Shared internals live in the @withstudiocms namespace, including @withstudiocms/auth-kit. Project home is studiocms.dev and documentation is hosted at docs.studiocms.dev.

The concrete problem it solves is integration mismatch. An Astro site that needs editable content has traditionally been paired with a general-purpose headless CMS that lives outside the Astro runtime and must be wired in after the fact. StudioCMS replaces that arrangement with an Astro-native CMS that renders on the server, so content management and site rendering share one framework and one deployment. Persistence runs through Kysely, with support for libSQL, MySQL and PostgreSQL, so the content store is a database the operator already controls.

Key capabilities

• SSR Astro integration shipped as the studiocms package on npm, installed alongside the Astro project rather than run as a separate service.
• Pluggable content renderers: @studiocms/md, @studiocms/mdx, @studiocms/markdoc, @studiocms/html and @studiocms/wysiwyg, so authoring format is a per-project choice.
• Authentication through the @studiocms/oauth plugin category, with shared auth internals in @withstudiocms/auth-kit.
• Database access via Kysely, with libSQL, MySQL and PostgreSQL listed as supported engines.
• Image handling through @studiocms/cloudinary-image-service.
• Front-end content delivery through the @studiocms/blog plugin, plus development helpers in @studiocms/devapps.
• Project tooling that includes Biome for formatting, Crowdin for localisation, a continuous release channel on pkg.pr.new, and CI test workflows with a published Allure test report at tests.studiocms.dev.

Who uses it and how

• Astro developers building server-rendered sites who want content editing inside the same framework, installed as an integration in the existing project.
• Teams that need more than one authoring format, mixing a Markdown or MDX renderer for docs with the WYSIWYG renderer for editorial pages.
• Projects that require OAuth-based sign-in for editors, wiring @studiocms/oauth and extending authentication through @withstudiocms/auth-kit.
• Self-hosting teams that want the content store in a database they operate, choosing libSQL, MySQL or PostgreSQL through the Kysely layer.
• Contributors and translators: the repository is tagged hacktoberfest, localisation runs through the StudioCMS Crowdin project, and unreleased builds are available through pkg.pr.new.

Getting started

Install the studiocms package from npm as an Astro integration in an existing Astro project, then follow the setup steps in the StudioCMS documentation at docs.studiocms.dev.

How it compares

No list of paid products that StudioCMS replaces is provided in the facts, and no comparable CMS is named there either. Within this registry, it stands alone: it is the Astro-specific SSR headless CMS entry, distinguished by being built for the Astro ecosystem rather than adapted to it.

When to use it — and when not to

A self-hoster must operate a supported database (libSQL, MySQL or PostgreSQL) and configure the Kysely layer, and must set up authentication through the OAuth plugin before editors can sign in — no hosted option is named in the facts, so the homepage and docs are the only documented starting points. It is a poor fit for anyone who wants a fully managed content backend with nothing to run, or who is not building on Astro. One honest weakness is documentation shape: the repository README excerpt is largely a package and test-coverage table, so the actual installation and configuration instructions live in the external docs site rather than in the repository itself.