blahg is Cassidy's Astro blog with TinaCMS bolted on the front

Markdown in the repository, an editor in the browser

The interesting decision in blahg is not the framework but the editing model. Content lives as Markdown files in a posts directory inside the repository, so every post is a git commit, reviewable and diffable like code. On top of that, TinaCMS provides a browser-based admin interface for the same content, reachable at yoururl.com/admin.

The documentation puts it plainly: this is a blog template built with Astro, and it uses TinaCMS to edit the content. The name is a joke, with the readme explaining that blahg is the proper spelling for Chicagoans, and there is a live deployment at blahg.netlify.app to look at before you fork it.

For the target audience, a developer writing a personal site, this is the useful trade. You get the comfort of writing in a text editor with git history, and you also get a visual editor when you would rather click. What you do not get is a platform where a non-technical editor logs in and works independently of your repository. That is the real boundary of this template, and it is worth being clear about before you start.

The topic tags on the repository describe the shape of it: astro, blog, markdown and template. The homepage of the live site is the Netlify deployment, and the repository includes a Netlify deploy status badge.

A short checklist of files you have to edit yourself

The setup steps are a checklist of concrete files, which is exactly the right level of detail for a template. Connect to your hosting provider, using the Deploy to Netlify button if you want that route or the GitHub template button if you do not. Make an account at tina.io, then add your TinaCMS keys, update astro.config.mjs with your domain, and edit src/settings/settings.json or change it through Tina itself.

The remaining items are small and specific: set your Twitter creator handle in src/components/BaseHead.astro in the twitter:creator meta tag, add your URL on line 1 of public/robots.txt, add your links in src/components/Header.astro, update the intro in pages/about.md, and optionally replace the images in public/ and the RSS styles in public/.

One optional step is more interesting. You can edit the tags you want in tina/config.js, which tells you that the tag vocabulary is a configuration list in the repository rather than something a writer creates in the admin UI. That is a deliberate simplification, and it is also a limitation for a site with many tags.

The documentation closes by asking anyone who uses the template to say so through social media or a GitHub issue. That is a personal project maintained by one person, and the tone of the instructions reflects it.

npm scripts that run Astro through Tina

The package manifest is the clearest description of how the two tools interlock, because every script wires them together.

The dev script is the interesting one. It does not call astro dev directly, it runs the TinaCMS dev command with Astro passed as the inner command, so the CMS and the site start together:

		"dev": "npx tinacms dev -c \"astro dev\"",
		"start": "astro dev",
		"build": "tinacms build && astro build",
		"preview": "astro preview",

The start script runs Astro on its own, without the CMS, and the build script runs a Tina build before the Astro build, which is how the CMS data is pulled into the site before it is generated.

The documented commands are listed as a table. npm install installs the dependencies. npm run dev starts the local dev server at localhost:4321, and the documentation adds a fallback, npx tinacms dev -c 'astro dev', described as a way to manually run the local server if the regular command does not work. npm run build builds the production site into ./dist/, and npm run preview previews the build locally before deploying.

The dependency versions are modern. Astro is pinned at ^7.0.3, tinacms at ^2.10.1 and @tinacms/cli at ^2.5.1, with @astrojs/rss and @astrojs/sitemap as dev dependencies, along with prettier and prettier-plugin-astro. The package itself is private, named @cassidoo/blahg, at version 0.0.6.

TinaCMS keys need a .env.development file before the editor works

To clone the template and run it locally with the CMS attached, you need credentials from tina.io in an environment file. The documentation names the file and the three keys it needs:

TINACLIENTID=<from tina.io>
TINATOKEN=<from tina.io>
TINASEARCH=<from tina.io>

The three values are placeholders pointing at what you get from your tina.io account, and the file itself is git-ignored, which is the point of the exercise: credentials stay out of the repository while the content stays in it.

Once the server is running you open localhost:4321/admin/index.html to reach the CMS interface. Note that the admin path is not simply /admin in the local dev server, which is a small difference from the deployed behaviour described elsewhere in the readme, where the editor is at yoururl.com/admin.

There is a known failure mode documented for the setup. If you hit a remote GraphQL schema error, the documentation says the likely cause is that TinaCMS needs updating, and points at the Tina documentation entry on resolving a local GraphQL schema that does not match the remote one. That is a useful heads-up because the error message does not obviously point at a version mismatch.

RSS styles in public/ have no hot reloading

A small limitation is called out that would otherwise cost an afternoon. If you want to edit the RSS feed styles, the file is public/rss-styles.xsl, and that file does not have hot reloading, so you have to refresh the page with every change. The documentation explains why in one sentence: it seems hard-coded, but that is how XSL styles work.

It is a small thing, but it is representative of the template's edges. The XSL file is served as a static asset from public/ and is processed by the reader, not the build, so the dev server has no way to know it changed.

The RSS setup is otherwise handled by the @astrojs/rss dependency, and the public/ directory also holds the images and the robots.txt file you update with your URL. The documentation lists editing the RSS styles and the images as optional, so a fork that skips them still works.

MIT licensed, deployed on Netlify, and quiet since June

The licence is MIT, so the template can be forked, modified and shipped without restriction beyond keeping the copyright notice. That is the right licence for something intended as a starting point rather than a service.

The deployment target is Netlify, and the readme carries a Deploy to Netlify button that starts a deploy straight from the repository. A Netlify status badge points at the deploys page for the site. The alternative path mentioned is the GitHub template button, which creates your own copy of the repository and lets you pick a different host later.

On upkeep, the last push was on 2026-06-29, and the repository publishes no GitHub releases. There is no changelog to read and no versioning scheme to track, so the version field in package.json, currently 0.0.6, is the only signal of where the template stands. The package is marked private, which is the npm flag for a package that is not published to the registry, and there is a package-lock.json so the dependency tree is pinned for the deployment.

The practical reading is that this is a maintained personal project rather than a released product. The dependencies on Astro and TinaCMS are what actually determine whether the template still builds, and both move quickly.

Editorial conclusion

blahg suits a developer who wants a personal blog with a visual editor today and is comfortable owning the Markdown files and the hosting account tomorrow. It is the wrong starting point for a team that needs multi-author roles, scheduled publishing, or a CMS that the site owner does not have to build themselves, because the editor is configured in tina/config.js and the tags are a hand-maintained list. Before cloning it, read the setup checklist and put your own domain into astro.config.mjs, your links into src/components/Header.astro, and your Twitter handle into src/components/BaseHead.astro, since leaving the template's placeholder values in place is the most likely reason a fork looks broken on day one.

Frequently asked questions

Official sources

1. cassidoo/blahg on GitHub
2. Issues
3. License: MIT
4. Project website
5. README