ApostropheCMS + Astro or Standalone Apostrophe: Which is right for you?

The core question

Does your team have a frontend framework they already work in?

If yes — React, Vue, Svelte, Solid, or another — ApostropheCMS + Astro is almost certainly your path. Astro is how you bring that framework to ApostropheCMS. Your frontend developers work in the Astro project using the tools they already know. ApostropheCMS handles content, the admin UI, and the editing experience. The two halves connect through the @apostrophecms/apostrophe-astro bridge.

If no — or if your team wants a single unified environment without a separate frontend layer — Standalone Apostrophe is probably your path. Templates are written in JSX or Nunjucks, live inside the same application as your content model and backend logic, and are discovered automatically by filename. One process, one deployment, no coordination overhead.

Choose ApostropheCMS + Astro when...

Your team has frontend framework preferences. If your developers are already productive in React, Vue, Svelte, or Solid, Astro is how you bring those skills to ApostropheCMS — without being locked into any one of them. Your frontend and backend can be worked on independently, by different people, without stepping on each other.

Performance from static builds matters. Astro's static rendering and partial hydration model means pages can be served as pre-built HTML with JavaScript only where it's needed. For content-heavy marketing sites and high-traffic pages, this is a meaningful difference in load time and infrastructure cost.

You want a clear boundary between CMS and frontend. The Astro path gives frontend developers their own project with familiar component tooling. The CMS handles content, the frontend handles rendering. Neither team needs to be in the other's codebase to do their work.

You're building for production scale from the start. The Astro architecture reflects where the ecosystem is headed and has strong backing — including from Cloudflare. It's the recommended path for new production projects.

Choose Standalone Apostrophe when...

You want one codebase, one server, one deployment. Standalone Apostrophe is a single Node.js application. No coordination between services, no shared keys to manage, no deployment order to worry about. Everything — content, templates, admin UI, routing — runs in one place.

Your team doesn't have strong framework preferences. JSX and Nunjucks are solid, well-understood templating approaches. If your team is comfortable in either, you don't need to introduce a separate frontend framework and application layer to build a great site. And standalone Apostrophe still provides lightweight, performant ways to run frontend JavaScript if needed.

The project is straightforward. A marketing site, a content hub, an internal tool — projects where the editorial team needs a great page-building experience and the development team wants to move quickly without additional infrastructure. Standalone is the lower-complexity choice, and lower complexity is a feature.

You're a solo developer or small team. When one person or a small team owns the full stack, the coordination overhead of two applications isn't worth it. Standalone keeps everything in one place and under one mental model.

Editor experience is the same on both paths

This is worth saying clearly: the visual editing experience — clicking on a page to edit content, adding widgets to an area, previewing changes in context — works on both paths. Editors don't see a different CMS depending on which architecture you chose. The admin UI, content modeling, media management, permissions, and workflow are shared across both.

The difference is where the visitor-facing page is rendered, not how editors interact with their content.

Can you switch paths later?

Yes. If you start on Standalone and later decide to move to Astro, that migration is supported and something we can help with. The content model — your pages, pieces, areas, widgets, and data — carries over because it lives in the database and is defined through ApostropheCMS modules. The migration is primarily a frontend concern: rebuilding your templates as Astro components and setting up the bridge integration.

Starting on Standalone is a reasonable choice if you want to learn the CMS content model before taking on the two-application architecture. You won't lose your content work.

Summary