Category: Uncategorized

So you’ve stood up an LLM agent somewhere in the home lab. The demos make it look inevitable: plug it into everything, hand it a shell, and let the to-do list melt away. The instinct is to start with hands — restart this, resize that, deploy the thing. Resist it. The first thing your agent should do in your lab is look, and the honest way to make that happen is with skills whose entire job is reading state and explaining it.

There’s a nice shift happening in agent tooling that makes this easy. Agent runtimes — Hermes, OpenClaw, and friends — now have skill systems: packaged instructions plus small helper scripts that teach the agent how a particular system works. And thanks to shared hubs like the Hermes Skills Hub and ClawHub, a skill written for one lab’s Technitium DNS server or Proxmox cluster is often a one-line install for yours. Someone already wrote the glue. Your job is deciding what glue deserves to exist.

A skill is a monitoring probe that can explain itself

Reframe what a skill is and the whole safety question gets simpler. A read-only skill is a monitoring probe with a language model bolted on. Uptime Kuma pings your service and reports up or down. A DNS skill queries your resolver’s API and reports auth failures, zone warnings, and weird error spikes — and then, unlike the probe, it answers follow-up questions. “Which of these errors started first?” is where the agent starts earning its electricity.

Probes don’t need root, and neither do eyes. Before you install anything, run the runtime’s inspection commands and actually read what the skill claims to do:

hermes skills search technitium
hermes skills inspect technitium-dns
hermes skills install technitium-dns

The inspect step is the one people skip and shouldn’t. You’re about to hand a third-party package an environment variable with an API token in it. Look at what endpoints it calls, whether it’s read-only by construction or read-only by promise, and whether the install-time security scan flags anything. Thirty seconds of reading beats a week of regretting.

The three eyes worth installing first

Most home labs converge on the same three load-bearing systems, so the first three read-only skills pick themselves:

• DNS. It’s the lab’s nervous system. When something is “slow” or “broken,” half the time the real story is in the resolver: unreachable API, auth failures, zones with issues, unusual error rates. A skill that summarizes resolver health turns vague vibes into a diagnosis.
• The hypervisor. Node inventory, CPU and memory pressure, which guests are stopped, snapshot lists. Ask for a compact summary before you ask for anything deeper — “list my nodes and guests, show node CPU and memory, flag stopped guests, change nothing” is a perfect first prompt.
• Uptime monitoring. Your dashboard already knows what’s down; a skill lets the agent distinguish a current outage from a down-that-already-recovered, and line the timeline up against the other two eyes.

Notice what’s missing from that list: anything that mutates state. No container restarts, no snapshot creation, no DNS record edits. That’s not timidity — it’s sequencing. You can’t trust an agent’s hands until you’ve watched its eyes for a while.

The real payoff is correlation, not queries

Anyone can open three dashboards. The agent’s edge is holding all three in one context and answering the question you actually have at 7am: what happened overnight, and do I need to care?

So make the agent produce a briefing:

“Check my DNS server for auth problems, zone warnings, and error spikes. Summarize my hypervisor nodes: CPU, memory, any stopped guests. List monitors that are currently down versus down-and-recovered. Correlate timestamps. Read-only, no changes.”

The first few briefings will be mildly wrong in small ways — a service it miscounts, an alert it over-weights. That’s the point of the read-only phase: wrong answers cost you nothing but a correction. Every correction you make is training your own expectations about what the agent sees clearly and where it hallucinates confidence. That calibration is the actual product of week one.

Read-only is a property of the credential, not the prompt

Here’s the part worth internalizing: “keep this check read-only” in a prompt is a suggestion. The token in the environment variable is the contract. If your Proxmox credential can create snapshots, then so can the agent, no matter what the prompt says — a model under instruction drift, a confused plugin, or a malformed request will happily use every permission the token grants.

So scope the credential like you mean it:

• Proxmox: a PVEAuditor-style role, not root@pam.
• Technitium or TrueNAS: an API key restricted to read endpoints, in its own TECHNITIUM_URL / TRUENAS_API_KEY environment pair.
• Uptime Kuma: a viewer-level session, and if the skill only supports fuller access, accept that it can pause monitors and decide whether you’re okay with that.

The env-var pattern most skills use makes this pleasant: one token per skill, one line to rotate, one line to revoke. Treat tokens like the probes they feed — small, named, and individually disposable.

The ladder from watching to touching

Once the briefings have been reliable for a few weeks, you’ve earned the next rung, and only the next one:

• Observe. Read-only skills, scoped tokens.
• Correlate. Cross-system briefings on a schedule.
• Propose. The agent drafts the change — a snapshot plan, a compose fix, a DNS record edit — as a diff you review. It still can’t apply anything.
• Act. One narrowly-scoped write capability, on one non-critical system, with every action logged somewhere you’ll actually read.

Most labs will live happily on the first three rungs for months. The agents that get there fastest are the ones whose owners can point at a month of briefings and say “its eyes have been right every time.”

The boring briefing is the product

An agent in the lab succeeds the same way good monitoring does: by making the invisible boring. You’ll know the read-only phase worked when the morning briefing is a paragraph you skim in ten seconds and trust completely — and when something does go sideways at 2am, it’s the agent’s correlated timeline, not three browser tabs, that tells you why.

Inspired by 7 Hermes Agent Skills I’d Add to My Home Lab First over at Virtualization Howto — worth a read for the concrete skill list and CLI walkthrough.

Inspired by Umami — open-source web and product analytics.

