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.

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.