Show HN: Foundry: a Markdown-first CMS written in Go | Hacker News Reader

Show HN: Foundry: a Markdown-first CMS written in Go

github.com

31 pointsnsayoda8 comments

Hi HN! I've been building a CMS called Foundry, brought together from multiple smaller private projects as well as greenfield code.

The short version is: it's a CMS written in Go with a focus on markdown content, a simple hook-based plugin model, themes, archetypes, preview flows, and a clean authoring/developer experience.

I started working on it because I wanted something that was more powerful than Hugo for a few of my websites, without having to resort to dangling onto a database.

What seems different about it, at least to me, is that I'm trying to keep the system small in concept: local content, explicit behavior, compile-time plugin registration, and an admin/editor layer that is meant to stay close to how the content actually lives on disk. The goal is not to make "yet another website builder", but to make a CMS that is easy to use and quick to onramp onto, but has powerful advanced features and extensibility.

Still early, but usable enough that I wanted to put it in front of people here and get feedback. Please don't castigate me on the UI look - I'm not a designer, and the themes are basically clones of each other.

Happy to answer technical questions, architecture questions, or hear where this seems useful versus where it does not.

Open articleView on HN

I like the markdown first focus - Something I am building on markdown : https://github.com/VoidenHQ/voiden

That's pretty sick! Downloading to try it out now

The instinct to keep the system "small in concept" is the right one, and it's harder to maintain than it sounds — most CMS projects start focused and then bloat themselves into irrelevance trying to be everything. The tell will be how you handle feature requests that are genuinely useful but push against that philosophy. What's already been the hardest "no" to say?

Very well put. I'm hoping most features can live in standalone plugins built by the community or myself, rather than being built into the core. The goal is to keep the core small and avoid bloat, while still leaving plenty of room for features and customization.

The hardest "no" so far has been a request to change the license from AGPLv3 to MIT

That might not sound like a huge deal, but most of my previous FOSS projects have been MIT licensed, and with this one I want to keep the expectation that modifications to the core remain available to the public under the same license terms

I did carve out explicit exceptions around a boundary: third-party themes and plugins are not intended to be pulled into the copyleft scope. I spelled that out in the repo alongside the license in the LICENSE.*.EXCEPTION files

Interesting approach. Keeping everything as local content without a database is a strong design choice - it makes version control with git trivial and deployment much simpler.

Exactly! My thought was that backups, or porting from one version of Foundry to another would be as simple as copying the `content` directory since everything user-generated lives there (admittedly inspired by Wordpress' `wp-content`)

Interesting concept. You may run into legal trouble with Palantir over the name Foundry if you scale, lol. Otherwise it's cool--website looks way too AI generated IMO.

No hate tho, you got this.

Thank you! That's a valid concern - though I think I should be ok as Foundry CMS. Something I'll have to keep in mind, and hopefully it scales!

> website looks way too AI generated IMO

The docs? Yeah that and the base themes were all from AI-generated scaffolds that I then wired into the project with the SDK - UI/UX is not my forte. Hopefully I can either hire a proper designer in the future (at least for the docs and default theme), or a designer in the community decides to help with the project

Reply on news.ycombinator.com