A browser-based, Git-backed content editor for Astro sites.
Give clients a familiar editing experience for pages, collections, media, translations, custom fields, and MDX — while keeping your content as clean files in your repo. No database. No CMS server. No plugin stack.
A WordPress-style admin that writes Markdown straight into your repo.
No database · No backend · No lock-in
- Drop a folder, start editing
- Custom post types & taxonomies
- Multilingual with translation groups
A real CMS, on a runtime you already trust.
Everything you reach for in WordPress — minus the infrastructure. Built around the browser's native filesystem APIs, so your content stays where it belongs.
Zero backend
PhantomEdit runs entirely in your browser. No server to host, no database to back up, no auth provider to configure.
Your files, your repo
Edits write straight into `.md` / `.mdx` files in your local Astro or Next.js project. Saves are real saves; git is your git.
Familiar admin
A pixel-honest WordPress-style admin with post types, taxonomies, custom fields, media library, and SEO — minus the PHP.
Multilingual out of the box
Per-locale folders, translation groups, RTL support, and route strategies that map cleanly onto Astro & Next i18n.
Privacy by default
Files never leave your machine. The sandbox lives in your browser's encrypted OPFS. There's nothing to log into.
Instant feedback
Open the editor, change a paragraph, hit save — your Astro/Next dev server picks it up the same way you would from VS Code.
Fewer moving parts than the alternatives.
No PHP host. No SaaS dashboard. Just the files your framework already builds from.
PhantomEdit is opinionated for solo developers and small teams building content-driven static sites with git as source of truth.
From repo to publish, in three steps.
Connect a folder
Pick your Astro or Next repo with the File System Access API, or try the browser sandbox if you want to kick the tires first.
Edit like it's 2024
Use the familiar block editor, manage media with folders / tags / categories, set per-post SEO, and translate content side-by-side.
Commit & ship
Saves are plain file changes. Review the diff, commit, push — your CI builds the same way it always did.
Edit in the browser.
Diff in your terminal.
Every action in PhantomEdit maps to a file change you can see, review, and revert. Hit save and the frontmatter on the right gets written verbatim into your repo — ready for git diff and your usual review flow.
- Real saves — gray-matter frontmatter + body, exactly as your build expects it.
- Custom field groups become typed bindings for the SDK.
- Media goes to public/uploads/yyyy/mm — the path your framework already serves.
---
id: 9f8a...
title: Welcome to PhantomEdit
slug: welcome-to-phantomedit
status: publish
date: 2026-05-25T14:00:00.000Z
author: admin
featured_image: /uploads/2026/05/hero.png
terms:
category: [announcements]
post_tag: [launch, local-first]
seo:
title: Welcome to PhantomEdit
description: A local-first headless CMS.
canonical: https://phantomedit.com/welcome
locale: en
---
A WordPress-style admin for your Markdown repo.---
// src/pages/blog/[slug].astro
import { getCollection } from "astro:content";
export async function getStaticPaths() {
const posts = await getCollection("blog");
return posts.map((post) => ({
params: { slug: post.slug },
props: { post },
}));
}
const { post } = Astro.props;
const { Content } = await post.render();
---
<article>
<h1>{post.data.title}</h1>
<p>{post.data.seo?.description}</p>
<Content />
</article>Your framework. Your conventions.
Zero glue code.
PhantomEdit doesn't ship a runtime SDK that owns your data layer. It writes files. You read them with getCollection, fs.readFile, or whatever your framework already gave you.
- Frontmatter shape matches your existing Astro/Next content schema.
- Custom field groups stay strictly typed — no `any` leaking into your templates.
- Want fetch-based access from a Next.js route? An optional SDK is one import away.
Any framework that reads from disk.
Folks who got their content out of a database.
“I deleted my Strapi instance and replaced it with PhantomEdit. My content is back in git where it belongs.”
“Finally — a CMS that doesn't try to own the build pipeline. It just edits the files I already had.”
“WordPress was 90% of the reason my marketing site needed a server. PhantomEdit gave it back to me.”
Questions, answered.
Does PhantomEdit need a server?
No. Everything runs in your browser. The whole admin is a static site, and content edits are written directly to your local repo via the File System Access API — or to an in-browser OPFS sandbox if you just want to try it.
How do you store my content?
Posts are plain `.md` / `.mdx` files with YAML frontmatter, written next to your existing content collections. Media goes into `public/uploads/yyyy/mm`. Everything is just files on disk — exactly what your Astro or Next.js build already expects.
Can I keep using git the way I always have?
Yes — that's the whole point. Every save is a normal file change. Diff it, branch it, review it, revert it. PhantomEdit doesn't fight your workflow, it slots into it.
What about teams?
Today, PhantomEdit is best as a single-author tool that turns your laptop into the CMS. For teams, you collaborate the way devs already do: branches and pull requests. Real-time multiplayer editing is on the roadmap.
Is it open source?
PhantomEdit is built to be open-source friendly. The core admin is MIT-licensed and self-hostable as a static site.
Which browsers are supported?
Any Chromium-based browser (Chrome, Edge, Brave, Arc, Opera) with the File System Access API. Firefox and Safari work for the in-browser sandbox; full disk-write needs a Chromium browser today.
Open the admin. Make an edit. See it in git.
No signup, no install. PhantomEdit boots in the browser sandbox so you can poke around before pointing it at a real folder.