Work

Open-source product · Astro integration

CaretCMS

Content editing that fits existing Astro sites instead of forcing them into a new platform or publishing model.

Astro IntegrationTypeScript PackagesCloudflare KV/R2
View live site Source
Caret CMS — the visual editor included with every site
4 packages Core, Cloudflare, CLI, and Zod bridge
3 examples Starter, content-site, and Cloudflare demo
Static + server Works with both delivery models

Build overview

Problem

Adding a CMS to an existing Astro site usually changes more than the editing experience. Developers may have to move content, rewrite templates around a new schema, or switch a static site to server rendering. CaretCMS needed to add visual and structured editing without taking control of the site's architecture.

Implementation

I separated the system into a core Astro integration and optional packages for Cloudflare storage, schema support, and project setup. Existing templates connect to the editor through small `data-caret` attributes, while the CLI handles much of that setup work. Static sites keep their build-and-deploy workflow; server-rendered sites can apply published changes immediately.

Result

The result is one editing system that can be adopted gradually across different Astro projects. Developers keep their components, content structure, and hosting model while gaining inline editing, a structured Studio, and replaceable storage. The tradeoff is that editor bindings must stay in sync as templates evolve, so the CLI and validation layer are part of the product rather than setup extras.

Architecture choices

Alternative Engineering decision Why it matters
  • AlternativeBuild editing separately for every site, which offers total control but repeats authentication, storage, publishing, and admin work.
    Engineering decisionDesigned a reusable Astro integration with a small core and optional packages for storage, schemas, and setup.
    Why it mattersProjects share a tested foundation while only adding the pieces their hosting environment needs.
  • AlternativeRequire server rendering so every edit can appear immediately.
    Engineering decisionAdded separate delivery paths for static and server-rendered sites.
    Why it mattersTeams can choose immediate updates or a simpler static deployment instead of changing architecture just to add editing.
  • AlternativeMove existing content and templates into a CMS-owned schema.
    Engineering decisionConnected rendered content with lightweight attributes and built a CLI to annotate existing components.
    Why it mattersAdoption can happen inside the current codebase, although bindings still need to be maintained when templates change.

Implementation

Astro integration

One integration provides the admin routes, editing runtime, content loading, and publishing behavior needed by the site.

Inline editor and Studio

Supports visual page editing for rendered content plus structured collection editing for repeatable data and shared site settings.

Delivery model flexibility

Static sites apply published edits during a build, while server-rendered sites can show them immediately without maintaining two separate products.

CLI-assisted adoption

The caretize CLI scans an existing project and helps connect templates to the editor, reducing repetitive setup work.