Every small business site I’ve inherited has the same line in its <head>: a Google Analytics snippet someone pasted in 2019 and nobody has logged into since. It sits there slurping data into an account nobody checks, feeding a dashboard with forty reports, hanging a consent banner off the front of the site, and — the part that always gets me — costing actual page weight on every visit, on a service the site owner doesn’t control and can’t export anything useful out of.

Google Analytics is built for organisations with analysts. A tradie’s site, a consultancy, a hobby blog with delusions of grandeur: none of these need “explorations” or a predictive audience. They need four answers — is anyone here, where did they come from, what did they read, did that campaign work? — and they need them in ten seconds without a training course.

That’s the whole case for Umami, an MIT-licensed, privacy-first analytics platform you can self-host. No cookies, no personal data, no cross-site tracking — first-party aggregation only. It answers the four questions and declines to collect the surveillance surplus that creates the legal and ethical overhead in the first place.

Why “no cookies” is a bigger deal than it sounds

It’s not a values statement, it’s an operational one. Analytics that sets no cookies and stores no personal data doesn’t just feel cleaner — it removes the reason a small site drags a consent banner in front of every visitor. I’m not your lawyer and rules differ by jurisdiction, so verify your own obligations, but the banner exists to obtain consent for the tracking. Delete the tracking and the banner’s reason for existing goes with it. Fewer scripts, faster loads, nothing to consent to.

There’s a trust angle too: when a client asks “who has my visitors’ data?”, the answer becomes “me, in a Postgres database on hardware I control, and it’s page URLs and referrers, not people.” That’s an answer you can give without flinching.

One container and a database

The deployment is the kind of small a homelab barely notices. Umami ships a Docker image and a compose file that brings up the app with PostgreSQL:

docker compose up -d

The image is docker.umami.is/umami-software/umami:latest, the database wants PostgreSQL 12.14 or newer, and the first build creates your tables plus an admin account you should change the password of immediately. If you’d rather run from source, it’s a Node 18.18+ app with a one-variable .env — DATABASE_URL — and a build step. Behind your existing reverse proxy on some hostname like stats.example.com, it’s just another service in the rack. Updates are the usual dance: docker compose pull && docker compose up -d --force-recreate.

Instrumenting the site is one async script tag with a data-website-id. There’s no plugin to install, no tag manager to wrangle. If you can edit a template, you’re live.

What you get, and what you don’t

The dashboard is deliberately small: traffic over time, visitors, pageviews, top pages, referrers, countries, browsers and devices, plus events and UTM-tagged campaigns so “did the newsletter work” is a filter click instead of a research project. You can generate share links — a public, read-only view of a site’s stats — which is a surprisingly useful client-facing feature: send the link, skip the PDF export ritual every month.

What you don’t get is the deep end: session replay, funnels through twelve steps, cohorts, “AI insights”. If your business genuinely lives and dies on product-analytics funnels, run a product-analytics tool and pay for it honestly. But for the ninety percent of sites whose analytics questions end at “is the blog working, and where do people come from”, the deep end is a cost centre — in dollars, in complexity, and in privacy exposure.

One genuinely forward-looking detail: Umami has an MCP endpoint (off by default — enable with MCP_ENABLED=1 and an API key from Settings). That means your agent can query the analytics itself. “Ask the stats server how last week’s post did” becomes a tool call. On a homelab that’s already agent-shaped, that’s a nice little moat GA will never give you.

The honest trade-offs

• You own the uptime. If the container falls over, your stats stop recording. It’s a single service with one dependency — but it’s yours to monitor, back up and upgrade. Put it with the rest of your watched services.
• You own the data — including its loss. Back up the database. It’s one Postgres volume; snapshot it with everything else.
• Ad blockers still block it. Self-hosted analytics dodges most GA-specific blocklists but not all blockers. Treat numbers as trends, not censuses — which, honestly, is all GA ever gave you too.

Google Analytics is free the way a puppy is free: the purchase price is the smallest cost you’ll ever pay. For a small business site, Umami flips the model — a few hundred megabytes of RAM and a Postgres volume, in exchange for faster pages, no consent banner theatre, answers in ten seconds, and a stats database whose continued existence doesn’t depend on a product manager at a trillion-dollar company staying interested. That last one, historically, is the strongest argument of all.

Inspired by “Crafting Apps: thirteen open-source creative tools, built in Rust” (ArtCraft).

Every year or so, someone announces they’re going to replace Adobe with open source, and every year the announcement ages like milk. GIMP still opens with a dialogue about its old name, Krita is genuinely great if you paint, Inkscape’s exporters still fight you — and the suite-of-misfits problem never goes away: each app has its own shortcuts, its own file habits, its own ideas about what a toolbar is. So when a project called ArtCraft says it’s building thirteen creative apps from scratch — image editor, vector illustration, video editing, raw photo development, PDF workbench, motion graphics, page layout, interface design, word processing, audio workstation, presentations, CAD and spreadsheets — my first reaction was healthy scepticism.

My second reaction was that they’re not attacking the problem the way everyone else has, and the difference matters even if you never install a single one of these apps.

One stack, one language, no Electron

All thirteen apps are being written from scratch in Rust, compiled to native desktop apps for macOS, Windows and Linux — no Electron, no web views, no Chromium instances wearing an app costume. Each app also compiles to WebAssembly and runs in a browser tab, which sounds like a party trick until you remember what it means for deployment: the same codebase behind your desk and in a browser, with no porting layer between them.

