# What AstroCraft is > A git-backed CMS that mounts into an Astro site you already have, reads its field types from your own Zod schema, and commits edits to your own repository. Source: https://editor.astrocraftthemes.com/docs/introduction/ AstroCraft is a CMS for Astro sites that adds no second source of truth. Your content stays as markdown in your repository, its schema stays in `src/content.config.ts`, and the editor **reads** that schema rather than mirroring it. There is no `config.yml` describing fields you already described in Zod, no database, and no API between the editor and your files. That one decision is the product. Decap and Sveltia both make you maintain a parallel description of your content, and the two descriptions drift — a field renamed in Zod keeps rendering the old control until someone notices. Here there is nothing to keep in sync, because `src/admin.config.ts` can only ever _name_ fields that already exist in your schema. It cannot declare one, and it cannot disagree with your schema about a type. ## What it actually is, on disk `src/admin/` is the CMS: thirteen routes, around sixty components, the auth stack, the editing engine and the screen data layer. It mounts into an Astro site as a single integration, injects its own routes under `/admin/`, and guards every one of them server-side. It is a package that happens not to be published — the boundary is asserted on every test run, and it may import exactly seven things outside itself. Everything else in the repository you buy is a working demo site around it — a coffee roastery — so that every screen has real content to render while you decide whether you want it. ## The loop An edit becomes a commit, and that is the whole write path. When you save an entry, an authenticated `editor` posts the changed frontmatter keys and the body to a server action; the action patches the file, writes it, and commits it authored by your own account. Every block you did not touch is re-emitted from its original bytes, so the diff a developer reads contains your edit and nothing else. **Publish** is a separate, admin-only verb. It runs your build command and, only if the build succeeds, pushes the branch. Nothing is ever pushed that did not build. Then it polls your production site until the deployed commit stamp matches what it pushed, and says _"Your changes are live ✓"_ — or an honest sentence that the build is taking longer than usual. Between those two sits a staging branch. A landed commit auto-pushes it, your staging deploy rebuilds with `PREVIEW=1` and shows drafts, and production never does. [Deploying the CMS](/docs/deployment/) is that loop in full. ## What it deliberately does not do There is **no Style panel**. A page is a list of your own section components with the props their authors declared — `variant`, `align`, `spacing` — and never raw CSS, because the output of this editor is a diff in your repository that somebody has to read. Free positioning would emit `` into your source, which is the kind of diff that gets a CMS deleted. The component library lists **your** components. It can only ever name what already exists, discovered by reading the directories you point it at. There is no block library to install and no component of ours to learn. It does not run your site. The CMS is a long-lived Node process with a real checkout of your repository; your published site is your own Astro build, deployed however you already deploy it. The two are connected by a git branch and nothing else, which is why a lapsed licence cannot take a customer's website down — the published site contains no check of any kind. ## What you are getting into Be clear-eyed about the shape of the commitment, because it is unusual for a CMS: - **Your site must render on demand.** `output: 'server'` with an adapter, because middleware only runs at request time for on-demand routes. A statically built admin would ship its HTML — drafts included — straight past the session guard. The build refuses rather than letting that happen. - **You copy source in, you do not install a package.** Three directories are ours and get replaced wholesale on update; two are yours and are never touched again. [Updating](/docs/updating/) is the whole procedure. - **It needs a server and a volume.** One container holding a real clone. That is more infrastructure than a static site, and it is what buys commits authored by real people instead of a bot with a token. ## Where to go next Work through Getting Started in order — [Installation](/docs/installation/), [Mounting](/docs/mounting/), [Configuration](/docs/configuration/), [Your first account](/docs/first-account/) — and you will have a signed-in CMS editing your own content. Everything after that is either a screen you use or a decision you defer. If you would rather see it work before you read anything, clone the template itself and run it: `pnpm install && pnpm dev` gives you the demo roastery with every screen populated.