Intern

Fri, 19 Jun 2026 02:10:06 GMT

Ah, the Autonomous Intern. A glorious little housing meant to sit on your desk with its LEDs flashing, letting you know it's hard at work on whatever you threw at the agent it's running.

Out of the box, the Intern is a Raspberry Pi 5 with 4 GB of RAM and a 64 GB SD card. It ships with a factory install (the docs imply Debian Bookworm), and when you plug it in, it boots into access point mode. You connect to its wifi network (Intern-XXXX) and set it up from there.

You can also pop the case open by removing four screws, minding the wires for the LED array. With some tweezers you can pop the SD card and flash it with whatever you want. It's a Pi! Have some fun with it.

Well, I had some fun with it. I reworked the setup script Autonomous provides with some defaults that I preferred:

Debian Trixie instead of Bookworm
Caddy instead of nginx
Hermes instead of OpenClaw (the stock default)
Supermemory dropped for the default Hermes memory (recommended by Teknium, who leads Hermes)

The agent

The brain is now Hermes, the agent from Nous Research. It runs as a gateway service on the Pi and talks over whatever channels you wire up. Bring your own model (I point it at OpenRouter) and pick it in a little web dashboard. Caddy sits out front, serving the setup page and proxying the backend. Nothing fancy, just the parts I trust doing the jobs I want.

Memory

This is the part I went back and forth on. I started by self-hosting Honcho as a memory backend: Postgres, pgvector, Redis, a deriver worker, the whole Docker stack. It worked, and it was also a fragile, RAM-hungry pile of moving parts for what it actually bought me on a 4 GB Pi.

So I ripped it out. The default Hermes memory is just a small MEMORY.md the agent keeps current, plus skills it writes for itself. No vector database, no embeddings bill, and a lot less to run.

Reaching it

The Intern lives on my desk, but I don't want to be at my desk to use it. Tailscale handles that. The dashboard is published to my tailnet only, SSH goes over the tailnet, and a firewall locks the rest down so nothing interesting is exposed to the local network. From my phone or my laptop, anywhere, it's just there.

The LEDs

Those flashing LEDs aren't just for show. The backend drives the ring to track what the agent is doing. On my build, getting it to follow Hermes took a small bridge that feeds Hermes' activity to the backend's LED API, so the ring breathes one color when it's idle, another while it's thinking, another while it's running a tool.

The Rabbit R1

There's one more goodie in the script: a shim that lets you pair a Rabbit R1 to the Intern using the R1's built-in OpenClaw pairing. Scan a QR and the R1 becomes a pocket remote for the agent. I wrote that part up on its own: Replacing Rabbit's Brain.

One script

It's all one script. Flash a Raspberry Pi 5 with Debian Trixie, run it, and you get the whole stack: agent, web layer, memory, remote access, LEDs, and the optional R1 channel. It's idempotent, so you can re-run it without thinking too hard, and it works out on its own whether to run wifi onboarding or use a connection you've already got.

Repo's here: github.com/iammatthias/intern.

Farfield

Mon, 18 May 2026 01:06:15 GMT

If you've followed along at all you'll be aware of the various evolutions this site has undergone. From Wordpress to a Ghost blog built around a template from Themeforest, Squarespace, Hugo, Gatsby, NextJS, and now Astro. And for each framework in the mix, there has been a revolving door of backend. Flat files, a private GitHub repo read over the GraphQL API, a single-user PDS. The frontend changed and the backend changed under it, year after year.

Obsidian as a CMS carried me the longest. Write in Obsidian, sync to a private repo, query GitHub's GraphQL API from the frontend, render the markdown. It was cheap, it was mine, and for a few years it did the job. The rough edges stayed rough. Tag aggregation lived in a hacky flat file. Images went through a plugin. There was no real notion of a record, just files in folders.

A friend had been building everything on a personalized Rust stack, andromeda and a thin slice of dependencies. I wanted that shape for my content. So I built my own CRUD apps. Not a new concept. This collection is mine.

farfield

farfield is a set of small, single-binary Go services. Each one is an HTML admin UI for writing and moderating content, plus a public JSON API the website reads.

apex serves the landing page. content holds collections, entries, and series fragments. feed holds short ephemeral posts. blobs stores image bytes and metadata on Cloudflare R2. A fifth service, backup, runs tailnet-only and snapshots every database into R2 on a schedule.

The stack is the Go standard library plus one dependency: modernc.org/sqlite, a pure-Go SQLite driver. No cgo, so every build is a static binary. HTTP is net/http, templates are html/template, assets get embedded with embed. It's a Go adaptation of andromeda's shape, standard library first, one deliberate dependency.

Three ideas

Every record carries a CID, a sha-256 hash of its content. The slug is the stable key and never changes. The CID changes whenever the content does, which makes change detection, ETag caching, and verification fall out for free. Content addressing on a PDS sold me on this, and I wanted it here too.

A private IPFS

I do devrel at Pinata, so content addressing is the day job. IPFS is good. The DHT, the gateways, the pinning network, all of that is more than a personal site needs.

farfield keeps the part that earns its place. The CIDs are CIDv1, sha-256, the same identifiers IPFS would mint. They live as columns in SQLite and serve over plain HTTPS. Content addressing without the network. A private IPFS, shaped to one site.

A blob's CID is the hash of its bytes, so /blobs/{cid} is immutable and caches forever.

How it runs

docker compose builds each app into a distroless/static image. Production is my homelab server, exposed through a Cloudflare tunnel. Reads are public and send Access-Control-Allow-Origin: *, so Astro fetches them straight from the browser. Writes need an X-API-Key.

The site is rebuilt around this now. Astro reads three JSON APIs instead of cloning a markdown repo at build time. Entry bodies embed blob:// and series:// URIs that resolve to real URLs before rendering.

The home server those services run on is its own story. That's a post for later.

iammatthias — #self-hosting