The stated rules are consistent across the lineup: open source under permissive licences with the code on GitHub, files that stay on your machine (no cloud round-trip between you and your work), and layouts familiar to professionals who already know the incumbent tools. There’s a launcher that installs and updates the whole set, the way a package manager should have been doing this for a decade.

The sceptic’s caveat, stated plainly: most of the lineup is labelled “in development”, and the rest “early alpha”. Nobody should be cancelling an Adobe subscription over this today. Video editing, DAW work and CAD are famously brutal categories where the incumbents have decades of edge-case scar tissue. A from-scratch video editor is a five-year problem even when it’s the only thing you’re building.

The part that’s actually new

Here’s the line in their principles that made me stop scrolling: agent-ready. Every app is drivable from a CLI, a JSON control channel, or an MCP server — built for automation and AI agents from day one, not bolted on later.

Think about what that means in practice. A PDF tool you can drive from a script means “split these 40 invoices, stamp each with its filename, move them to the client folder” is a one-liner in your agent’s tool belt — no UI automation, no screenshot-driven hacks, no hoping the desktop app doesn’t steal focus mid-job. An image editor with a JSON control channel means batch-resizing, watermarking and exporting become part of a pipeline instead of a Tuesday morning of clicking. The MCP support means an agent you already run — the one that lives in your homelab and handles the boring chores — can operate these apps like it operates your file system.

This is the inversion worth paying attention to. The old open-source pitch was “same experience, zero dollars”, and it lost because the experience was never quite the same. The pitch hiding inside ArtCraft is different: software you can program beats software you can click, and the creative apps are the last major category where nobody’s seriously tried it. Commercial vendors won’t do this — scriptable creative apps cannibalise the seat licences that fund them. An open-source suite has no such conflict.

What a small shop should actually do

• Don’t migrate anything. It’s alpha software. Your production files deserve better.
• Pilot the utilities, not the exotic stuff. A PDF workbench and an image editor are low-stakes, high-frequency tools where an alpha is genuinely usable and an agent hook pays for itself immediately. A from-scratch DAW is not that.
• Watch the file formats, not the feature lists. The suites that die, die on compatibility. If these apps read and write the incumbent formats honestly (PSD, RAW, PDF/A, SVG, XLSX), they have a path. If they champion a new format first, they don’t.
• Steal the architecture even if you ignore the apps. If you build internal tools, “every app ships with a CLI, a JSON channel and an MCP server” is a principle you can adopt on Monday. Your future automation stack will thank you.

The bet, framed honestly

Thirteen simultaneous from-scratch rewrites is either monumentally ambitious or monumentally naive, and at alpha stage you can’t tell which from the outside. But the goalposts have moved. Five years ago, an open-source creative suite needed to win a beauty contest against polished commercial tools, and that was a losing game. Today it needs to be good enough to click and perfect to script — because the thing doing the scripting didn’t exist when the incumbents were designed.

That’s the shift worth tracking. The version of this story where it succeeds isn’t “free Photoshop”. It’s “an agent that lives on your NAS quietly processes every asset that touches your business, and the human only opens an app for the decisions that need taste.” Watch the launcher’s update notes, pilot a utility or two, and keep your files portable in the meantime.

Inspired by “My favorite Notion alternative isn’t OneNote or Obsidian: it’s more powerful and private” (XDA).

Every note-taking app I’ve used eventually asks the same question before it will accept a single sentence: where does this live? Which page, which database, which workspace, which of the three apps that each hold a third of your system? I’ve lost more thoughts to that decision than to forgetfulness. The thought arrives, the filing dialog opens, and by the time the thought has a home, it’s gone.

That’s the problem Memos solves, and it solves it by refusing to ask. It’s a self-hosted, capture-first note app: you type, it lands on a timeline, you get on with your day. Organization happens later — or never, which turns out to be fine more often than you’d think.

The filing tax

Notion is powerful, but it’s organize-first: you shape your workflow around its databases, and every capture starts with a filing decision. Obsidian gives you local Markdown files, which fixes ownership but not the decision burden — and once you add plugins and themes and CSS snippets, the vault itself becomes a project. OneNote is a notebook. All three tax the first two seconds of note-taking, which is exactly when you can least afford it.

Memos inverts the order. The timeline is the whole interface. You post first and structure emerges from what you actually captured — which, if you’re honest about your note-taking, is mostly one-liners: a command to look up, an app to try, a headline variant, something to check on a server. Not documents. Fragments.

One container, one volume

For a homelab, the deployment is about as small as self-hosting gets. An official Docker image, SQLite by default, one persistent volume:

docker run -d --name memos \
  -p 5230:5230 \
  -v /srv/memos:/var/opt/memos \
  usememos/memos:stable

Treat that as a sketch and check the current docs before you commit it to Compose — image tags and volume paths have changed between releases. Once it’s up, you open the port in a browser, create the admin account, and you’re running. No database server, no dependencies worth naming, nothing to babysit.

The backup story is the quiet best part: your entire instance is essentially one SQLite file in that volume. Snapshot it with your existing host-level backups and you’re done. Every note you own, in one file, on hardware you control — if you’ve ever had to export years out of someone else’s cloud, you know that’s not a small thing.

Tags do the filing for you

The trick that makes capture-first survivable is that structure is inline. You don’t file a memo into a hierarchy — you tag it as you type: #docker, #articleideas, #client/acme. Nested tags give you structure when you want it, search finds everything else, and the home page has a calendar view so “what did I do Tuesday” is answered visually.

