Standalone backend: Overview
A standalone backend is a repository for one site that you own. It holds an API Worker backed by its own D1 database, an Astro site, the published content, migrations and deployment scripts. The API reads only its own database. Statically built pages need nothing from Dee Wan. Blog routes, site search, Latest entries, visitor comments, forms and the optional preview reach Dee Wan on every request: see What still depends on Dee Wan. This page describes generated source code, not a Cloudflare deployment that has passed acceptance.
The API and the statically built pages are a snapshot. They hold what was published when they were generated, and later publishes reach them only when you regenerate and deploy again. The CMS public API, and the website routes that read it, serve current content.
The generated API enforces declared text length and pattern rules. Changes to these rules require regeneration and redeployment; see the API reference.
You do not need to detach to customize it. See Extending your backend for the owned registry and the connected workflow. The detachment contract describes stopping managed regeneration.
Generate, deliver, deploy
Section titled “Generate, deliver, deploy”These are different steps. Source is generated on your machine. The CMS never compiles it.
| Step | Path | What it does |
|---|---|---|
| Generate standalone backend | npm run backend:generate (below) |
Opens a local CMS SQLite copy read-only, generates and verifies the project against a disposable target database. It does not push or deploy. --model <id> limits it to one model. |
| Generate and deliver for the first time | npm run backend:deliver |
Generates the project locally, delivers it to your repository, and starts the first deployment. --media transfers public media into your storage. |
| Deliver an existing generated commit | npm run wire:github -- --managed (GitHub delivery) |
Pushes a project you already generated, verifies the remote commit, and dispatches deployment of that exact commit. |
| Deploy from an existing repository | Settings → Source & delivery → Deploy | Calls the build webhook. The repository’s own dee-wan-build.yml pulls definitions, runs the regeneration script already committed in that repository, commits, and deploys. Requires a repository that already contains generated source. |
| Hosted source generation | Settings → Source & delivery → Generate source with GitHub | Unavailable. The CMS Worker has no source build runtime and answers source_build_runtime_unavailable. |
npm run backend:generate -- --site <site-id> --source <cms.sqlite> --dest <output-directory> --db <scratch.sqlite>A site with an active managed renderer release also needs --template-artifacts <dir>: a local copy of that release’s template artifacts, with each file at its expected key (managed/<site>/<candidate>/<role>.json), in real directories and regular files. Symbolic links are not followed. Without it, generation refuses with managed_release_custody_unavailable. npm run backend:deliver accepts the same flag. --model output exports no managed renderer, and npm run backend:generate:all cannot pass the flag, so that command refuses generation for these sites.
Each path writes a directory or delivers a Git repository. There is no archive download. npm run backend:deliver uses GitHub device authorization, Cloudflare account credentials and a writer token, verifies the deployment, and offers detachment.
These commands run in the Dee Wan repository. The generated repository has its own commands, listed under Snapshot, migrations, deployment and rollback. GitHub delivery separates the admin GitHub App from command-line device authorization.
Keep connected or detach
Section titled “Keep connected or detach”A connected repository is regenerated through the managed workflow when you request it. dee-wan-build.yml retrieves site definitions with a build token, regenerates, validates, commits, and calls deploy-from-repository.yml for that exact commit. Developers may edit owned/shared files, commit them, and deploy them while connected.
A detached repository stops that managed update relationship. The repository-only workflow deploys committed source without fetching CMS definitions. Detachment does not enable extra extension points. Follow the detachment runbook. Keeping the repository does not by itself mean you store the media files yourself, or that a deployment succeeded.
The site
Section titled “The site”Astro pre-renders page models from generated pages.json and serves them through a site Worker. Hero, rich text, media/text, feature-grid and call-to-action sections use accepted chrome and theme inputs. The repository emits navigation, footer, redirects, robots and an optional sitemap. Statically built pages use the committed page snapshot. Blog routes, search pages and pages with a Latest entries section, a Site search section or visitor comments are served on each request from Dee Wan’s public API (/v1 on the site’s host), so these routes depend on a running Dee Wan installation; the generated API itself does not. See what still depends on Dee Wan and the compatibility flag.
Owned head/body components, layout slots, section wrappers/overrides, Astro integrations, islands and /owned/ pages extend it without detachment. Preview is disabled unless previewApiOrigin is configured. See the page-document contract for the generated page format.
What is not included
Section titled “What is not included”The repository does not reproduce the CMS admin, user system, review workflow, plugin host, imports, AI generation, outgoing webhooks, drafts or history. It does not include media bytes, arbitrary business endpoints, or automatic provisioning for bindings you add yourself. Put your business logic and schema-validated routes in the owned extension files.
Reference and details
Section titled “Reference and details”- API reference: routes, authentication, read tokens, guards, errors, OpenAPI, sign-in for the backend, deployment and rollback.
- Implementation details: files, dependencies, Cloudflare resources, table mappings, the exported managed renderer and the response cache.
- Extending your backend: where your own code goes.
- Detach and verify and standalone recovery.
Next step
Section titled “Next step”Follow the four walkthroughs, starting with edit and publish.
Unreleased / pre-MVP; no stable version
Source revision: fe23db481c422b40e317b92fc98116b4c0c26a87 (modified checkout)
Build date (UTC): 2026-10-18T09:22:34.630Z
Upgrade target: unavailable: modified checkout. Release notes