Why Pluto
Pluto is a CMS that you build from Nuxt layers. In a Nuxt app, it is a first-class part of the app: the site and its admin are one project, with one deploy. With any other framework or stack, Pluto is a headless CMS: it runs the admin and the API, and your site reads the content through the API. You start with Markdown files in Git, with no setup (local Git in development), and add layers when you need more.
The problems it solves
The admin is a second project
Many CMSs run as their own server, or as their own app in another framework. You deploy, update, and secure two things, and the content reaches your site through an API.
In a Nuxt app, Pluto is part of your app. The admin is at /admin, on the same domain, built from the same code. It uses Vue and Nuxt UI, like your site.
Your site does not use Nuxt
The admin and the API of Pluto run in a Nuxt app. Your site does not have to. A site in any framework or language reads the published content through the Public API of Pluto, from the Markdown files in Git, or from the database of a backend layer. See Use Pluto headless.
You need a database before the first post
A blog or a docs site does not need a database. With Pluto, posts and pages are Markdown files in your Git repository, and each save is a commit. It works out of the box with local Git in development. On a deployed site, editors sign in with GitHub. You get the history of git, and no database to run.
When a site needs users, roles, products, or uploads, add a backend layer, such as Supabase. The admin stays the same.
Each feature is a new plugin with its own rules
A Pluto layer adds its features through one function, definePlutoExtension: content types, admin pages, navigation, dashboard widgets, settings, and admin bar buttons. Every layer plugs in the same way. You install only the layers that you use.
Each content type needs a list, a form, and an API
A content type is one typed definition. Pluto makes the list, the form, the API routes, and the capability checks from it. See Content model.
Markdown is hard for some editors
The docs layer edits the pages of a Nuxt Content site with a visual block editor and a live preview. A page that you open and save with no change stays the same, byte for byte. Authors who know Markdown can switch to a Markdown editor at any time.
The setup takes an afternoon
npm create pluto@latest makes the project and installs it. On your machine, you need no account: the dev server signs you in as a local user. After a deploy, the admin creates the GitHub App for you. See Git CMS in 10 minutes.
How it compares
Each tool below is good at what it does. This table shows where Pluto is different. The other tools change often, so check their own docs for details.
| Tool | Where the content lives | Where the admin runs | How a site reads the content |
|---|---|---|---|
| Pluto | Markdown in GitHub, or a database (Supabase today) | In a Nuxt app, at /admin | Nuxt: composables in the same app. Any stack: its public REST API, the files in Git, or the database |
| Nuxt Studio | Markdown in Git | In your Nuxt app | Nuxt Content, in the same app |
| Decap CMS | Markdown in Git | A separate single-page app (React) | The files in Git, with any static site generator |
| TinaCMS | Markdown in Git, through its own data layer | A React app, with Tina Cloud or a self-hosted backend | Its API, from any framework |
| Keystatic | Files in Git or on disk | A React app (Astro, Next.js, and more) | The files, or its reader API |
| Payload | A database (Postgres, MongoDB, and more) | Inside a Next.js app | Its API, from any framework |
| Strapi, Directus | A database | A separate server | Their API, from any framework |
| Sanity | A hosted content store | A React studio | Its API, from any framework |
| WordPress | A MySQL database | A separate PHP server | A PHP theme, or its API |
In short:
- Git-based tools (Nuxt Studio, Decap, Tina, Keystatic) also keep the content in Git. Pluto is a full admin, not only a content editor: it has users, capabilities, settings, a dashboard, and layers for a database when you need one.
- Headless CMSs (Payload, Strapi, Directus, Sanity, WordPress) are strong for large content teams and many front ends. Most of them need a database or a hosted service. Pluto serves other front ends through its API too, and with no database the content stays in Git. In a Nuxt app, you also skip the second project: the admin and the site are one app.
When Pluto is not the right choice
- You cannot run a server. The admin and the API of Pluto need a host with a server runtime, such as Vercel, Netlify, or Node.
- Your front ends need a rich query API, such as GraphQL, or filters and relations across types. With the Git CMS, the public routes of Pluto list the items of a type and get one item. With a backend layer, your site can also query the database directly.
- Your team needs editorial workflows, such as reviews, schedules, and translations of each entry.
These docs run on Pluto
This site is a Nuxt Content site with the docs layer. Each page is a Markdown file in the plutocms/plutocms repository. We edit the pages in the Pluto admin of this site, with the visual block editor. Each save is a commit, and the host deploys the new version. The site uses the hybrid render mode, so a saved page shows at once, before the new build is live.