Hosted by TMQ

Hosted by TMQ website

TMQ — Fri, 03 Jul 2026 00:00:00 GMT

This site is intentionally personal, but it is not a snowflake. It uses the same platform pieces as the client sites: route manifests, media manifests, Payload snapshots, SvelteKit static output, DaisyUI themes, and deployment orchestration.

What it is testing

Blog, project, and system collections in the shared content model
Full-content RSS and Atom feeds from the static snapshot
Instant fuzzy search without a server endpoint
Reusable code blocks, author badges, and reader preferences
Build-once promotion from a checksum-verified remote release bundle

export const contentCollections = [
  'blog',
  'projects',
  'systems',
] as const;

Visit hosted.fyi - The canonical public home for Hosted by TMQ.

Static sites with a CMS are not a contradiction

TMQ — Wed, 01 Jul 2026 00:00:00 GMT

A static site does not have to mean writing every page by hand or teaching editors Git. It means the public thing people visit is already built, cacheable, and boring in the best possible way.

The CMS still matters. Payload is where entries are drafted, reviewed, and published. The public website only sees a validated snapshot after publish. That small separation removes a lot of runtime drama.

The publishing shape

Payload owns content, editorial metadata, and publish state
A signed publish hook asks the Website Manager to rebuild the site
SvelteKit turns the current snapshot into static HTML, feeds, and search JSON
The release is pushed to storage and served through BunnyCDN

export function contentEntryPath(entry) {
  return `/${entry.collection}/${entry.slug}`;
}

// /blog/static-sites-with-a-cms

Why I like this default

It keeps the fun parts of a CMS, like clean authoring and publish workflows, while making the public site cheap to host and easy to cache. There are still places where live rendering is useful, but a technical blog is usually not one of them.

The best production system is often the one that has fewer opportunities to be interesting at 2am.
TMQ

NixOS rebuilds with a soft landing

TMQ — Sun, 28 Jun 2026 00:00:00 GMT

NixOS makes server state pleasantly explicit, which is a nice change from the classic "I edited five files and now the machine remembers my sins" style of operations.

The habit I keep reaching for on VPS hosts is simple: apply the new config temporarily, verify the services that matter, then make it permanent only once the host looks healthy.

sudo nixos-rebuild test
systemctl --failed
curl -fsS https://example.test/health
sudo nixos-rebuild switch

What this buys you

A reboot can fall back to the previous boot config if the test change was bad
You get to inspect systemd failures before committing the change
The runbook stays boring enough to repeat under pressure

Client hosting platform

TMQ — Thu, 25 Jun 2026 00:00:00 GMT

The platform is split into a public web host and an internal services host. The public host serves static files through Caddy, while Payload, Umami, and deployment orchestration live away from public reader traffic.

Current shape

client-web-01 serves static releases and reverse-proxy front doors
internal-01 runs Payload, Umami, Komodo, and supporting services
BunnyCDN handles DNS and global CDN delivery
Releases use build artifacts, rsync, symlink swaps, and cache purge

Things I still want to improve

Tighter rebuild queue visibility
A nicer approval packet for content-only changes
More automatic checks around cache headers and stale release cleanup