In 2023, the CMS running more than 100 of our themes announced it was shutting down. We had no plan B. Back in 2018, we adopted a tool called Forestry, a Git-based CMS that had quietly become the backbone of how our non-technical customers edited their sites. When it announced it was shutting down, we went into a panic. It was the solution to one of the most common problems we heard: “How do I edit content on this theme without touching code?” Now we didn’t have that. So our team at Zeon Studio built one ourselves, and called it Sitepins.

This case study explores how a CMS shutdown and the lack of viable alternatives led to the development of Sitepins, and why we decided to make it open source.

Where This Started

Back in 2018, Zeon Studio, the people behind Themefisher, Gethugothemes, were early adopters of the Jamstack approach, building sites with Hugo and Bootstrap well before it became a mainstream pattern. The missing piece was always the same: how do you let a non-technical client edit a statically generated site without asking them to touch Markdown files or a Git client? Forestry solved that. It gave our customers a visual editing layer on top of Git-based sites, and it worked well enough that a tutorial video we made on using it picked up more than 63,000 views on YouTube. That number acted as a proof: this wasn’t a niche need. A lot of people were building the same way we were, and facing the same issues.

The Problem: No Replacement Fit

When the shutdown was announced in 2023, the impact hit hard. We had well over 100 themes depending on that CMS, customers actively using it, and no replacement lined up. Every other option we looked at just didn’t fit.Their own successor product, TinaCMS, turned out to be built for enterprise clients, and it didn’t integrate cleanly with what we already had. CloudCannon was fully commercial, priced out of reach for a lot of our customer base, and incompatible with our themes without significant rework. Decap CMS (formerly Netlify CMS) looked promising on paper, but Netlify was no longer actively maintaining it. It was buggy, the UX was clunky, and when we tried forking it ourselves to fix the worst of it, we ran into an architecture too fragmented to patch our way out of.

While we were evaluating all of this, a second problem was compounding in the background. Our own marketing team couldn’t make basic content edits without pulling in a developer. And as we expanded our theme library into Astro and Next.js, new customers kept asking the same question we no longer had an answer to: what CMS do you recommend?

That question was asked enough times and we needed to find an answer soon.

The Turning Point

At some point the search itself became the answer. Nothing on the market cleared the bar our old tool had set, and we weren’t going to find it by waiting. So we decided to build it.We also knew exactly what we didn’t want to rebuild. Every Git-based CMS we’d tried, including the one we forked and abandoned, made you hand-write a schema before the editor would show you anything: every collection, every field, every field type, declared in a config file first. Get one path wrong and the editor renders nothing. That was the friction we’d hit walls on repeatedly, and it’s still true of most of these tools today.

The Solution: What We Built

Sitepins is a Git-based CMS built for the frameworks we already knew our customers were using: Astro, Next.js, and Hugo. Connect a GitHub or GitLab repo and it reads the content files that already exist, infers structure from your frontmatter, and builds the editing interface from what it finds. No config file to write first. You can still edit any of it afterward: field types, labels, defaults, drop-downs, required or hidden flags, but detection gives you a working editor on day one instead of a blank config screen. Everything else follows from that same repo-first approach: visual and Markdown editing side by side, drag-and-drop media management, AI-assisted content tools, and full version control. Every save is a Git commit, so content never leaves the repo. Zeon Studio, our in-house development team, built Sitepins end to end, the application itself and the site you’re reading this on. We built it for our own sites first, and ran it internally before anyone outside the company touched it. We didn’t want to hand customers a tool we hadn’t stress-tested on our own workflows.

Why We Open-Sourced It

Sitepins is bootstrapped. No investors, no VC funding, no outside pressure shaping the roadmap. That independence is what made the open-source decision possible.

We watched what happens when a company shuts down a tool its users depend on, and we didn’t want that to happen to anyone Anyone picking a CMS today is placing a bet on the company behind it lasting. Open-sourcing Sitepins removes that bet. Even if Zeon Studio ever disappears, the code is still yours, and your sites keep running.

Sitepins is now open source under AGPL-3.0. In practice, that means:

• Full source code, free to read and modify
• Free self-hosting for personal and commercial projects, with no usage limits (self-hosting needs Node.js 22+, pnpm, MongoDB, and an S3-compatible bucket for media; Docker Compose brings up the whole stack in one command)
• One condition: if you modify Sitepins and run it as a hosted service for other people, you publish your modifications too

Making the codebase public isn’t just about access, it changes what people can actually do with the product.

• Security auditing. Anyone can look into the codebase and check for vulnerabilities instead of taking our word for it.
• Customization. Developers can tweak features to fit their own workflows rather than waiting on our roadmap.
• Faster bug discovery. More people reading and running the code means more bugs get found than our internal team would catch alone.

Where Sitepins Stands Today

Sitepins sits alongside Decap CMS, CloudCannon, and Nuxt Studio as a Git-based CMS option for static site frameworks. It’s also built for a shift we’re watching play out in real time. AI tools have made building a website fast; they managing content in it isnt one any easier. A site isn’t a one-time deliverable, it’s something you keep updating, and most AI-built sites aren’t structured for that ongoing work. Every small text change risks going back through a prompt and breaking something that already worked.

We built Sitepins for builders who prefer content-in-repo frameworks like Astro, Next.js, and Hugo. And as they hit that wall, and toward a CMS that keeps content as plain files rather than locked in an API meant for multi-channel publishing.