Tin

While I was kvetching about blogging and pondering how to cobble together some kind of post-by-email Rube Goldberg system, my buddy Owen was busy solving problems. I made it very clear that I am not a particularly competent software developer; whereas Owen is a very skilled one.

He has been working on a Golang-powered blog package that he calls Tin. The atomic symbol for Tin is Sn, so that’s the shorthand name of the app. It’s still a work in progress, but it’s sufficiently reliable that he’s been using it to power his own site for quite some time. This weekend, with no small amount of assistance from Owen, I switched my site over to use it, too!

What makes Tin particularly interesting to me is that it’s fed by static content – plain old Markdown files – and it maintains an in-memory SQLite database of that content. This makes an interesting combination of benefits. I can version control all my content, and deal with plain text, but the app can index it to create single post pages, tag pages, my archive page, and a search page all on the fly.

Another super powerful feature is that Tin can read a git repository of content on startup. That means I don’t need to manage a sync process or a “publish” workflow to get my content from GitHub to my site. I launch Tin, it reads the repo, and starts serving content. It also has a webhook that I can hit to make it fetch new content from that repo. This means I can push content to my GitHub repo all day long, edit it, review it, whatever; and then when I’m ready I make a simple curl request to my own website which then fetches any changes to the repository and starts serving it. I could make a GitHub Action to ping my site on merges to the main branch to automate this update.

There is a simple writing interface in Tin, which can create new content and add it to the repo. If you use a read/write access token, it’s possible to have Tin push new posts the GitHub repository. This is super clever, and provides not just a nice workflow, but a nice backup mechanism. With database-powered software like, say, WordPress, one needs to take regular backups of the database to save content. Tin leverages git to manage backups and version control. And while I use GitHub to store my blog contents, I could just as easily use Gtilab or any other hosted git solution.

My modest contributions to the project so far are some small feature requests, and a Dockerfile. I’m running Tin via docker-compose here. My entire blog archive fits in a tiny amount of memory, and the Tin container uses an astonishingly small amount of CPU.

While this strays a little bit from my previously stated goals of “running less software” and “serving static content”, I think the tradeoffs are acceptable for now. I still have plaintext source files; I have version control; and I have an easy-to-maintain runtime that won’t suck up all my free time babaysitting updates. Plus, I know the guy who wrote it so I can ask him for help.

I’m looking forward to writing more. I’ve been pretty lax for the last couple of years. In the process of tweaking things for Tin, I made a number of small content improvements to a few older posts, implemented a better system for handling “pages” outside of the blog timeline, and added OpenGraph tags. None of this is particularly interesting or important, but it feels nice to tidy up the ol’ blog as hurtle toward 2025.