rhys.wtffeeds

← Back to Coffee now

Building an IndieWeb house (II): Hugo and syndicating elsewhere

Coffee nowOpen original ↗

In this second part of my ‘Building an IndieWeb house’ series, on the whys and hows of this blog, I’m going to go over the very basics of using the static site generator (SSG) Hugo to make a website, how to get that on the internet and the ‘syndicate elsewhere’ element of the ‘Publish (on your) Own Site, Syndicate Elsewhere’ (POSSE) concept.

This will be the post that’s the most techy of this series, and one where I do also mention specific platforms, software or companies, and, yep, sometimes they have been chosen because of how we align with their or their owners’ policies.

I’m indeed actually writing this a few days after Mozilla did an absolute shocker with some truly bad terms being added to FireFox, and although those have partly been rolled back, I’m reminded in many cases all we have for tech is least-worst options. Because while Mozilla did its self-inflicted damage, almost to the day, Google pivoted to permit fingerprinting, as well as disabling Manifest V2 in Chrome and hence tracking blockers, such as uBlock Origin.

For browsers, we have Chrom(ium) and its derivatives (i.e. those running on the blink engine), and FireFox and its derivatives (gecko engine), that’s it.

For blogs, thankfully we do have quite a plethora of good options… and a few I personally wouldn’t use, such as the proprietary platform Substack (which charges $50 to use with your own domain anyway). I even would have concerns right now with WordPress, despite its core being open source. [Why is too much to get into here, but there are some links in the ‘extra shots’ section for further reading.]

With regards to techy stuff [oh, yes, I do say techy, not the more-common form techie; I think it’s a valid alternative, so my blog, my rules!], my intention is to show that once something is familiar, with practice it becomes less intimidating.

The most very basics of Hugo

Now, this is not meant as a tutorial to Hugo; the purpose of this section is just is to give a flavour of how we go about using it to go from some markdown and images to a static website.

And the first step to using Hugo is obviously to install the Hugo program from the Hugo website.

Next, you set up a folder structure on your computer to organise your blog’s content.

Hugo operates through the command line, so create a root folder to store your blog, open a terminal in that folder (right click, open terminal), and type the command ‘hugo new site coffeelater’.

$> hugo new site coffeelater

This creates a folder structurea diagram showing root folder call coffee later and subfolders of archetypes containing default.md, assets, content, data, layouts, statics, themes, and a file hugo.toml marked as site configuration:

coffeelater/
├── archetypes/
│   └── default.md
├── assets/
├── content/
├── data/
├── layouts/
├── static/
├── themes/
└── hugo.toml      <– site configuration

Then you need to choose a theme from the Hugo theme’s directory, grab those files (usually from GitHub) and stick them in the themes folder.

One thing that’s immediately noticeable is you don’t get a huge number of themes. But that said, how many times do you find you visit a WordPress site with the exact same theme (like every recipe blog)!

Our site is currently using the Hugo theme Papermod, written by Aditya Telange and available under an MIT license. It’s basic parameters are set up through the ‘site configuration’ file, but it’s actually called ‘config.yaml’ in that theme.

Then, start writing!

Content for each post goes into separate folders (called page bundles in Hugo parlance), within content>posts; the main bit of markdown for each post needs to be saved as index.md (and yes, it’s an annoyance of page bundles that you do you have to call the file ‘index.md’, so you end up with a lot of ‘index.md’s over the years)a diagram showing root folder call content and a subfolder posts containing pizza-test-post and my-real-first-post both with an index.md file. pizza-test-post also contains two image files.

content/
├── posts
│   ├── pizza-test-post
│   │   ├── index.md
│   │   ├── image-1.png
│   │   └── image-2.jpg 
│   └── my-real-first-post
│       └── index.md
│

One thing to remember about any images, or any media really, is to size them appropriately (your visitors don’t need to download a full on 30 MB file that gets squished into a third column-width view!).

Oh and remove/adjust the metadata (especially, say, GPS coordinates on the image of the sandwich taken in your back garden!). Hugo does have an imaging processing pipeline to help with this, or you can use your own scripts, or do it manually as you go.

Once you have your blog post’s content sorted, it’s onto using Hugo to make the website.

Open a terminal back in your ‘coffeelater’ folder, type ‘hugo server’.

$> hugo server

What will happen at that point is some text will appear, the second to last line of which contains a link to a ‘localhost’. What you’ve done is set up a web server on your computer that’s showing a live version of your Hugo website.

$> hugo server
.
.
.
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
Press Ctrl+C to stop

Upon visiting that URL in a browser of your choice, you’ll see your website.

As well as rendering your post from markdown to HTML, the Hugo template will have taken care of all the tricky stuff, like pagination of your posts, tag pages, navigation etc.

This is the stage where you fiddle with your post’s content until you’re happy with it.

I will say almost every blog has a first post about setting up the blog, but for fun we’ve left up our real first post – the pizza test post! Although it has also served as a test page for other things added since that practice at some basic formatting in our first ever markdown file.

When you’re ready, then it’s open your terminal again, type ‘hugo’. This makes all your website files and saves them, ready to be transferred to your web server.

Infinite Ink has a full Hugo tutorial explaining a bit more, although it doesn’t cover recent changes.

Hosting

So now we have to decide where to host our website to get it actually on the internet.

Static sites are by definition just the files, so hosting these is not complicated. That said we (and I assume most readers) aren’t in the business of self-hosting our own web server, so we need a third-party host.

The cheapest option is GitHub pages, which offers completely free hosting for non-commercial static sites of up to 1 GB under your own domain, and until relatively recently, that’s indeed where we hosted this site.

