03 / Self-hosting · Everyday learning
The useful things, and the rabbit holes
Running my own services is a way to learn about maintenance, recovery, and the small conveniences worth looking after.
- Status
- In use personally / evolving
- My contribution
- Configured, integrated, and operated with AI assistance
- 01Choose a small need
- 02Configure & test
- 03Observe & maintain
- 04Practice recovery
If I change this today, how do I get back to yesterday?
Useful is allowed to be ordinary
Photos I can browse, media I can watch, and small automations that connect things I already use. That is plenty of reason to run a homelab. Sometimes the reward is a convenience. Sometimes it is understanding a little more about how a service works.
I configure, integrate, and maintain these systems with AI assistance. I did not write Docker, Immich, Plex, or the other applications. Choosing how they fit together and looking after them is its own kind of hands-on work.
One build: finding my way back to a conversation
Alongside the off-the-shelf services, I have been building a personal dashboard around recorded notes. A FastAPI application and SQLite index connect recordings, transcript search, action items, and follow-ups. Tasks retain a connection to their source recording so there is a route back to the original context.
Conceptual source-to-action flow. No real meeting content is shown.
PLAUD provides the recording and export functionality. The dashboard and integration are an AI-assisted personal build, not an official PLAUD product or an employer CRM. The interesting part for me is making the next action inspectable without losing the conversation behind it.
The limit is part of the design
An AI answer can use only part of the available context. In this dashboard, chat draws on a bounded selection of recent material and matching transcript snippets. It is not exhaustive recall, and model calls mean it should not be described as fully offline. I still need to check a summary against the source.
The maintenance question
Before an update, I want to know what depends on the service and how I would return to the previous state. A running container is only one check. The application also needs to contain the expected data and work from the path a person actually uses.
A small service-care checklist
- Understand the dependency before changing it.
- Preserve configuration and data that would be difficult to recreate.
- Make one bounded change.
- Check the application, not just the process.
- Keep a recovery path and a note explaining what changed.
What I get out of it
There is always another thing to try. Keeping the lab useful means deciding which experiments are worth maintaining, and being willing to retire the ones that no longer are. Not every rabbit hole needs to become a service.