ApostropheCMS: Node.js CMS with In-Context Editing and Headless API

What ApostropheCMS Provides for Content Teams and Developers

ApostropheCMS is a full-stack content management system built with Node.js and MongoDB. It is designed for teams that want content creators to edit directly on the live page rather than in a separate admin dashboard, while developers retain the option to consume the same content through REST APIs in any frontend framework.

The system requirements are Node.js 20.x or later (the repository's package.json sets an engine floor of Node 18, but the documentation lists 20.x as the supported version), MongoDB 6.0 or later, and npm 10.x or later. MongoDB Atlas is the recommended cloud option; local MongoDB installations also work.

The license is MIT, which permits use in both commercial and open-source projects without restrictions on distribution. The project has no GitHub releases listed; versioned packages are available through npm.

In-Context Editing Alongside a Headless REST API

The defining feature of ApostropheCMS is that content creators see the actual live page while editing. Changes appear immediately in place rather than in a separate preview pane. The admin interface is accessible at `/login` after installation.

The headless mode exposes content through a REST API documented at docs.apostrophecms.org/reference/api/pieces.html. The REST API works with React, Vue, Svelte, or any HTTP client. The Astro integration is specifically called out in the README as the easiest path for headless projects: two starter kits exist, one production-ready with a design system (Apollo) and one minimal for custom builds (Essentials). The README states that the Astro integration handles content fetching automatically without requiring the developer to write REST API calls manually.

The two modes are not mutually exclusive. A team can run ApostropheCMS in traditional mode for most of the site and expose selected content types headlessly to an external application.

Installing ApostropheCMS and Running a Local Site

The recommended path is to install the CLI globally and then scaffold a new project:

npm install -g @apostrophecms/cli
apos create my-website
cd my-website
npm run dev

This creates a new project directory, installs dependencies, and starts the development server. The site runs at http://localhost:3000 and the admin interface is at /login.

For a one-off project creation without a global install:

npx @apostrophecms/cli create my-website
cd my-website
npm run dev

Both paths produce the same result. The project uses pnpm as its package manager internally (pnpm 10.18.0 as declared in the root package.json), but the developer-facing install commands use npm.

For headless Astro projects, the README points to the Apollo Starter Kit at apostrophecms.com/starter-kits and the Essentials Starter Kit on GitHub at apostrophecms/starter-kit-astro-essentials. Both provide a pre-wired integration between ApostropheCMS and Astro.

Database Protocols and Monorepo Structure

The repository is organized as a pnpm workspace monorepo. The top-level packages/ directory contains individual packages; the pnpm-workspace.yaml defines the workspace layout. The root package.json orchestrates cross-package commands: `pnpm --recursive run dev` for development and `pnpm --recursive run build` for production builds.

The test suite runs against four database protocols, as shown in the root test script: postgres, mongodb, sqlite, and multipostgres. This means ApostropheCMS supports PostgreSQL and SQLite in addition to MongoDB, a detail not prominently featured in the README's quick start but visible in the test configuration. Teams that cannot run MongoDB in their infrastructure can use PostgreSQL instead.

The `DEVELOPMENT.md` and `MONOREPO.md` files at the repository root document the internal development workflow and monorepo conventions. New contributors are directed to `CONTRIBUTING.md` for the contribution process and to the labeled "good first issue" list on GitHub for starting points.

Limitations and Cases Where ApostropheCMS Is the Wrong Fit

ApostropheCMS requires a running Node.js server; it is not a static site generator. Deployments to static hosting platforms such as GitHub Pages or pure CDN setups require treating ApostropheCMS purely as a headless backend and building the frontend separately, adding architectural complexity.

The MongoDB or PostgreSQL requirement adds operational overhead compared with CMSes that can run on SQLite alone for small deployments. While the test suite covers SQLite, the README's system requirements section lists only MongoDB 6.0+, so teams relying on SQLite in production should verify support through the documentation or community before committing.

The README does not document rollback procedures for content migrations or describe how schema changes are handled across deployed environments. Teams with strict governance requirements around content schema versioning should investigate this before adopting the system.

Pro features (granular permissions, automated translation via DeepL and Google Translate, analytics, multisite management) are behind a paid license. The free open-source core does not include these capabilities.

ApostropheCMS vs. Strapi for Headless Node.js Content Management

Strapi is an open-source headless CMS also built on Node.js. The core difference is that Strapi is headless-first: its editorial interface is a dedicated admin panel that editors use separately from the live site, with no in-context editing capability. ApostropheCMS offers in-context editing as a first-class feature while also supporting headless delivery.

For teams that do not need in-context editing and want a pure API-first architecture, Strapi's model may be simpler to reason about because the editorial interface and the content delivery layer are explicitly separate. For teams where content creators expect to edit on the live page, or for projects that mix traditional and headless delivery, ApostropheCMS's dual-mode approach removes the need to maintain a separate preview environment.

Both tools require Node.js and support multiple databases. The choice comes down to editorial workflow: if the content team works comfortably in a separate admin interface, either tool fits. If in-page editing is a requirement, ApostropheCMS is the narrower fit.

Maintenance Status and Licensing Details

The last push to the repository was on 2026-09-26. The project is actively maintained. The changelog follows the Changesets workflow, and the repository includes a .changeset/ directory for tracking changes across the monorepo packages.

The license is MIT, as stated in the README's License section. MIT permits use, modification, and distribution for both personal and commercial projects without requiring derivative works to be open-source. The README explicitly confirms this scope.

Pro features are available through ApostropheCMS Workspaces, which requires a separate paid license from Apostrophe Inc. The README lists the pro extensions catalog at apostrophecms.com/extensions. Teams evaluating the platform should clearly separate the MIT-licensed open-source core from the pro-tier extensions, since features like automated translation and multisite management are not available in the open-source version.

Editorial conclusion

ApostropheCMS suits JavaScript teams that need in-context editorial workflow and headless API access without splitting into two separate tools. The MIT license and CLI scaffolding lower the adoption bar for new projects. Before committing, confirm that your infrastructure supports MongoDB 6.0+, Node.js 20.x, and npm 10.x, then run the CLI starter kit against a representative content structure to verify the editor experience matches your team's needs.

Frequently asked questions

Official sources

1. apostrophecms/apostrophe on GitHub
2. Issues
3. Project website
4. README