I’ve been working on a personal creative writing project all year, and along the way I built a tool for it. I’ve open-sourced it.

It’s called Editorial VCS, and it’s a self-hosted version control system for writing projects. Every save is a full revision with a commit message. Side-by-side diffs. Files move through Draft, Review, and Final independent of their revision history. Projects are siloed, can be tied to a URL, and you can promote a file from one to another without losing its past. If you’re working on fiction, there’s an optional lore bible that catches every mention of a character or place across your files and draws the relationship graph for you.

Plain PHP, MariaDB, Docker compose up and you’re running. MIT license.

Why it exists: I spent this spring running essays through five AI models, each with an assigned editorial role: one for facts, one for structure, one to attack the argument. That produces a lot of revisions, and the question “which pass lost the details I wanted to keep?” turned out to need a real answer. Git is built for code. Nothing I found was built specifically for this.

So the tool built for a project that will never see the light of day ended up separately shepherding ten essays and an eight-story anthology to publication instead.

It’s version one. I had to strip out some internal LAN-based pieces before publishing, so it’s a single commit, no releases, and I haven’t finished testing the clean deploy yet. I wanted it up to share while I polish it. If you write with a pipeline (human or otherwise) I’d like to know whether it fits how you work, and where it doesn’t.

And yes, I wrote it with Claude. Domain expertise did the steering.

Available on GitHub: https://github.com/bcGITster/editorial-vcs