Although you need to know a little git to actually do this.

However, owing to vague unease about ‘if you’re not paying for the product…’, among other reasons, we’ve recently moved to hosting ‘coffee now’ with Mythic Beasts, and because this is such a small site, such hosting is still not costly.

So, it’s simply a matter of following their instructions to send files over to the web server via secure FTP in a old-school, it works way.

Then you need to set the DNS record (from where you bought your domain name) to point at the IP address that your host tells you (or one of the other ways to make your domain point at your web server).

Finally, it’s tick a box to enable https, as no website should run without encryption to prevent man-in-the-middle attacks in 2025, or even in 2021 (shout out to Let’s Encrypt for their 20 years providing this service!).

🎉🥳 Yippee!!!

OK, that’s not nearly loud enough. Some inline CSS to the rescue.

Presented at three times usual size 🎉🥳 Yippee!!!

Much better.

We have our IndieWeb house.

Syndicate elsewhere

Next we come to the syndicating elsewhere, or where and how we share our content around such that people who are interested in it might find it.

Now, although I don’t know this for sure (we do no tracking of visitors at all on coffee now), I do suspect most people will come to this blog because we know them and have sent them a URL in real life!

Q: “Do you have any pictures of that?"
A: “Oh, yes there are some on our blog at coffeenow dot moomop dot uk”

But for everyone else… all two of you looking at this (just joking)…

Via RSS and email

First, let’s remember RSS, the simple – in my mind best too – solution to letting people subscribe to your blog.

Almost all blogs will have an RSS (or ATOM) feed somewhere (even youtube still has RSS if you know where to look), although it’s location might be deeply buried. This is a URL pointing to a simple machine-readable text file that will allow a program called a feed reader to ping up new posts.

NetNewsWire is the feed reader I use on iOS (aside: I need to check out a pink NetNewsWire theme I’ve just discovered while doing research for this blog post), or there are some nice browser extensions out there like RenewedTab.

RSS feeds can also be added directly to some so-called ‘timeline apps’, such as Tapestry and Surf.

You could also offer an email subscription service, although that is a bit too much for us; email is expensive (well it’s more like email is cheap, but getting it through to Outlook and Gmail is expensive), and takes you into needing permissions to collect data and processes to keep it secure.

There are also a few services, such as FeedRabbit, that you can point people to for RSS-to-email if someone asked (although note I’ve not personally used them).

Via the silos

Then there’s your social media silos (you know the names, Facebook, Instagram, LinkedIn, TikTok, X) that you might want to share your URLs or content on, even though most silos will, at best, depromote content with links.

You definitely can’t avoid politics when you decide which of these you might want to engage with.

My choice might not be your choice here, but one tip is if you do share a URL in Facebook, run the URL through Facebook’s debugging tool first.

This is because the first time a link is sent to Facebook, the OpenGraph information that makes up the preview cards isn’t there, and if you’ve gone to the effort of making those, then of course you want them showing up. [Aside: in our case, the doodles in the preview cards are actually drawn by me by hand in a digital art tool – they are not AI; if people do use AI cover images on blogs, it tends to make me suspicious that the text content is AI slop too.]

Via open protocols

You might also choose to share content on social media platforms run on open protocols; in particular, I’m thinking the ATmosphere and the fediverse.

Now, details of the ATmosphere and fedi are too complex to get into here (our initial impressions of Mastodon are already in another post), but to summarise a few points (as of Feb 2025, when I gave the talk):

ATmosphere

  • runs via ATproto
  • is 99% BlueSky; what little isn’t, is usually the personal data server (PDS) side of things
  • the relay component of the network is totally BlueSky because it’s expensive; hence, this is a centralised platform (even if other relays came on board, those too would almost certainly be corporate owing to the cost)
  • venture capital funded (therefore, I’m afraid it will likely enshittify in time as those investors will want their money back)
  • ~4.5 million posts per day (so about five times the size of the fedi)

Fun tip – you verify yourself by using your domain name as your handle (I really like this feature, even if it’s down to your real handle being blockchain)! Hence, we’re @coffeenow.moomop.uk.

Fediverse (not including Threads, which at best can only be described as partly fedi)

  • runs via ActivityPub
  • is ~60% Mastodon, ~20% Pixelfed and ~20% other software platforms
  • is truly decentralised, being a network of small instances (servers); you could even set up your own instance!
  • mostly donation funded, so runs on a shoestring budget, both for the software and the instance hosting (yes, I do contribute to my instance’s costs)
  • ~1.6 million posts per day

Best tip for the fedi is check out third-party apps and web clients, e.g. Phanpy might suit you better than the standard interface.

We’re @coffeenow@mastodon.me.uk.

There is a bridge between the ATmosphere and fediverse, meaning you can cross post. To enable that, it’s simply a matter of, on BlueSky, following @ap.brid.gy, and, on the fedi, following @bsky.brid.gy@bsky.brid.gy (search for it from your instance).

At the moment, pre-BlueSky enshittification, I don’t see any major downsides to bridging (although I do have to modify my posts in the fedi somewhat to make sure all the important info is in the first 300 characters for BlueSky).

So here we are. Now we not only have an IndieWeb house, we’ve POSSE’d it around!

All that remains to talk about is my blogging top tips – hint, the most important one is to have fun.

Back for that next time.

Extra shots

Substack and WordPress

Hugo

RSS

Social media

Credits

Photo of the mailboxes by Mathyas Kurmann on Unsplash

Comments (0)

Comments (0)

No comments yet.