Where Notes Can Be Remembered

There is a particular kind of problem that creeps up on a home lab slowly.

It is not a broken service, or a misconfigured network, or a certificate that refuses to issue. Those problems announce themselves. They have error messages. They are logged. They have a shape you can work with.

The problem I am thinking of is quieter than that. It is the problem of not being able to find what you already know.

For a long time, my home lab knowledge lived in the places knowledge goes when it has nowhere better to be. Terminal history. Half-finished notes in applications. Decisions I remembered making but could not reconstruct. Configuration choices that made sense at the time and were now just facts I was carrying around in my head, hoping I would not need to explain them to myself at an inconvenient moment.

That is not a crisis. But it is friction. And friction, as I keep learning, has a way of accumulating quietly until it costs more than you expected.

So I started thinking about a wiki.

The word wiki carries a lot of weight it does not always deserve. It can suggest something sprawling and committee-maintained, something that requires governance and structure before it can be useful. That was not what I wanted. What I wanted was simpler: a place where notes could live that was easier to trust than memory, easier to search than terminal history, and easier to feed to an AI assistant than a folder of loosely organised files.

That last part mattered more than it might sound like it should.

I have been thinking about how I work with AI tools. Not as a replacement for thinking, but as a way of extending what I can do with the thinking I have already done. If my notes exist as plain markdown files, they become easy to share, easy to paste, easy to reason about with outside help. If they live in a proprietary format, or behind an interface that does not expose the raw text cleanly, that path closes. The format of a note is not just a storage decision. It is a decision about what the note can do later.

Silverbullet appealed to me for exactly that reason.

The setup was straightforward in the way that good tools often are. An Incus container on anvil. Docker inside the container. A single image. A volume mount for the notes themselves. The kind of deployment that fits in a few lines and does not ask you to understand a great deal before it starts working.

That simplicity was not accidental, and I did not take it for granted.

There is a version of this decision where I spend three evenings configuring something more powerful, more flexible, and ultimately less likely to be used. I have made that mistake before. The right tool for a notes system is not the most capable one. It is the one that stays out of the way long enough for the notes to actually accumulate.

Getting it running was only the first part. The container needed Docker to behave inside LXC, which required a small amount of persuasion at the Incus level. Security nesting. A couple of syscall intercepts. The kind of configuration that looks obscure until you understand what it is doing, and then looks obvious. Once that was in place, the container came up cleanly and the service started without drama.

Then came the reverse proxy.

By this point, proxy was already doing its job. Caddy was already running. The Cloudflare DNS plugin was already in place. Adding Silverbullet meant one new block in the Caddyfile, one new DNS record in Technitium, and a name that felt right: docs.forge.cdilks.com. Not wiki. Not notes. docs. A place where documentation lives. That felt like the correct word for what I was building.

There was one moment that gave me pause.

Silverbullet, it turns out, will not run happily over plain HTTP from a remote browser. It uses browser APIs that require a secure context. That is not unreasonable. It is also a reminder that the HTTPS layer I had already built was not just tidiness. It was a prerequisite. The infrastructure I had put in place earlier was now doing real work, quietly, in the background, making the next thing possible.

That is one of the things I keep noticing about this rebuild. Layers that seemed like they were about completeness turn out to be about capability. You build the foundation not because the foundation is the point, but because without it, the next thing cannot stand.

Authentication was the other small piece. Silverbullet supports a simple username and password passed as environment variables. That was enough. This is an internal service, sitting behind a reverse proxy, accessible only on my own network. I did not need a full identity provider. I needed a door with a lock, and that is what I put on it.

The first page I created was for anvil.

That felt like the right place to start. The host that runs the wiki should probably be the first thing the wiki knows about. I documented the hardware, the network, the Incus instances, the services. I documented what I had learned over the course of setting things up, including the parts that had required fixing before they worked properly.

It was a strange and satisfying feeling.

Not because the documentation was impressive. It was not. It was just accurate. But accuracy, in a system you are trying to trust, is its own reward. The wiki did not make the lab more capable. It made the lab more knowable. And a lab you can know is easier to extend, easier to maintain, and easier to hand back to yourself after a gap of weeks or months when memory has started to blur the details.

That is what I was really building.

Not a wiki. Not a notes system. Not a place to store markdown files.

A place where the things I have learned can stay remembered.