The Problem

A portfolio lives from its content: blog posts, project descriptions, a glossary of technical terms. On this site, all that content lives as text files right next to the source code, in the same repository on GitHub. For a developer, that is perfect: open the editor, change a file, save, done. Convenient as long as you have your work machine with you. Inconvenient the moment you do not, or when a less technically inclined person needs to create or edit an entry.

That is what content management systems are for. A web interface that sits between the content and a human at the screen. Forms instead of text files, a save button instead of terminal commands.

The Options

Many people’s first reflex is WordPress. Everyone knows it, it installs anywhere, but it brings its own database and its own theme system. My portfolio would stop being an Astro website with content and would instead become two systems running side by side, with a bridge in between.

A comparatively young category are the Git-based CMSes, which use the website’s existing repository itself as the database. The three best-known are Decap CMS, TinaCMS and Keystatic.

Why Keystatic

Keystatic comes from Thinkmill, an Australian agency with a strong reputation in the JavaScript ecosystem. It is open source, explicitly built for Astro, and can be hosted entirely on your own server.

Three things tipped the scale:

Astro-native. Integrating it into my existing project took a handful of lines in the config file. Keystatic understands how Astro manages content, and I did not have to restructure my files to make it work.

Git as the store. Every click on “Save” in the browser turns into a real commit in the repository — and therefore automatically triggers the existing CI/CD pipeline that rebuilds and deploys the site. I did not have to touch my infrastructure at all.

A good admin interface. Clear structure, sensible defaults, works without explanation. No designer experiment, no cluttered dashboard, just a tool that does what it is supposed to do.

How It Fits In

The portfolio stays a statically generated Astro website with its content as text files in the repository. The existing pipeline builds it into a finished site on every push and pushes it out to the web server. Nothing about that changes.

What is new: a second small application now runs at cms.mathis-adler.dev. Its only job is to serve the Keystatic admin panel. Whoever logs in there edits the content of the portfolio repository directly in the browser. Save = commit = automatic rebuild of the live site. All through the same pipeline that was already there before.

The bridge between the two is a purpose-built GitHub App that may write to exactly one repository and nothing else. Login to the CMS happens via that app: whoever can log in is also allowed to commit — which was already the case when I was only using the terminal.

The Day-to-Day Workflow

Open cms.mathis-adler.dev, log in, pick between Blog, Projects or Glossary in the sidebar, open an entry. The form shows all metadata as fields — title, description, date, tags, glossary references. The actual text is edited in a rich-text editor that feels like a classic word processor: bold, italic, headings, lists, quotes, code blocks, images via drag-and-drop.

Press save. A few seconds later the new state is in the repository, half a minute after that the live site is rebuilt and online. No intermediate step, no separate “publish” button.

What I Learned

Git as a content store works surprisingly well. Version history, one-click rollback, a clean audit log for every change — all of that comes for free because it was already there. There is no separate database to back up, no custom rollback procedure to write. The infrastructure I use anyway as a developer carries the CMS along with it.

The right tool is the one that fits the rest of the environment. Keystatic does not win because it is the most powerful CMS on the market. It wins because it understands Astro from the ground up, because it adopts my deployment model instead of replacing it, and because it lets me capture half a thought from my phone without spinning up a development environment.

Glossary

Static Site Generation (SSG)
A build process where all HTML pages are generated at build time — not on each request. The web server delivers pre-built files without a database or server-side logic. Result: fast load times, minimal attack surface, and simple hosting.
CI/CD
Continuous Integration and Continuous Deployment — automated processes that test, build, and deploy code after every push. Reduces manual errors and enables fast, reproducible deployments.