[Feature Request] Add Open Authoring Support with GitHub Fork + PR Workflow (Like DecapCMS)

[SultanZain]

Hi Keystatic team! 👋

First off, thank you for building such a modern, thoughtful CMS. The GitHub-backed approach is awesome for developer workflows and content versioning.

However, one major feature currently missing — and very useful for community-driven projects — is Open Authoring, like what [DecapCMS](https://decapcms.org/docs/open-authoring/) supports.

---

💡 What is Open Authoring?

Open authoring allows contributors who aren’t collaborators on a GitHub repository to:

• Authenticate via GitHub
• Automatically fork the repo to their own account
• Create a branch and edit content in the CMS UI
• Submit a Pull Request back to the main repo
• All without using Git or needing write access

This enables non-technical contributors (like writers, translators, editors) to easily contribute through a visual interface, while maintaining version control and review workflows.

---

🎯 Why This Is Important

For open-source or community knowledge bases (e.g. multilingual projects, documentation, religious or educational content), open authoring is a game-changer. Contributors can submit translations or updates without technical friction.

We’d love to use Keystatic for such a project, but this feature is a blocker. Otherwise, we’d need to keep using DecapCMS for now just to enable this flow.

---

✅ Suggested Features

• Auto-fork GitHub repo if the user is not a collaborator
• Let users edit content via Keystatic UI on a new branch
• Submit a PR to the original repo
• Optional: Approvals from maintainers, notifications, etc.

---

📦 Example Use Cases

• Open documentation sites
• Multilingual content contributions
• Public religious/educational repositories (e.g. Seerah content, where anyone can contribute translation or lessons)

---

🙏 Thank you!

Keystatic is amazing already. This one feature would make it perfect for many community-first projects.

Looking forward to your thoughts!

[Greenheart]

This would be very useful, especially for open source projects where anyone could contribute content or documentation.

To learn from the work that went into Netlify/Decap CMS and others, it's important to plan for multiple Git providers from the start.

By implenenting Open Authoring with a plugin-based architecture, it would be easier to support multiple Git providers, and allow the community to help maintain plugins without having to learn the entire Keystatic codebase.

Take a look at how Sveltia CMS has implemented this: https://github.com/sveltia/sveltia-cms/tree/ed125ae20680d319faf5d9d9351e4b3db9e2a6e4/src/lib/services/backends/git

Another idea for the implementation is to make the Open Authoring logic decoupled from the Keystatic UI, to allow them to evolve independently. One challenge with Netlify/Decap was that it started with one provider and gradually added partial support for more. However the CMS was shaped by the first Git provider and that made maintenance quite hard.

[nimble-turtle]

I dug into the codebase and it turns out that Keystatic actually already supports this, but only slightly.

What works now

• You can add the keystatic github app to fork
• You can create branches (though it is a bit buggy)
• When you click the button to create a pull request (in keystatic) it properly makes the pull request to the upstream repo

What would make it a lot better

• Smoother onboarding flow to create the fork and install the app in one sequence.
• Display the name of the fork/repo you're on in the admin.
• The "changes" icons that show up throughout the keystatic admin UI should show up even if you're on the main branch.
• Similarly, the "create a pull request" button should show up even if you're only on the main branch on a forked repo.
• Preview URLs should support specifying the repo, not just the branch (I found a workaround, but it would be nice if support was native)

I'm willing to work on a PR for this if the team is interested.

[nimble-turtle]

How it's going on my deployment

I successfully implemented fork-aware preview URLs with the code in this pull request on my repo: https://github.com/ActivistChecklist/ActivistChecklist/pull/258/changes.

The preview URLs dynamically pull from the fork repo and branch rather than from the source repo, which is pretty cool. The fork name gets stored in a cookie so that the preview can pull it from the correct github repo.

The order of steps is:

1. Fork the repo: https://github.com/ActivistChecklist/ActivistChecklist/fork
2. Install the app (which also serves as oauth): https://github.com/apps/activistchecklist-keystatic/installations/new?state=close
3. Visit the admin: https://activistchecklist.up.railway.app/keystatic/
4. Make a branch
5. Make edits
6. Click the preview button to see changes (optional)

Here's what my top bar looks like when on the source repo.

Here's what my top bar looks like when on the forked repo. (see repo name at the top)