The organizational debt doesn’t disappear, but it becomes optional and deferrable. Most of my memos never need promoting — they were valuable for a day and then they weren’t, and a timeline full of stale one-liners costs nothing. The few that matter get promoted on purpose.

Where it sits next to a vault

Memos is not an Obsidian replacement, and you shouldn’t ask it to be. It’s the intake layer. The pipeline that feeds this very blog starts as one-line captures; a capture tool that demands zero decisions is exactly the right shape for that job. The pattern that works:

• Capture everything to the Memos timeline, tagged loosely
• Promote weekly — the handful of memos with staying power become real notes or documents in your vault or repo
• Leave the rest on the timeline, where search still finds them

That division of labour beats either tool doing both jobs. Vaults are for thinking; timelines are for catching.

The honest limits

Memos won’t replace Notion for everyone. There are no relational databases, no board views, no complex team workflows — if your notes need structure stronger than tags and search, you’ll hit the wall fast. It’s not for long-form writing either; the editor is simple by design. There’s PWA support so it installs like a native app on phone and desktop, themes well past the usual light/dark pair, and you can publish individual memos as links — which makes a private instance double as a low-commitment microblog — but the scope stops deliberately at capture.

That restraint is the feature. The next time a thought shows up unannounced, the only thing between it and being saved is a text box. That’s how it should always have worked.

Inspired by “I replaced ChatGPT, Claude, Gemini, and Perplexity with free open-source alternatives” (XDA).

There’s a particular kind of dread that arrives with the fourth AI invoice of the month. ChatGPT Plus, Claude Pro, Google AI Pro, Perplexity Pro, a coding agent seat — each one defensible on its own, and together they quietly became a car payment.

Here’s the thing that finally pushed me to do something about it: those subscriptions overlap. Spotify and Canva solve completely different problems, so paying for both makes sense. But ChatGPT, Claude, Gemini, and Perplexity all do mostly the same jobs — they’re just marginally better at different corners of them. If you’re paying for several, you’re almost certainly paying for the same capability two or three times. That’s not a budget problem, that’s an architecture problem.

Audit the jobs, not the tools

Before cancelling anything, write down what you actually do with AI on an ordinary day. Mine came out looking like this:

• Drafting, rewriting, summarising — chat-shaped work
• Search that comes back with sources I can check
• A coding agent that can read a repo and make changes
• Quick visual assets — slides, one-pagers, mockups
• Research grounded in documents I supply

Notice what’s not on that list: “use Claude” or “use ChatGPT”. Brands are not jobs. Once the list is about jobs, you can ask a much sharper question per line: is this job ordinary enough that an open-source tool does it, or extreme enough that I genuinely need a frontier model? For most people, most of the week, it’s ordinary.

The chat habit: Jan

The chat-shaped 80% of my usage moved to Jan, and the change was smaller than I expected. Jan’s pitch is blunt — an open-source replacement for the ChatGPT desktop app — and the execution matches. You get conversations, projects, custom assistants with their own instructions, file uploads, and a model hub wired to Hugging Face, so you browse and download quantised models instead of hand-managing GGUF files and hoping your GPU can take it.

Two things matter more than the feature list. First, it speaks MCP, so the same tooling you’d point at a hosted assistant works locally. Second, it’s honest about being a frontend: it’ll happily talk to a dozen remote providers too. That’s the correct framing for the whole exercise — Jan is a client you own, pointed at models you choose. The model is a swappable part, not an identity.

Search with receipts: Vane

The reason I kept a Perplexity subscription was never the chat — it was answers with citations. Vane (formerly Perplexica) is that, self-hosted: a Docker deployment that runs its web search through a SearXNG instance and its reasoning through whatever model you point it at, including one on your own hardware via Ollama.

The good part is that the citations survive the move. You ask a question, you get a summarised answer, and you get the sources it drew from — which is the entire product, as far as I’m concerned. The modes are sensible too: something fast for throwaway questions, something deeper when you actually care. The honest part is the friction: this is a container stack you maintain, not a URL you type. If your Perplexity usage is five queries a month, keep the free tier. If it’s a daily habit and you already run a homelab, the marginal container is cheap.

The coding agent that doesn’t own you: OpenCode

This one stings if you’ve built muscle memory around Claude Code or Codex, because both are excellent — and both lock the agent to one vendor’s models. OpenCode keeps the parts of that workflow that actually matter (planning mode, skills, MCP support, real read-and-edit access across a project) and drops the exclusivity. Claude for the messy refactor where its context handling earns its keep, a cheap or local model for the boilerplate, and you stop paying frontier prices for jobs a small model does fine.

That routing instinct — match the model to the job, not the job to the subscription — is the whole game. It’s the same discipline as not running your CI on the biggest node in the cluster by default.

The remaining seats

Two smaller line items fell out of the same audit. For visual assets, Open Design does prompt-to-design (slides, prototypes, mockups) using whichever agent engine you already run, keeps the output as actual files, and lets you pin a DESIGN.md so assets follow your typography and colours instead of reinventing them per generation. For source-grounded research, Open Notebook covers the bulk of why I used NotebookLM — grounded chat, summaries, and podcast-style audio overviews of material I supply — and I’ve already written about it running it with a local LLM.

What I’d still pay for

None of this means subscriptions are a scam. There are weeks where frontier reasoning, very large context windows, or zero-setup polish genuinely earn the fee, and “free” tools cost you time and hardware like any self-hosted service does. The rule I landed on: cancel the overlap where the job is ordinary; keep paying only where the job is extreme.

