Here's my blog posting workflow, using bckt¹, Obsidian², and Netlify³.

The setup

All my posts live in a folder called posts/, which I’ve added as an Obsidian vault. That gives me a nice writing environment with all of Obsidian’s goodies.

Inside the vault, I keep a posts/_obsidian/bckt-template.md file that looks like this:

---
title: "{{title}}"
date: {{date:YYYY-MM-DD hh:mm:ss}}
abstract: >
 Use this to add a post abstract
tags: []
attached: []
image:
---

This is my frontmatter template for new posts.

Writing a post

When I want to write something new, I create a folder like this:

posts/2025/10/251023-my-bckt-workflow/

Then I drop a markdown file inside — for example post.md. (The name doesn’t matter; bckt will pick any <filename>.md.)

I use Obsidian’s Templates: Insert template action to insert my frontmatter, then I fill in the title, date, and abstract, and start writing.

I also add any related files (for example, images) in the same folder, and include them in the attached frontmatter field. I can then reference them relatively (ex: ![image](image.png)), and bckt will take care or the rest.

Turning Farcaster casts into posts

Sometimes I post something short on Farcaster⁴ that I later want to turn into a proper blog post. That’s where bckt-fc comes in. I just run a command like:

bckt-fc --castid vrypan/0xe9e10a9ae08803d21e4c80ce6da730dd3ff3d6a5 \
--destination posts/2025

This fetches the cast (and any images or videos in it) and automatically creates a new post in my posts/2025 folder. It’s a quick way to turn spontaneous thoughts into something more permanent.

Publishing the site

Once I’m done writing, I render the site with:

bckt render

If I want to preview locally, I use:

bckt dev

Finally, to push everything live, I deploy to Netlify:

netlify deploy --dir=html --prod

And that’s it — a full publishing loop that starts in Obsidian and ends with a live post on my blog, all backed by git and simple CLI tools.

When we refer to a blog's "first page", we usually mean the first page visitors see—the homepage with the latest posts. But what if we treated a blog like what it actually is: a notebook or diary?

In a physical notebook, page 1 contains your first entry. As you write more, you fill pages 2, 3, 4, and so on. When someone wants to read it, they naturally start from page 1 or jump to the last page for recent entries.

Traditional blog pagination works backwards because it was simpler for developers to write SELECT * FROM posts ORDER BY dt DESC LIMIT 10. But it creates a fundamental problem: page contents change with every new post.

You can't say "this post is on page 10" because page 10 contains different posts after each publish. This isn't just conceptually messy—it has real technical costs. Links to /page/10 become meaningless. Static site generators must rebuild and upload N index pages per post. Git histories bloat with N changed files.

The Solution

Treat your blog like a notebook with fixed pages:

• Page 1: posts 1-20
• Page 2: posts 21-40
• Page 3: posts 41-60

Your homepage becomes the last page—the one you're currently writing.

To avoid a sparse final page, keep a buffer of 20-39 posts on the homepage. When you publish post 101, articles 81-100 stay on the homepage. Once you hit post 120, page 5 (posts 81-100) gets finalized, and the cycle repeats.

This blog works this way. Visit blog.vrypan.net, and you land on page 138, because I've been posting for years, and this is the page I'm currently writing on.

Note: This is how pagination works on bckt since v0.5.2. Of course, if you think this way of thinking will confuse your users, you don't have to expose it to them, and tell them they are on page 100. You can show links to previous and next pages, just like they are used to. But whne you post a new article, you wont have to re-upload or git commit 100 new index pages ;-)

I've been blogging for almost 30 years—from back when we called them "weblogs" or just "online journals," before "blogging" was even a term. This blog started in 2003 as a diary for my friends. Back then, the audience was tiny. Few people were online. Among them, few spoke Greek, and from them, even fewer knew what a "blog" was.

Then we discovered RSS Syndication—an early content distribution system that let readers subscribe to updates. We didn't use the word "distribution" back then, but that's exactly what it was.

Then social networks arrived and changed everything. They were easy to use and had built-in sharing features that made RSS feel complicated by comparison. Even with all this change, I kept my blog updated, even if not as often. I'm glad I did. Going back to posts from 20 years ago is a real treasure, and I can also point people to my old writings when needed.

Over the years, my blog evolved from a personal diary into my content repository. When I experimented with platforms like Medium and later Paragraph, I always copied the articles back to my blog—keeping everything in one place.

These days, Farcaster is where I publish most regularly. It's so much easier to post a quick thought there—whether it's short-form text, photos, or videos—than to create a full blog post.

That's where bckt comes in. It includes bckt-fc, a tool that makes it trivial to fetch a cast and convert it into a blog post. It will even fetch attached images and videos and store them locally inside the posts folder (in bckt, a post is a folder containing markdown and other assets). It also has special templates to render these posts (for example, with no title).

It's easy to build these small tools for bckt, and I'll probably build more. For example, I'd like to build one that takes a photo as input, reads its EXIF data, and creates a post with the date and location—or maybe a gallery if multiple photos are provided. Or use an MP3 file and its embedded ID3 tags to do something similar for podcasters. (If you've built one of these, let me know!)

I finally built the SSG I always wanted.

https://github.com/vrypan/bckt/