The post list and archive page weren’t quite enough

This blog runs on Hugo + PaperMod. At first the header just had two menu items: “Posts” and “Archive.” As the post count grows, being able to browse by date or tag helps. PaperMod is a single-column theme though - there’s no concept of a sidebar built in. The content column is fixed at a max width (--nav-width: 1024px) and centered, so on a wide screen there’s blank space on either side. I figured something could go there.

First pass: just two buttons

PaperMod ships an empty hook partial called extend_footer.html - override it and you can inject arbitrary HTML at the end of every page. There’s also a convention where any CSS file dropped in assets/css/extended/*.css gets auto-concatenated into the theme’s stylesheet. Using both, I added two fixed pill buttons in the right margin: “📅 By date” linking to /archives/, and “🏷️ By tag” linking to /tags/. Just shortcuts, nothing more.

Looking at Hatena Blog, I decided to rebuild it

Plain buttons felt thin. Hatena Blog’s sidebar has an actual month-grid calendar with post days highlighted, and a tag cloud with names and counts sitting right there. I wanted that instead.

The tag cloud was easy - PaperMod’s own /tags/ page (taxonomy.html) already does exactly this, so I borrowed its logic directly:

{{ range $tagsPage.Data.Terms.Alphabetical }}
  {{ with site.GetPage (printf "/tags/%s" .Name) }}
    <a href="{{ .Permalink }}">{{ .LinkTitle }} ({{ $count }})</a>
  {{ end }}
{{ end }}

The calendar took more thought since this is a static site generator. At build time, I embed each language’s post dates, titles, and URLs as JSON inside the page ({{ $calItems | jsonify }}), then render the month grid with plain vanilla JS. No external library.

The calendar rendered nothing

I shipped it, and the tag cloud showed up fine - but the calendar area was just blank. The prev/next (‹ ›) buttons appeared; no day grid, no month title.

Checking the actual rendered HTML in devtools, I found this:

<script type="application/json" id="quick-cal-data">"[{\"date\":\"2026-08-21\",\"...\"}]"</script>

The whole array had been escaped and wrapped in quotes as a string. Feed that into JSON.parse() and you get back a single string, not an array. The .forEach() right after it obviously doesn’t exist on a string, so it threw and halted the rest of the script.

The cause was Hugo’s template engine (html/template). When you interpolate a value inside a <script> tag, Hugo automatically treats it as untrusted and escapes it as a JS string literal. jsonify returns a plain string, so Hugo wrapped the whole thing in quotes rather than trusting it as raw JS.

The fix was one line - pipe it through safeJS to tell Hugo explicitly that this JS is safe to pass through as-is:

{{ $calItems | jsonify | safeJS }}

With that, the JSON landed as a real array again, and the calendar started working.

Adding monthly jump buttons

Once the calendar worked, I wanted a way to jump straight to a given month instead of stepping through prev/next one month at a time - which gets tedious as posts accumulate. I added a list of every year-month with at least one post, newest first; clicking one jumps the calendar there in place, no page reload, reusing the same state the prev/next buttons already manage.

Where things stand

This post ends up being a record of the blog fixing itself while I was building it. Calendar, monthly buttons, and tag cloud are all in the sidebar now - next up is actually writing more posts.

To be continued.

Deliberately a different stack

The blog runs on Hugo, but this one is plain HTML/CSS/JS with no build step at all. If I’m going to put projects out as a portfolio, showing range in approach felt better than reaching for the same stack every time. Data lives in a terms.json file, with search and category filtering built on top of it. At launch: 33 terms across 5 categories (stock phrases, reactions/emotions, food & daily life, relationships/how people address each other, and things picked up at work).

Content is a mix of generally well-known Singlish terms plus a few I’ve actually heard myself. The plan going forward is to keep appending to terms.json as new ones come up.

The subdomain pattern became a real pattern

The domain-and-repo shape settled into an actual template at this point: one dedicated GitHub repo per project, one <project>.taikiito.com subdomain via a Cloudflare CNAME. One thing I learned here: the CNAME has to stay DNS-only (not proxied), or GitHub Pages’ automatic HTTPS certificate issuance gets delayed or fails outright.

Back and forth on the footer line

I rewrote the footer copy twice. The first version said something like “hope this is useful to someone” - writing it out, it felt a bit presumptuous, so I changed it to a more self-aware “way too niche for anyone, but I made it for myself so here it is.” Looking at that again, I decided neither was actually necessary and removed the line entirely. Stating what the thing is felt like enough; why it exists is something a reader can decide for themselves.

Two more things shipped, same day

The blog and this glossary, both shipped the same day, both riding the same subdomain pattern. Whatever comes next, that pattern makes it fast to stand up.

To be continued.

Why

The same newsletter that had introduced me to MulmoClaude in the first place also carried some advice from its author: if you want to move toward being an engineer, publish real work on GitHub. The domain setup, self-hosting, and email troubleshooting I’d been doing seemed like the kind of thing that could be genuinely useful to someone hitting the same problem via search, so I decided to write it up.

Choosing a diary format

I first considered topic-organized how-to posts, then switched partway through to a chronological diary - writing things in the order they actually happened, mistakes and detours included. It’s closer to how it actually went.

Picking the stack

I went with Hugo as the static site generator, mainly because multi-language support (i18n) is built in. Theme: PaperMod. Deploy is GitHub Actions building the site and pushing it to GitHub Pages, with a custom domain (blog.taikiito.com) pointed at it via a Cloudflare CNAME.

I split it into two repos: the actual Hugo source I edit (blog-source) stays private, and a single Actions job builds it and force-pushes only the built static output to a separate public repo (blog). Editing history and drafts never leave the private repo - only the finished output is public, which I like.

Renamed my username while I was at it

I also renamed my GitHub username at this point. The old one had a string based on my birthdate in it, added without much thought when I first signed up, and I’d wanted to change it for a while. My first choice was already taken, so I landed on a -dev suffix instead. With zero public repos at the time, the switching cost was basically nothing.

I also set up a GitHub profile README - creating a repo with the exact same name as your username makes it auto-display on your profile page. Kept it to two lines:

Tinkering with computers on the side. Hoping it helps someone.

Where things stand

The blog itself and a public GitHub account are both in place now. The actual posts are what comes next, written up after the fact as things happen.

To be continued.

Why Miniflux

A few options were on the table, but I picked Miniflux for being lightweight and easy to self-host. The setup was one Docker Compose file - a Miniflux container plus a PostgreSQL container. Access followed the same pattern as MulmoClaude: a Cloudflare Access authentication gate in front.

The plan was to pull in the Straits Times, the NYT, and a handful of blogs, sorted by category. Twitter/X was out from the start - it dropped free RSS access back in 2023.

What subscribing to feeds actually revealed

Once I actually wired up the feeds, a few things weren’t what I expected.

• The NHK feed had been silently blocked as of August 8th. No explanation given, and it’s likely targeting cloud-provider IP ranges as a class, not anything specific to my setup.
• The Straits Times and NYT feeds were both alive, but both stop at headline and summary before the paywall.

Technically, I got it fully working.

And decided to stop anyway

Once it was working, I paused and thought about it. The idea of aggregating news by category wasn’t bad on its own, but running it for real seemed like it would just become an ever-growing pile of unread items - an information-overload sink. The point had been to control how much I read, not to read more.

Same day, I removed the whole thing - the Docker containers, the nginx config, the DNS record, the Cloudflare Access application. Less than 24 hours between building it and tearing it down.

Getting something working and actually keeping it are different things

This one taught me that getting something technically working is a different question from whether it actually earns a permanent place in my routine. Deciding to build something and then walk away from it isn’t necessarily a bad outcome.

To be continued.

One subdomain, one static page

I created a new subdomain, card.taikiito.com, and added a second nginx server block on the same Lightsail box. The important part: it’s completely separate from the main Node.js app. No proxy_pass - just a single static HTML file being served - so traffic to the card page has zero effect on the main app’s load.

The content is lifted straight from the business card I actually use day to day. I kept it down to two buttons:

• “Save Contact” - generates a .vcf file on the spot via a JS Blob and opens the phone’s add-to-contacts sheet
• “WhatsApp” - a wa.me click-to-chat deep link

I originally had a third button for sending an email too, but later cut it down to just an info row with a mailto: link. Fewer buttons turned out to be more usable.

A small color detour

I’d built it in navy from the start, but made a black-and-white version too, just to compare side by side. Navy won, and the black-and-white draft got deleted.

A small gotcha

Right after launch, previewing the card inside this app’s own embedded iframe, the email address showed up as a garbled placeholder string instead of the real thing. My first thought was I’d broken something. Turned out to be Cloudflare’s “Email Address Obfuscation” (Scrape Shield) - it automatically encodes email addresses on the page to deter spam scrapers, and a small decoding script is supposed to restore the real address in a normal browser. That decoder just doesn’t run inside this app’s preview iframe. It’s a zone-wide setting, so I left it on and confirmed the real address renders fine in an actual browser tab.

What a name-domain unlocks

The moment my own name became a domain, spinning up small subdomains like this got trivial. A few more of the same pattern would follow.

To be continued.

Why bother with a domain

The server itself was running fine, but the address you’d use to reach it wasn’t exactly memorable, and I wanted something with my own name in it. I registered taikiito.com via Cloudflare Registrar.

I also learned that a brand-new domain tends to get treated with suspicion for a while by various automated network filters, as “uncategorized” and unclassified. There’s basically no way around this except time - letting the domain accumulate age and a sending history until it earns a trustworthy classification. I registered it now, well before I’d actually rely on it, and I’m letting that trust build up patiently.

A backdoor I’d left open myself

While reviewing my access setup, I tried reaching the Lightsail origin’s raw IP directly instead of the domain - and it loaded fine.

That meant the authentication gate I’d set up via Cloudflare Access, which protects access through the domain, could be completely bypassed by hitting the origin IP directly. The lock I’d built for the front door meant nothing if you came in through the back.

The same day, I set up ufw to only allow inbound traffic on ports 80/443 from Cloudflare’s published IP ranges (https://www.cloudflare.com/ips-v4), denying everything else by default. I made sure to run ufw allow OpenSSH explicitly before enabling ufw (get that order wrong and you can lock yourself out of SSH the moment the firewall activates). After applying it, domain access kept working fine, and direct origin-IP access was cut off entirely.

A 522 error when adding a second origin

Under this domain, I added a second entry point for MulmoClaude (mulmoclaude.taikiito.com) and a subdomain for a digital business card (card.taikiito.com).

Right after setting up the DNS (A record) and the Cloudflare Access policy for the second entry point, hitting it returned Cloudflare’s 522 error (connection timed out to origin). The cause: SSL/TLS encryption mode is managed per zone (per domain), not globally. The new taikiito.com zone had defaulted to Full mode, so Cloudflare tried HTTPS to the origin on port 443, but nginx there was only listening on port 80. Switching it to Flexible mode, matching the existing domain, fixed it immediately.

Went ahead and set up SPF/DKIM/DMARC for email too

Since I had the domain, I used iCloud+’s Custom Email Domain feature to set up me@taikiito.com. No extra subscription - just three DNS records, exactly as instructed:

• MX: mx01.mail.icloud.com / mx02.mail.icloud.com
• SPF (TXT): v=spf1 include:icloud.com ~all
• DKIM (CNAME): sig1._domainkey → sig1.dkim.taikiito.com.at.icloudmailadmin.com

These prove, through a few different mechanisms, that mail is genuinely coming from my domain and not being spoofed. Simple copy-paste work.

Still didn’t reach one particular inbox

The setup was correct, but a test email to one of my other addresses never arrived. No bounce either - it just silently disappeared.

Just in case, I added DMARC too (TXT, v=DMARC1; p=none; rua=mailto:(report address)) and confirmed via an external DNS checker that it had propagated correctly. Still nothing. The cause was a sender-reputation problem that SPF/DKIM/DMARC being perfectly correct simply can’t fix - the domain has no sending history yet. Mail servers with strict filtering seem especially sensitive to this.

I’d run out of technical levers to pull, so I’m letting time solve this one too. Even with SPF/DKIM/DMARC configured flawlessly, a domain’s “trust” has a component that correct technical settings alone can’t fix - learned twice now, once for web access and once for email.

To be continued.

What was happening

MulmoClaude has a background feature called journal that auto-generates daily summaries from chat logs. It started taking an abnormally long time every time it ran hourly - some runs took 25 to 90 seconds. It felt like something was retrying over and over, and token usage was climbing noticeably.

Tracking it down

Digging in, I found that a large batch of sessions (625 of them) generated during the migration work (see last post) had been left unprocessed. The hourly job kept trying to process the entire backlog every single run, and kept failing to finish - so the next hour it would try the exact same backlog again. Close to an infinite loop.

Digging further, there was a deeper root cause underneath. The logic that checks whether a session has “already been processed” compares timestamps, and the Python side and the Node.js side handled milliseconds slightly differently - one truncating, the other rounding. That mismatch meant sessions that should have counted as “already processed” kept looking “unprocessed” every single time. A few attempted fixes didn’t stick, because none of them addressed the mismatch itself.

Stopgap, then the real fix

First I turned the journal feature off entirely to stop the bleeding. Then I fixed the timestamp handling so both languages treat precision the same way. After that, I confirmed daysSkipped: 0 and the hourly check dropped to 2-3 milliseconds.

I also revisited the schedule: journal is now pinned to run once a day (dailyIntervalHours: 24), and the hourly scheduler check itself stays lightweight.

What I took from this

“Always-on” turned out to mean more than just the app staying up - the quiet automation running behind it has to not break either. The most expensive thing was happening somewhere completely invisible from the front end.

To be continued.

Weighing the options

Leaving my laptop on 24/7 was ruled out on electricity and portability grounds. Connecting directly via SSH from my own machine was ruled out early too - corporate networks commonly block outbound port 22 (SSH). Instead I went with HTTPS over a domain, fronted by an authentication gate (Cloudflare Access). Login is via Google account, plus the app’s own shared secret (MULMOCLAUDE_AUTH_TOKEN) as a second layer.

I went back and forth with Sakura Cloud, but chose AWS Lightsail for the lower latency from its Singapore region. Started on the $7/mo bundle (1GB RAM, 2 vCPUs, 40GB SSD), planning to upgrade later if it wasn’t enough.

A silent failure: the CSRF trusted-origin gap

The migration itself went through, but sending a message from the browser just silently failed - no error, no response.

The cause: the app’s built-in CSRF guard checks the Origin header, and the new domain hadn’t been added to MULMOCLAUDE_TRUSTED_ORIGINS in .env. Adding https://mulmoclaude-taiki.com there and running systemctl restart mulmoclaude.service fixed it. If you’re self-hosting MulmoClaude and sends silently fail only from your public domain, check this first.

Chasing down “Network error calling …”

A few days later, internal MCP-bridge calls like presentForm and manageCollection started intermittently failing with “Network error calling …: fetch failed.”

My first suspicion was memory pressure. /proc/meminfo did show low MemAvailable, with swap mostly used. I installed zram-tools for compressed swap (/dev/zram0) and dropped vm.swappiness to 10 - no change. I even bumped the Lightsail plan from $7/mo (1GB) to $12/mo (2GB) just in case, and the error still reproduced 100% of the time.

The real cause turned up when I read the app’s source (server/index.ts): it’s designed to bind only to loopback - app.listen(port, "127.0.0.1", ...). The sandboxed agent reaches the host via host.docker.internal. On Docker Desktop (Mac), that resolves through a hypervisor proxy that does reach loopback. On Docker Engine (Linux), it just resolves to the real IP of the docker0 bridge (172.17.0.1 in this case) - a genuinely different interface, which a loopback-only bind will never accept a connection from. A latent bug that never surfaced on the Mac, exposed for the first time on Linux.

The fix was a single socat relay bridging the docker-bridge address to loopback:

ExecStart=/usr/bin/socat TCP-LISTEN:3001,bind=172.17.0.1,fork,reuseaddr TCP:127.0.0.1:3001

Registered as a systemd unit, and curl http://host.docker.internal:3001/ immediately started returning 200, with presentForm/manageCollection working right away. The memory/zram work wasn’t entirely wasted (headroom genuinely improved), but it was never the actual cause of this error.

Why I ended back on $12/mo (2GB)

Once the real cause was fixed, I tried downgrading back to $7/mo (1GB) to save money. Lightsail, though, doesn’t support resizing an instance down via snapshot - it meant rebuilding a 1GB instance from scratch. That rebuilt instance repeatedly hung under load (like building the Docker sandbox image), with SSH and even Lightsail’s own browser console becoming unresponsive, more than once.

I concluded 1GB can’t reliably sustain this workload (MulmoClaude itself, the Docker sandbox, and the Telegram bridge together) and settled on $12/mo (2GB) as the final plan. Stability won over saving a few dollars.

Running 24/7

A few stumbles along the way, but this server has been running around the clock ever since. I can use it anytime, from anywhere, regardless of what state my own laptop is in.

To be continued.

As a first step, here’s how it all started.

How it started

I came across “MulmoClaude” through Satoshi Nakajima’s newsletter - an open-source project that lets you self-host an AI assistant like ChatGPT or Claude on your own machine instead of as a SaaS, with conversation history and memory persisted as local files you control. I decided to set it up on my MacBook. Environment: Node.js v24.18.0, git 2.50.1, Claude Code CLI v2.1.220.

First stumble: ERR_MODULE_NOT_FOUND

There are a few install methods. I first tried the developer route: git clone-ing receptron/mulmoclaude. Running yarn install then yarn dev threw ERR_MODULE_NOT_FOUND and the server wouldn’t start. The cause: I was trying to start dev before the package workspace had actually been built. Running yarn build:packages:dev first fixed it immediately. If you hit this exact error, check that build step first.

Once it was working, I found out the officially recommended path is npx mulmoclaude@latest - no build step, no repo to manage. I switched over the same day. The port also changed, from 5173 (the git-clone/yarn dev setup) to 3001 (npx). I still run the npx version today. Had I started there, I’d have skipped the ERR_MODULE_NOT_FOUND stumble entirely.

Getting it into actual daily use

Once it was running, I made a few changes to turn it into something usable day to day. First, I wanted access when I wasn’t at my computer, so I created a bot (taiki_mulmoclaude_bot) via BotFather and wired it up following the official Telegram Bot API steps. Being able to chat with it on the go turned out to be genuinely useful.

Alongside that, everything I’d built up talking to the official Claude app (my work, where I live, my interests, day-to-day notes) got carried over as “memory” (a system that accumulates as local Markdown files) into this new setup. Picking up from that existing history, instead of starting from zero, made a real difference.

Finally, I didn’t want a broken local environment to wipe everything out, so early on I created a private GitHub repository and set up regular automated backups via git push. That habit is still going, and it later gave me the confidence to move everything to a server.

By this point, I had MulmoClaude running on my machine, reachable via Telegram, with its data backed up on GitHub. Next: moving it to an always-on cloud server.