Rerun that audit every quarter. The line between ordinary and extreme moves in your favour every few months — and the tools you own don’t invoice you for finding out.

Your app stack is a state-replication problem

Look at a typical productivity stack and you’ll find the same architecture failure ops people get paid to eliminate: state, copied everywhere. The task app keeps its copy, the notes app keeps another, the research tool holds its threads, and every “integration” is a fragile pipe working overtime to keep them vaguely in sync. Nobody would design this on purpose. So stop.

The setup that replaced most of my stack is two pieces: a folder of Markdown files, and an agent pointed at it (I use Claude Code; anything that can read and edit files safely will do). I landed here partly thanks to an XDA piece on running everything through Obsidian and Claude, and it matches what infrastructure work had already taught me: one source of truth, generated views, and a diff whenever anything changes.

The vault is the database

An Obsidian vault is just a folder of plain text files, which is the entire point. Frontmatter properties — status, priority, due date — behave like a row in a table. Wikilinks are relations. Even Bases, which presents itself as a full-blown database view, is a YAML file underneath, which means an agent can create or update one without ever opening the app.

This is the part people underestimate. Once your data is text, everything downstream becomes automatable, diffable, greppable and scriptable. The apps stop being systems of record and become views — and views are cheap.

Dashboards are generated, never hand-edited

The core trick isn’t note-taking, it’s regeneration. My project notes carry their own checkboxes and deadlines. An /index/ folder holds two generated files: this-week.md and stalled.md. When I ask, the agent rescans the vault, rebuilds both, and shows me a diff of what changed. A deadline I added to a design brief on Tuesday shows up in the weekly view on the next run, without anyone copying anything.

stalled.md earns its keep more than anything else in the vault. Every stuck item gets its blocker quoted from the note itself, and patterns leap out — when half your stall reasons turn out to be the same missing decision, no kanban board will tell you that, but a pattern-reading agent will.

The rules live in CLAUDE.md, where the agent can’t miss them:

## Project dashboards
- /index/this-week.md and /index/stalled.md are generated. Never edit by hand.
- Regenerate only when asked; always show a diff of what changed.
- An item is "stalled" if status is active and updated: is older than 7 days.
- When marking something stalled, quote the blocking text from the note itself.

What it actually replaced

• The task board. Deadlines and checkboxes live in the project notes they belong to; the weekly view is assembled from them. The board stopped being a place I maintain and became a place I read.
• The to-do app. Checkboxes in context beat a separate list of orphaned tasks I have to re-decode every time I look at it.
• Research tool threads. Research-heavy answers get saved as notes in a cache folder, and the agent checks the cache before going back to the source. Same answers, zero re-searching, and the good ones accumulate.
• Low-fi diagrams. Mermaid and Excalidraw are text. Version-controlled, diffable, living next to the notes they illustrate.

Where text honestly loses

Knowing the edges is what makes the rest of the setup trustworthy:

• Collaboration. No live multi-user editing on one file. If a doc needs a team poking at it, it goes to a real shared doc — the vault is mine.
• Notifications. A Markdown file never pings you. File-based scheduled tasks need a machine that’s awake. Phone reminders stay on the phone, full stop.
• Design. Notes can hold specs and links, but they can’t be the pixels. Figma stays.

Guardrails before you hand over the keys

An agent that edits files is an agent that can edit files wrong. Three rules keep it boring:

• Generated files are marked as generated, and the agent must show a diff — never a silent rewrite.
• The vault lives in git. Syncthing keeps devices current; git means an agent mistake is a revert, not a loss.
• Destructive operations (deletes, bulk moves) require asking first, every time, no matter how confident the agent sounds.

“File over app” isn’t a new idea — Steph Ango was writing it in 2023. What changed is that an agent can now do the transforming. The app stack doesn’t collapse because Markdown got prettier; it collapses because something finally does the chores.

Inspired by Claude and Obsidian now run every workflow I needed separate apps for (XDA Developers).

The five-dollar fix for hardware nobody is standing in front of

Every home lab eventually manufactures the same 2am problem: equipment that needs a finger, and nobody near it. A server wedged so hard that Wake-on-LAN won’t touch it. An air conditioner that only speaks infrared. A garage door whose manufacturer decided you were no longer the customer. None of this gear is broken — it just has an interface designed for a person standing directly in front of it.

The fix is to stand something in front of it for you. An ESP32 dev board costs less than a coffee, carries Wi-Fi and Bluetooth on the die, and — thanks to ESPHome — mostly doesn’t require writing firmware at all. I read a piece over on XDA that surveys several of these gadget revivals, and it’s a good tour. But I’d push the framing further for home lab people: the ESP32 isn’t a hobbyist toy, it’s remote hands. It is the cheapest out-of-band management you will ever buy.

Buy for the drawer, not the project

First mistake everyone makes: “an ESP32” is a family, not a chip. The original ESP32, the S3, the C3 and the C6 all carry the name and they are not interchangeable — different radios, different capabilities, and only some of them do the things a given project assumes.

• Classic ESP32 (WROOM/WROVER modules): the safe default, and the only variant with Bluetooth Classic. That matters for audio projects and some legacy tinkering.
• S3: more RAM, native USB, the one to grab for anything driving a screen.
• C3/C6: cheaper and smaller. Fine for sensors and blasters, wrong for Bluetooth Classic audio.

My advice is boring and I stand by it: buy five classic dev boards, put them in the drawer, and stop optimising. For things that get sealed into walls and ceilings, standardisation beats every other virtue.

