itsy, bitsy, editsy

The little CMS that lives in your repo!

editsy turns the TypeScript, JSON, and markdown content files your site already has into an editing UI, with no database, dashboard SaaS, or migration to take on, and every edit lands as a clean git diff.

$ npx editsy editView on GitHub

Your file is the schema

content/home.ts// content/home.ts
export default defineContent({
  hero: {
    heading: "A tidy little website.",
    launched: "2026-07-02",
    cta: {
      label: "View on GitHub",
      href: f.url("…"),
    },
  },
});

Point editsy at the content files you already have. Short strings become text inputs, 2026-10-09 becomes a date picker, arrays of objects become collections. This very page is edited with editsy, and every word here lives in content/home.ts.

  • "short string" text input
  • "2026-07-02" date picker
  • f.markdown() WYSIWYG
  • [{…}, {…}] collection

Inferred fields

The editing form comes from the values already in your file, so there's no schema to author.

Diff before write

Every save shows the exact file change first, applied as an AST rewrite, never regex.

Live preview

See edits on the real site as you type, before anything is saved.

No database

Content is files in your repo, git is the history, and there's nothing to babysit.

Publish = commit

Edits across several files publish as one credited commit and one rebuild.

Editor-friendly

Markdown is WYSIWYG, images get a picker and uploads, dates get a calendar.

Hand over the keys

Add one route and yoursite.com/editsy becomes a login page. Editors sign in with a password or an emailed link, see changes live before saving, and publish. Behind the scenes that's a git commit, and your host redeploys like it would for any push.

app/editsy/[[...editsy]]/route.tsimport { createEditsy } from "@editsy/next";

export const { GET, POST } = createEditsy();

FAQ

Do I have to restructure my site?

No. If your content files export plain objects or arrays, editsy edits them as-is (as const and satisfies included). The defineContent() wrappers are optional and add type-safety when you want it.

Where does my content live?

In your repo, in the TypeScript, JSON, and markdown files you already have. There's no separate content store, so there's nothing to migrate into or out of.

How do non-technical editors log in?

Password or an emailed login link. No GitHub account needed. Editors are a small list in your deployment's environment, with passwords stored as scrypt hashes. No user database.

What about AI agents?

From both directions. Agents that build sites get a conventions doc to follow (editsy init scaffolds an AGENTS.md carrying it), and sites that follow it are editable by construction. Agents that edit content get @editsy/mcp, an MCP server that runs their edits through the same pipeline as the editor: formatting preserved, stale writes refused, and a diff back to review. The AI agents page has both halves.

Why "editsy"?

Itsy, bitsy, editsy. The name comes from a little kitten in my kiddo's favorite cartoon, and I wanted editsy to match: small and cute, like the rest of my favorite things.

When is editsy the wrong choice?

When you need editorial workflow (drafts, approvals, scheduled posts), content shared across many sites, thousands of entries with querying, or a team too big to trust with direct publish access. Those are real CMS jobs, and a real CMS will do them better. editsy is for small sites where the content is the site's copy and the right number of steps between an edit and production is one.

Install it

$ npm install editsy @editsy/next

editsy is MIT licensed, itsy bitsy on purpose, and works on the files you already have; add defineContent() wrappers when you want type-safety and richer fields.