The editor your Astro schemas already describe.

AstroAdmin reads src/content.config.ts and generates the admin — forms from your Zod schemas, a block editor for discriminated unions, live preview through your own dev server. Saving writes markdown to your repo. Publishing is a git push.

$ cd your-astro-site
$ npx astroadmin dev

what it looks like

A production editing session: the block editor on the left is the form AstroAdmin generated from that site’s hero schema; the preview on the right is the site’s own dev server rendering the edit as it’s typed.

this page is a folder of markdown files

Every section of this page is one markdown file in a public repo — the tag above each heading names it. This one starts:

---
type: section
order: 3
heading: this page is a folder of markdown files
---

The schema in src/content.config.ts declares three section types. AstroAdmin reads that schema and generates a form for each one. Editing this paragraph in AstroAdmin writes this file, reloads the preview, and Publish creates a commit.

There is no database. Remove AstroAdmin and the Astro site still builds, because the build reads the same markdown files through Astro’s own glob() loader.

how it works

• AstroAdmin parses src/content.config.ts with esbuild and converts the Zod schemas to JSON Schema. Forms come from that: a z.enum() renders as a select, image fields get upload controls and alt text, arrays get add, remove, and reorder.
• A discriminated union renders as a block editor — add, reorder, and edit page sections. The schema behind this page is one.
• The preview iframe points at your own Astro dev server, so it renders your components and your CSS.
• Saving writes the markdown or JSON file atomically, in the path your glob() or file() loader reads.
• Publish commits the configured paths and pushes. A build-on-push host (Netlify, Cloudflare Pages, GitHub Pages) rebuilds the site from git, so reverting content is a normal git revert and push.
• No build-on-push host? An rsync deploy adapter builds and deploys from the machine running AstroAdmin instead.
• Auth is one username, an argon2 password hash, server-side sessions, and rate limiting in production. It warns at startup if production is running with the defaults.

what it doesn't do

• It needs a schema. No content collections, no editor — there is a setup guide if your site doesn’t have them yet.
• It runs on Bun, not Node.
• You host it. It’s a server you run next to your site, with one username. Put it behind TLS.
• No roles, no approvals, no draft workflow. The changes panel shows what’s uncommitted; the git history is the editorial record.
• Images land in your repo. No CDN, no transforms.
• Component previews for non-page collections rely on a naming convention ({Type}Block.astro).
• It’s young. The issue tracker is short — nested entry slugs like guides/start are a known gap, for example.

hosted, if you want it

The self-hosted editor is the product. A hosted version — connect a repo, invite your editors, someone else worries about the server — is under consideration. What gets built first depends on who turns up.

Add yourself to the waitlist issue or email james@cloudship.co.uk.