Second: skip the soldering iron if you want. Pre-built modules exist for nearly everything below — IR transmitter boards, optocoupler breakouts, the works — and ESP Web Tools lets you flash firmware straight from a browser tab. The barrier to entry here is genuinely just willingness.

The project that pays for the whole drawer: a remote power and reset button

A PC’s power button is not magic. It shorts two pins on the motherboard’s front-panel header. Reset does the same on its own pair. The power LED is just a signal waiting to be read. Wire an ESP32 to those points through optocouplers and you can press the button from your phone, hold reset for five seconds, and — critically — know whether the machine is actually running.

This is the feature Wake-on-LAN pretends to cover. WoL handles “off”. It does nothing for “hung with the fans at 100%”, which is the failure mode that actually ruins nights. A reset you can press remotely plus a sensor reporting power state is out-of-band management, home lab edition, for about ten dollars.

The optocouplers matter more than people credit: they keep the ESP32 electrically isolated from the motherboard, so a wiring mistake costs you a five-dollar board instead of a motherboard. In ESPHome the whole thing is a configuration file, roughly:

# Remote finger for a server's front panel
switch:
  - platform: gpio
    pin: GPIO26          # opto across the PWR_BTN pins
    id: power_button
    name: "${hostname} power button"
    restore_mode: ALWAYS_OFF
    on_turn_on:
      - delay: 300ms     # roughly a human press
      - switch.turn_off: power_button

binary_sensor:
  - platform: gpio
    pin:
      number: GPIO33     # opto across the power LED header
      inverted: true
      mode:
        input: true
        pullup: true
    name: "${hostname} powered"
    device_class: power

One caveat the blog posts skip: the ESP32 needs power while the PC is off. Give it its own USB charger, or use a motherboard port that stays live in standby. Otherwise your remote hands go dark at exactly the moment you need them.

Infrared: making dumb appliances honest

Anything that obeys a remote control has an API — it’s just line-of-sight and one-way. An IR LED (or a two-dollar transmitter module) plus a receiver to capture the original codes, all through ESPHome, turns a non-smart air conditioner, fan or TV into something Home Assistant can automate. The aircon starts following a schedule instead of a habit; the TV volume can dip when a call starts. No cloud account, no vendor app, nothing phoning home to a company that will one day turn the whole thing off.

The garage door, back under local control

In late 2023 Chamberlain cut off third-party access to its MyQ platform, and Home Assistant’s response was instructive: rather than fight it, they removed the integration and pointed everyone at ratgdo. The ratgdo32 is an ESP32-based board that wires to the same low-voltage terminals as your wall button — and it speaks Security+ 2.0 natively. That detail is the whole game: on newer Chamberlain and LiftMaster openers the wall button isn’t a switch at all, it’s a serial device, and a dumb relay across the terminals achieves nothing. With ratgdo32 you get the door, the light, the lockout, and obstruction sensor status — locally, permanently, no subscription.

The one I’d skip

Bluetooth audio. It sounds like a perfect match — old speakers, new phone — but only the classic chip does Bluetooth Classic, the friendly firmware (Squeezelite-ESP32) wants 4MB of PSRAM, so you’re shopping WROVER modules, and the realistic ceiling is “acceptable in a kitchen”. If you want whole-home audio, buy proper gear once. Don’t spend three weekends teaching a five-dollar chip to almost do it.

The pattern worth taking away

The unifying idea is bigger than any single project: if a device has a button or a blinking LED, it has an interface, and a five-dollar board is the adapter between that interface and your network. Most “smart home” spending goes to buying new endpoints. The better trick is usually to keep the endpoint and replace the access.

Inspired by 4 forgotten gadgets an ESP32 can resurrect on the cheap (XDA Developers).

Jira fatigue is the most universally shared feeling in software teams, and yet almost everyone keeps paying for it, because the alternatives all seem to cost something scarier than money: a migration. Plane — the open-source project management platform behind the makeplane/plane repo — is worth a look precisely because it lowers that second cost: it’s an AGPL-3.0 licensed Jira/Linear/Monday alternative that runs from a Docker Compose file, imports your Jira projects, and treats self-hosting as a first-class deployment path rather than an enterprise upsell.

First, the uncomfortable truth about trackers

Your issue tracker is consensus software. Its value isn’t the feature list; it’s the fact that everyone agrees to put work in the same place. That’s why teams endure tools they complain about — switching costs aren’t technical, they’re social. So before evaluating any Jira alternative, apply the exit test: can you get your data out, in a form the next tool can read? A tracker you can’t leave isn’t a tool, it’s a lease.

Self-hosting an open-source tracker is the strongest possible answer to that test. The data lives on your disk, in your database, exportable whenever the consensus moves on.

What Plane actually is

Strip the positioning and Plane covers the working core of a modern tracker:

• Work items with a rich-text editor, file uploads, sub-properties and cross-references between issues.
• Cycles — sprints, in Plane’s vocabulary — with burndown charts and progress tracking.
• Modules for grouping large efforts into shippable chunks.
• Views — saved, shareable filters, which is how a small shop runs “my queue”, “client A’s requests” and “this quarter’s roadmap” from one dataset.
• Pages for docs and notes, convertible into work items.
• Analytics across all of the above.

That’s not a laundry list of everything Jira does — it’s the 20% a small team uses daily, without the administration tax. Plane’s own comparison page also pitches AI agents and MCP integration for the AI-assisted workflow crowd; I’d treat that as direction-of-travel rather than a reason to adopt.

