SonicJS Headless CMS on Cloudflare Workers

SonicJS Content Modeling and API Generation

SonicJS addresses the work involved in connecting a content model to an API and an administrative interface. A developer defines content models in TypeScript, and the project generates the REST API and admin UI. This is useful for teams that want the schema, application code, and administrative surface to remain connected instead of maintaining separate CMS configuration and frontend data contracts. The README describes fields including text, number, date, boolean, select, media, and slug types, which indicates a structured content model rather than an unstructured document store.

The API layer is built on Hono.js and is intended for Cloudflare Workers. The README also lists Drizzle ORM for type-safe database queries. The intended flow is fairly direct: TypeScript definitions describe content, generated routes expose it through an API, and a SQLite-compatible storage layer holds the records. The project also documents a GraphQL endpoint and GraphiQL playground as an opt-in plugin. GraphQL is therefore an additional interface, not the default assumption for every SonicJS application.

For content workflows, the README lists revision history with restore, draft and published states, role-based permissions, scheduling, and automatic saving every 30 seconds. Those features change the operational shape of the CMS. A simple article API is only one part of the system, because editors can also manage drafts, restore older revisions, and publish or unpublish content according to dates. The documentation presents these capabilities as part of the core project and states that they are not placed behind an Enterprise tier under the MIT licensing model.

Cloudflare D1, R2, and the SonicJS Data Path

SonicJS has two deployment contexts, and their storage implications differ. The primary design targets Cloudflare Workers with D1 for SQLite data and R2 for object storage such as media. The README also identifies KV for caching and the Cloudflare Images API for image optimization and transformation. This arrangement keeps the API, relational content data, media storage, and cache services close to the Cloudflare execution model. Adopting SonicJS on Workers is therefore not simply deploying an ordinary Node.js process elsewhere.

The self-hosted route uses SQLite and filesystem storage instead. The Dockerfile identifies the `data/` directory as the location for both the SQLite database and media files, and it requires that directory to be mounted persistently. The documented Docker command maps port 3000 and mounts the current directory under `/app/data`. Losing that mount would remove the application data and media files from the container filesystem, so persistence and backup planning are part of deployment rather than optional operational details.

The README claims that SonicJS provides zero cold starts and 15 to 50ms API responses, but those figures are project claims rather than measurements established elsewhere in the repository documentation. The mechanism behind the edge approach is clear, however: Workers, D1, R2, KV, and Hono are used instead of a conventional long-running application server. Whether those services fit a project depends on its data model, media volume, regional behavior, and operational controls. A self-hosted SonicJS instance should not be assumed to inherit the same Cloudflare deployment characteristics.

Creating a First SonicJS Application

The README distinguishes application development from development of the SonicJS core package. It explicitly says that the repository is for developing the core package, while application developers should create a new project with `create-sonicjs`. The documented first step creates an application directory:

npx create-sonicjs@latest my-app

The quick-start sequence then changes into the generated directory and starts its development command. The README says the generated application is preconfigured with SonicJS CMS, database migrations, example content collections, an admin interface at `/admin`, and a deployment path for Cloudflare.

cd my-app
npm run dev

After starting development, the README directs the developer to `http://localhost:8787`. The next useful check is the admin interface at `/admin`, using the example collection created by the scaffold. This is a real first use because it verifies that the generated application can serve both the API side and the administrative HTML surface. The README does not document first schema-editing commands beyond the generator, so a migration flag or separate initialization command cannot be inferred from it.

Self-Hosting SonicJS with Docker and SQLite

SonicJS can run outside Cloudflare through the documented Docker path. The image builds the core package and the example application into a Node.js 22 Alpine runtime. The README gives a direct build-and-run sequence, including the persistent data mount and two required secrets. The `JWT_SECRET` and `BETTER_AUTH_SECRET` values are generated with `openssl rand -base64 32` in the example, which avoids hard-coding predictable secrets in the command itself.

docker build -t sonicjs .
docker run -d --name sonicjs -p 3000:3000 \
  -v $(pwd)/data:/app/data \
  -e JWT_SECRET=$(openssl rand -base64 32) \
  -e BETTER_AUTH_SECRET=$(openssl rand -base64 32) \
  sonicjs

The README then documents the first-admin reset command. It also shows default credentials for the initial account, so those credentials should be changed after the first login.

docker exec sonicjs npm run reset

The Compose file adds a health check against `http://localhost:3000/api/health`, configures a persistent `sonicjs-data` volume, and requires `JWT_SECRET` and `BETTER_AUTH_SECRET`. Optional settings include `SENDGRID_API_KEY`, `DEFAULT_FROM_EMAIL`, `IMAGES_ACCOUNT_ID`, and `IMAGES_API_TOKEN`. The repository links to a self-hosting guide for Docker Compose, Node.js, backups, and production hardening. Production deployments should consult that guide before exposing the service.

SonicJS Release Status and Upgrade Cost

The repository version is `3.0.0-beta.28`, and the recent release list includes `v3.0.0-beta.27` and `v3.0.0-beta.26`. A beta designation matters for adoption because API and configuration changes remain more plausible than they would be for a mature stable line. The README and repository files do not document a migration policy for every beta release, a long-term-support policy, or a compatibility matrix for existing applications. They also do not provide a detailed rollback procedure.

The repository is not archived, and its last push was on 2026-10-16. That is recent repository activity, but it does not by itself establish that every published API is stable. The root `package.json` is private, while the README points to the `@sonicjs-cms/core` npm package for application use. Upgrades therefore need to account for the relationship between the monorepo, the core package, generated applications, and the example workspace rather than treating the repository as a drop-in application template.

The project uses the MIT license, and the README states that every feature is included without an Enterprise gate. That reduces licensing uncertainty at a high level, although teams still need to review dependencies and operational costs separately. Cloudflare Workers, D1, R2, and related services may carry provider-specific configuration and usage costs. The MIT license does not remove those infrastructure costs or the work of maintaining secrets, backups, migrations, and production upgrades.

Choosing SonicJS Against Strapi or Payload

SonicJS presents itself as a cloud-edge alternative to Strapi and Payload. The architectural difference is the important part: SonicJS is designed around Cloudflare Workers, D1, R2, Hono, and an edge-oriented data path. Strapi and Payload are described in the README as non-edge-native alternatives with Node.js-oriented response and cold-start characteristics. The comparison table gives lower cold-start and API-response figures for SonicJS, but those are README claims and should not be treated as independent measurements for a particular application.

Strapi and Payload remain more directly associated with conventional server deployments and broader choices of hosting and database infrastructure, although the README does not enumerate their full deployment matrix. SonicJS is the narrower option in this comparison because its Cloudflare path is central to its design, while its Docker path gives it a self-hosted SQLite alternative. A team that needs a platform-neutral CMS may find that choosing SonicJS creates a stronger coupling to its supported storage and deployment choices than choosing a conventional CMS would.

SonicJS also includes an AI-oriented surface described in the README: an MCP server with tools for reading, creating, and publishing content, semantic search, and specialized Claude Code agents. These capabilities may reduce custom integration work for teams already using those tools. They are not a substitute for evaluating access control, content validation, deployment security, and the maturity of the beta package.

Editorial conclusion

SonicJS is a reasonable candidate for developers building content APIs on Cloudflare Workers or self-hosting a SQLite-backed service. It is less suitable for teams requiring a stable, long-established release or a deployment model that does not depend on Cloudflare services and filesystem persistence. Verify the exact package version, migration behavior, backup process, authentication configuration, and production deployment path before committing. The project uses the MIT license, is not archived, and had its last push on 2026-10-16.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. SonicJs-Org/sonicjs on GitHub