Self-hosting is the point

Two deployment paths are documented officially: Docker Compose for the one-box crowd, and Kubernetes for the rest of us. The Compose path is the usual shape — a setup script that generates your environment file, then docker compose up -d — and Plane lands as a set of containers alongside whatever else your box runs. Instance administration happens through what Plane calls God mode, the instance-admin surface where you manage settings, users and upgrades. For a homelab or small business, that means the tracker joins Uptime Kuma, the reverse proxy and the rest of the rack as just another service with a health check and a backup job.

The licence deserves one paragraph of honesty. AGPL-3.0 means that if you modify Plane and offer it as a service to others, you owe those users your source changes. For internal use — which is what most of us are doing — it’s simply free software with strong copyleft. Read it before you fork it into a product, ignore it comfortably for a team workboard.

When you shouldn’t do this

• If nobody will own the box. A self-hosted tracker still needs patching, backups and an upgrade cadence. If your team has no one who wants that pager, use Plane Cloud or pay Atlassian — an unmaintained tracker is worse than a rented one.
• If you’re welded to the ecosystem. Teams whose processes live in Jira plugins, Insight asset management or deep Confluence integrations will feel every missing edge on day one. The Jira import moves your issues, not your muscle memory.
• If the team is you and a cat. Trackers earn their keep at three-plus people with overlapping work. Solo operators need a note file and a calendar, and that’s fine.

The pattern I’d run

For a small operation — an MSP tracking client work, a five-person shop running sprints, a homelabber organising builds — the shape that works is one instance, two workspaces: internal work in one, per-client request queues as saved Views in another. Every piece of client work becomes a work item with a cycle, a module and an owner; Pages hold the runbooks; the burndown chart is the status report nobody has to write.

And because it’s your database, the exit test is always passing: pg_dump and you own your history outright.

Jira fatigue doesn’t need a better SaaS — the market is full of them. It needs an option where leaving is cheap and the data is yours. That’s the whole pitch of self-hosting Plane, and it’s a weekend, not a quarter, to find out if it fits your team.

Thunderbolt 5 docks have spent their first year priced like the laptops that need them. So the interesting thing about Engadget’s review of Keychron’s first dock isn’t the 8.3/10 — it’s that a keyboard company just shipped a genuinely sensible TB5 dock for $349, undercutting CalDigit and Anker’s $399 by fifty dollars while matching them where it counts. That’s the sound of a premium category turning into a normal one, and it’s worth understanding what you’re actually buying before the desk upgrade impulse takes over.

What Thunderbolt 5 actually buys you

TB5 is Intel’s latest shot at the one-cable desk: 80Gbps of symmetric data (with a 120Gbps boost mode when you need display bandwidth more than upload), enough power delivery to charge any laptop made this decade, and daisy-chaining that doesn’t fall over. In practice, the numbers that matter to a homelab desk are simpler:

• 140W upstream charging — one cable replaces the laptop brick permanently.
• 80Gbps — an external NVMe enclosure over TB5 stops being the slowest disk on the desk.
• Headroom — dual high-resolution displays and fast storage and networking at once, without the bandwidth arithmetic USB4 hubs make you do.

If your machine doesn’t have a TB5 (or at least TB4/USB4) port, none of this applies — a $60 USB-C hub is the honest answer, and no dock fixes a laptop that can’t take one.

Keychron’s port math

Fourteen ports, arranged the way someone who uses a desk would arrange them. Front: three 10Gbps USB 3.2 ports (two A, one C — I’d have preferred two C), full-size SD plus microSD slots where you can actually reach them, and a 3.5mm jack with a real audio interface inside, inline mic support included. Rear: three Thunderbolt 5 ports (one upstream, two downstream for SSDs or displays), two more USB-A, 2.5Gb Ethernet, a Kensington lock, and — the headline — two HDMI outputs.

The build is the quiet win. CNC-cut aluminium panels double as heatsinks, so it runs fanless and silent, and rubber feet on two sides let you stand it upright or lay it flat. Engadget’s reviewer notes you can insert a microSD card one-fingered without the dock sliding — a small thing that cheap docks reliably get wrong, and a tell that the manufacturer has actually used the product.

The catches that should shape your decision

No dock is perfect, and three of this one’s imperfections matter for our kind of desk:

• HDMI tops out at 4K/60. For higher resolution or refresh, you’re meant to use a Thunderbolt port for the display — which spends one of only two downstream TB5 ports. Dual HDMI is the differentiator, but it’s a 4K/60 differentiator.
• macOS multi-display quirk. macOS doesn’t natively drive multiple displays over a dock’s HDMI pair — both mirror. Mac users get one HDMI plus one TB display and change; Windows handles dual HDMI fine. Check your OS before the port count sells you.
• 2.5GbE, not 10GbE. For a homelab desk where the storage network is the point, this is the real miss. If your switch is 10G and your NAS is 10G, the dock’s Ethernet becomes your bottleneck the day you plug in.

No internal SSD bay, either — Razer’s $379 Chroma has one — though that’s a convenience trade rather than a capability one, given the downstream TB5 ports.

The field at $350

Every rival is a variation on the same theme: CalDigit’s TS5 ($399) is the incumbent favourite but drops HDMI entirely; Razer’s TB5 Chroma ($379) adds the SSD bay and RGB, also no HDMI; Anker’s Prime TB5 ($399) matches Keychron’s spread but swaps the second HDMI for DisplayPort and hides the SD slots on the side. Keychron’s dual-HDMI-plus-front-cards combo is genuinely the most desk-practical arrangement of the lot, and it’s the cheapest of them. Whoever thought the keyboard company would be the one shipping “boring and correct”?

Should a homelab buy it?

My checklist, having watched this category for a while:

• Yes if you run a TB5/TB4 laptop as your main machine and want the one-cable desk: power, dual 4K displays, storage, and Ethernet from a single plug, fanless, $349.
• Yes if you juggle a laptop and a desktop at the same desk — one dock, two computers, standardised cabling.
• Wait if your LAN is 10G today or planned — 2.5GbE is the dock’s weakest port, and it’s the one a homelab actually stresses.
• Wait if you’re on macOS and want two dock-driven displays; the mirroring quirk takes the headline feature off the table.

The bigger picture is the one I’d bank: this is the second piece of desk infrastructure in a month where the budget option stopped meaning compromise. First universal docks made us the QA team; now the good stuff is getting cheap enough to be the default recommendation. Buy when the specific port map matches your desk, not when the discount does.

Every Windows homelabber’s taskbar tells the same story: PuTTY for the shell, WinSCP for the files, a notes file with the ssh -L command you copy every time you need to reach a loopback-bound service. None of those tools is broken — PuTTY has been quietly excellent since the late nineties — which is exactly why nobody ever consolidates. MakeUseOf’s piece on replacing all three with one app finally pushed me to spend an evening with Submarine, an MIT-licensed SSH client that organises the terminal, the file browser and the tunnels around a single saved server.

The problem isn’t the tools — it’s the context

Watch what actually happens during routine server work. You SSH in, poke around, realise you need to pull a log file down — so you open WinSCP and re-enter the same host, user and key you just authenticated with. Ten minutes later you need the admin page of a service that’s bound to 127.0.0.1 on the remote box, so you dig through shell history for the forwarding command you used last month.

Nothing here is hard. It’s all friction of the worst kind: small, repeated, and paid every single day. The server’s identity lives in three different places, and only one of them remembers it. Submarine’s core idea is that the saved server should be the workspace, and the terminal, SFTP browser and port-forwarding rules should all hang off it.

What you get around one saved server

Add a machine once — hostname, port, user, key or password — and everything else inherits that context:

• Terminal: multiple shells to the same host in tabs, reconnects without rebuilding the session. Covers the PuTTY routine.
• SFTP: a split view with local files on one side and the remote filesystem on the other, with transfer progress in-panel. Covers most of the WinSCP routine, including rename, move, delete, permissions and file properties.
• Ports: local, remote and dynamic forwards — the equivalents of ssh -L, ssh -R and ssh -D — saved as rules under the server profile, each startable and stoppable on its own.

Two details deserve called out because they’re where client authors usually cut corners. First, credentials and saved servers live in a password-protected encrypted profile rather than the registry or a plaintext file. Second, the first connection surfaces an ED25519 host-fingerprint prompt and remembers your acceptance — proper TOFU (trust on first use) behaviour, and the fingerprint matches what OpenSSH shows you, which is a nice cross-check against a miscreant DNS entry.

The two features that earn the install

Remote editing with auto-upload is the sleeper feature. Pick “Edit” on a remote config file, and Submarine hands a temporary copy to your normal local editor; when you save, it uploads the changed file back. Fix a docker-compose.yml or an nginx site config in your real editor, then cat it from the adjacent shell to confirm — no manual download/edit/upload dance.

The other is tunnel rules as first-class objects. The classic homelab recipe works exactly as you’d hope: a service bound to 127.0.0.1:8765 on the server, a local forward listening on localhost:8080 on your desktop, and the admin page appears in your browser over the encrypted SSH channel. Because the rule is saved under the server profile, the tunnel you needed last Tuesday is two clicks away instead of a history search. Database admin pages, Grafana, dev servers, NAS interfaces — anything you deliberately didn’t expose publicly — all become reusable bookmarks.

Beyond the big three, an Info panel surfaces CPU, memory, storage, network and listening ports, and a Docker panel handles containers, logs and shells. Neither replaces htop or docker ps for serious work, but they’re the right shape for a glance while you’re already in there.

The honest caveats

Submarine is a v0.x project, and it shows in one place you can’t ignore: the Windows build is unsigned, so SmartScreen will warn on install. The project documents this honestly, but an unsigned binary for a tool that holds your SSH credentials is a genuine consideration — verify the source, or build it yourself, and keep the encrypted profile behind a real password.

It’s also not WinSCP’s equal in depth. If your workflow leans on WinSCP’s synchronisation and scripting automation, or you have a meticulously tuned PuTTY session library, there’s no shame in keeping them. And terminal-native folks should note that Windows Terminal plus OpenSSH’s ~/.ssh/config already solves portability and forwarding for free — Submarine’s case is the GUI around it all, not raw capability.

Who should switch

My decision list after a week with it:

• Switch if your daily rhythm on Windows is shell → grab a file → open a tunnel, especially across several servers or client boxes.
• Switch if you support less terminal-fluent colleagues — saved servers with tunnels they can click are safer than a shared cheat sheet of forwarding commands.
• Stay put if you live in tmux on Linux, script everything, or need WinSCP-grade sync jobs.
• Either way, hold any client you adopt to the same bar: encrypted credential storage, host-key pinning, and tunnels saved per-server. Those three are non-negotiable in 2026.

The tool didn’t teach SSH anything new — it just stopped pretending the terminal, the files and the tunnels were three separate relationships with the same machine. That reframing is worth more than any feature list.