Hansen IT Solutions

The problem with giving strangers your real address

Every vendor trial, every forum, every “enter your email to download the datasheet” form is a small gamble. Plus-addressing (gary+vendor@example.com) is the usual compromise, and it works — until the day one of those vendors strips the tag and sells the address anyway. Now your real domain is on a marketing list that outlives the vendor. The other option, a public temp-mail service, is worse: the inbox is shared with everyone else using it, the domains are on every blocklist in existence, and the mails sit in someone else’s logs until their retention policy says otherwise.

There’s a third option that homelab people keep sleeping on: run the disposable address service yourself, on a domain you control and don’t otherwise care about. OpenTrashmail caught my eye because it’s the rare mail-adjacent project that doesn’t demand a week of your life. It ships its own mail server — a Python SMTP daemon — plus a web UI, and it stores everything as flat files. No Postfix, no Dovecot, no database. That’s the right amount of mail server for a job that’s supposed to be disposable.

What it actually does

OpenTrashmail is a catch-all inbox for a domain you point at it. You set an MX record, expose port 25, and from that moment every address on the domain works — vendorx@burn.example.com, random-nouns@burn.example.com, anything. Nothing to pre-create. Mails land in a web UI with attachments, dark mode, per-address RSS, and delete buttons.

The parts that matter more than they first appear:

• JSON API and RSS for every address. You can script “give me the newest message at this address” — which turns throwaway email from a manual chore into plumbing.
• Webhooks, global or per-address, signed with HMAC-SHA256. A mail arrives, your automation hears about it.
• 100% file-based storage. The data directory is one bind mount. Backing up a burner-mail service is rsync, not database dumps.
• Retention is built in (DELETE_OLDER_THAN_DAYS), so the whole thing can be self-cleaning.

Why this beats the temp-mail sites

Public temp-mail domains get blocked because they’re public. Your domain gets blocklisted the same way only if you publish it — so don’t. Use it exclusively for your own sign-ups, never paste its addresses into forums, and pick a domain that isn’t your main one. The trade is: a little DNS discipline in exchange for addresses that (a) actually pass sign-up forms, (b) aren’t readable by every other temp-mail user, and (c) can be burned per-vendor because there’s an infinite supply.

The privacy argument is the one I care about most. A throwaway address that routes through someone else’s server isn’t throwaway — it’s theirs. Mine rides a mail daemon whose logs I own, on a box in my rack, and when I nuke the data directory nobody keeps a copy.

Setup: one record, one container

DNS first. Point an MX at a host that runs the container:

mail.burn.example.com.  IN A    203.0.113.10
burn.example.com.       IN MX 10 mail.burn.example.com.

Then the container. This is close to what I’d run in production — daemonised, persisted, domain-restricted, with cleanup:

docker run -d --restart=unless-stopped --name opentrashmail \
  -e DOMAINS="burn.example.com" \
  -e SMTP_HOSTNAME="mail.burn.example.com" \
  -e DISCARD_UNKNOWN=true \
  -e DELETE_OLDER_THAN_DAYS=90 \
  -e PASSWORD="something-long" \
  -p 80:80 -p 25:25 \
  -v /srv/opentrashmail/data:/var/www/opentrashmail/data \
  hascheksolutions/opentrashmail:1

If you want subdomain-tagged addresses per vendor family — shopping@retail.burn.example.com — a wildcard MX plus DOMAINS="*.burn.example.com" gets you there. Cute, optional.

The two settings that keep you off blocklists

Here’s where I’d slow down, because this is the part that separates “fun weekend service” from “career-limiting DNS incident”.

Set DISCARD_UNKNOWN=true. With it off, the server accepts mail for any domain, which to the outside world looks exactly like an open relay — the kind of thing that gets your IP onto blacklists your real mail will then suffer for. With it on, the server rejects foreign recipients during the SMTP dialog like a well-behaved MTA.

Host the web UI somewhere else. The project’s own advice is right: put the UI on a different domain than the one receiving mail, guard it with PASSWORD or ALLOWED_IPS (or hide it behind your reverse proxy with auth), and set SMTP_HOSTNAME to match your MX with a matching PTR record. Add STARTTLS with a Let’s Encrypt cert — a mail host that offers no TLS in 2026 looks sketchy to senders and spam filters alike. None of this is hard; it’s just ten minutes of care that most “quick SMTP in Docker” tutorials skip.

The trick that makes it more than a toy

The moment this stopped being a novelty for me was the JSON API. Disposable addresses plus a scriptable inbox equals automated email round-trips: sign up for a service from a script, poll /json/<address> for the confirmation link, done. The project docs even pitch it for capturing 2FA mail programmatically — I’d keep that inside the lab boundary only, because anything that auto-reads auth mail from a shared-ish surface deserves a long think first. But for test environments and CI that need to verify “the mail actually sent”, it’s excellent glue. Webhooks push the same idea further: a signed POST per message, straight into n8n, a Discord channel, or a small receiver script.

There’s also a quiet honeypot mode: set an ADMIN catch-all address and every message to every address is visible from one login. For a lab network where everything is yours anyway, that’s a feature; for anything multi-user, it’s a footgun. Know which one you’re running.

The small business angle

If you run IT for a small outfit, this pattern earns its keep without touching customer data: procurement portals, vendor trials, webinar registrations, “create an account to see the price” — all of it can go to per-vendor burner addresses on your domain. When the marketing spam starts, you know exactly who leaked, and you delete the address instead of unsubscribing from eleven lists. Combined with the retention setting, the data you’re keeping is close to none — and as I keep saying about breaches, mail you no longer have cannot be dumped.

Verdict

OpenTrashmail nails a narrow brief: disposable inbound mail with zero ceremony. It will not replace your mail server, and you shouldn’t ask it to. But as a purpose-built burner domain that you own end to end — scriptable, self-cleaning, one container — it’s earned a slot on my “runs forever, never think about it” list. Give it a spare domain, harden those two settings, and stop handing your real address to strangers.

The screen nobody fights over

Every home lab eventually has a drawer of shame: the $25 monitor that came free with something, the first-gen Pi you swapped out two upgrades ago, an HDMI cable of unknown provenance. The individual parts are worthless; the combination is the most-watched screen in the house — if you put them together as a family dashboard. A writer at XDA did exactly that this week, wiring a forgotten monitor and a Raspberry Pi 4 into a shared screen for chores, meals, calendars, and photos. It’s the right idea, and it deserves a harder look than the parts list — because the hardware is the easy 10% of the project.

Why family dashboards die

Not from hardware failure. From update friction. A dashboard is a promise that the screen will keep telling the truth — today’s calendar, this week’s chores, tonight’s dinner. The moment changing any of that requires SSH, the countdown starts. Within a month, the dashboard is a photo frame; within three, it’s a black rectangle the family has learned to ignore.

So my rule: if updating the screen needs a terminal, it’s already dead. Design for that from the first boot and the project survives. Ignore it and you’ve built a very expensive clock.

This is also why “just build it as a web page and open a tab” fails. A tab is not an appliance: it closes, it updates, it logs out. The dashboard has to be the only thing the machine knows how to do.

The build is two decisions, not twenty

• Screen: the worst HDMI monitor you own. Not-touch is fine. Big text fixes more UX problems than touch does, and the remote control is everyone’s phone anyway.
• Brain: whatever Pi is in the drawer. A Pi 4 with 1GB ran the XDA build at ~50% memory — no mini PC needed. A lightweight OS (DietPi is a good default; it idles under a few hundred MB) leaves the whole machine for one Chromium window.

Do not buy a touchscreen for version one. Buy it for version three, after the family has told you what they actually reach for. My experience with kiosk builds is that the features you’re sure they’ll want get ignored and the boring ones — the clock, the calendar, tonight’s meal — carry the whole device.

Kiosk mode, and the Wayland trap

The dashboard tool I’d point at here is Home Screens: custom pages, a proper web portal for layout, and — crucially — a separate portal just for content edits. But the software is only half the kiosk. The other half is making the OS boot into a fullscreen browser and nothing else.

On a Pi, that means an autostart entry or a small systemd service that launches Chromium fullscreen, incognito, pointing at the dashboard URL. Something like:

[Unit]
Description=Dashboard kiosk
After=network-online.target

[Service]
User=kiosk
Environment=DISPLAY=:0 WAYLAND_DISPLAY=wayland-0
ExecStart=/usr/bin/chromium-browser --kiosk --incognito \
  --noerrdialogs --disable-infobars \
  http://localhost:3000
Restart=always
RestartSec=5

[Install]
WantedBy=graphical.target

Two lessons that will save you an evening. First, the XDA author’s build crashed on boot — UI up for two seconds, dead, restart, repeat — because the kiosk was launched into a session layer (Wayland) it wasn’t configured for. If you see a crash loop, suspect the session before the app: launch the browser the way the project’s own installer does, into the session the project documents. Second, Restart=always with a short backoff is not optional. A kiosk that shows a black screen after a browser crash until someone reboots it has failed the appliance test.

Two doors into the dashboard

Home Screens’ smartest design decision is that it has two doors. The builder portal (port 3000) is for the person who makes pages. The content portal (the same URL plus /remote) is for everyone else: chores, meal plans, users, photos, screen brightness, sleep and wake — all editable from a phone, none of it able to break the layout.

That separation of powers is what keeps the screen alive. The family gets a door with no sharp edges; you keep the dangerous one. It also gives you the feature nobody knows they need until it works: alerts on the big screen. A persistent or timed message when someone forgets a chore is nag-as-a-service — off your back, onto the furniture.

Feed it things that update themselves

A dashboard’s content pipeline splits into two kinds, and they age very differently:

• Self-updating: calendar (iCal links), weather, photo carousel via an API. These never rot.
• Hand-fed: chores, meals, lists. These rot in days unless the editing door is genuinely easy.

Maximise the first, make the second a one-tap phone job, and skip anything in between. A card that needs a weekly manual export will be the first thing the family notices is wrong.

Run it like a service, because it is one

This machine has the most public SLO in your house. Everyone can see when it’s down. So give it the boring production treatment:

• Auto-restart everything — the browser session at minimum, and a read-only-ish SD card setup so a power cut at 6am can’t corrupt it.
• Boot to dashboard after power loss — no login, no desktop, straight to the kiosk.
• Sleep on a schedule — dim or blank overnight via the content portal or DPMS; a 24/7 bright panel in a hallway is how projects get unplugged.
• One-line health check — if you already monitor services (and if you’re reading this blog, you do), curl -f http://pi:3000 from your uptime monitor tells you the dashboard is serving, which is 90% of “the screen is fine.”

The small-business version is the same build

Swap the family content for ops content and this is a reception screen or a warehouse status board: today’s schedule, a Grafana or Glance page, the on-call rotation, the shipment board. The rules carry over unchanged — worst screen you have, kiosk boots to one URL, auto-restart, and a content door a non-technical person can use without calling you. Every client site has a wall; most of them are showing a screensaver because nobody treated the wall screen as a service.

The best screen is the one already paid for

The economics of a junk-drawer dashboard are unbeatable: zero dollars, one evening, and the family’s shared context stops living in four different apps. The XDA piece is a good build log — read it for the DietPi and kiosk details. But the parts list isn’t the lesson. The lesson is that the screen survives on maintenance design: two doors, self-updating feeds, restart-on-failure, and a phone-sized path from “tonight’s dinner changed” to the wall. Build those in, and the cheapest screen in the house becomes the one nobody can live without.

Agent skills — the markdown instruction files that teach a coding agent how you want things done — have quietly become real infrastructure. Claude Code keeps them in ~/.claude/skills/, Cursor in ~/.cursor/skills/, Codex in ~/.codex/skills/, Amp in ~/.config/amp/skills/, and there’s now a cross-tool convention forming around ~/.agents/skills/. Use more than one agent, as most of us now do, and your hard-won procedures are smeared across five hidden directories in two different file formats, with no way to find the one you wrote last March.

Chops is a free, open-source macOS app by Shpigford that treats this as what it actually is: a dotfile management problem. One window, every tool’s skills and agents, and an editor. It’s a small app doing an unglamorous job, which is exactly why it works.

What it does

• Discovery across tools — scans the skills and agents directories for Claude Code, Cursor, Codex, Windsurf, Copilot, Aider, and Amp, plus any custom paths you point it at.
• A real editor — monospaced, Cmd+S to save, frontmatter parsed and displayed, so you’re editing the file where it lives instead of round-tripping through a terminal.
• Full-text search — across names, descriptions, and body content. Six months in, this is the feature you’ll open the app for.
• Collections — group skills into logical sets without moving or rewriting the source files. Non-destructive by design.
• Per-tool boilerplate — creating a new skill generates the correct skeleton for whichever agent it targets, frontmatter included.
• File watching — FSEvents-based, so edits made outside the app show up instantly.
• Registries and remotes — browse and install from the skills.sh registry, and connect to remote servers running OpenClaw or Hermes to discover and install skills living on other machines.

The feature that matters most is the symlink

Buried in the README is the detail that makes Chops more than a file browser: skills are identified by their resolved symlink path. Symlink the same file into multiple tools’ directories and Chops shows it once, badged for each tool it serves. That’s not a dedup gimmick — it’s the correct architecture for this problem, and it’s the part you should steal even if you never install the app:

git clone git@github.com:you/agent-skills.git ~/agent-skills
for tool in claude codex cursor; do
  mkdir -p ~/.${tool}/skills
  ln -s ~/agent-skills/release-checklist ~/.${tool}/skills/release-checklist
done

One canonical copy in a git repository, one symlink per tool. Edit the skill once, every agent sees the update, and your procedures get a changelog for free. The honest caveat: agents don’t all accept identical skill formats — Cursor uses .mdc files, others use markdown with frontmatter — so some skills will need thin per-tool wrappers. That’s still vastly better than five divergent copies edited by hand.

An ops-flavoured review

What I like: it reads files where they are instead of importing them into its own database-shaped world, the collections never touch source, and the search is fast. What you should know before granting it access: Chops deliberately ships with the macOS sandbox disabled, because reading dotfiles across your home directory is the entire job. Defensible, but understand you’re handing an app unsandboxed filesystem access — fetch it from the GitHub releases page, not from a mirror. And it’s a young project with no automated test suite; validate what you care about manually, the way the README says the author does.

If you’re on Linux, there’s no app for you here. But the durable lesson isn’t the app, it’s the map: skills are plain files in known directories, they dedupe cleanly through symlinks, and they belong in git. A ten-line shell script gets you the same architecture Chops renders in SwiftUI.

Version your procedures like code

A skill is an instruction sheet an agent will follow with real tools on real systems. You wouldn’t ship an unreviewed deploy script to production, so don’t ship an unreviewed skill to the agent that can run your deploy script. Put them in a repo, review them in pull requests, and let Chops — or your symlinks — handle distribution across whichever agents you’re running this month.

The people getting real leverage from agents aren’t the ones with the best prompts. They’re the ones whose accumulated procedures survive every tool switch. Skills on disk, in git, deduplicated: that’s how that happens.

Obsidian vaults accumulate plugins the way home labs accumulate Raspberry Pis. One comes from a Reddit thread, another from a YouTube tutorial, and eighteen months later you have a dozen community plugins installed and no idea which of them still have maintainers — or what any of them can actually reach inside your vault.

Since May, Obsidian has been quietly fixing the information half of that problem. Every plugin version that lands in the community directory now gets an automated scan, and the results are published as a safety scorecard on the Obsidian Community site — the same catalog as the in-app browser, but with the receipts attached. A piece over on XDA, “Obsidian launched safety scorecards for every plugin, and checking mine changed what I keep installed”, is what finally pushed me to run the audit on my own vaults. Here’s the short version of what the scorecards say, and how to act on them without losing an evening to tab-hopping.

What the scorecard actually measures

Each plugin page on the Community site has a Scorecard tab, and the sidebar boils it down to two bars:

• Health — is anyone still looking after this? It pulls recent commit activity and install counts. A plugin with a commit five days ago and 97,000 installs is alive; a plugin whose last release predates your current laptop is a maintenance risk regardless of how well it scans.
• Review — does the code scan clean? Dependency vulnerabilities, suspicious patterns like base64 blobs, and — the part I care about most — whether the published build can be reproduced byte-for-byte from the public source repository.

Below the bars sit Disclosures: what the plugin can reach. This is where you learn that your drawing plugin reads the system clipboard and can see every file path in the vault. Usually that’s not malice — some feature needs it — but it’s a fair bet nobody ever asked you about it. Every scorecard also carries a work-in-progress banner, which is honest: treat the whole thing as evidence, not a verdict.

Read it like a pipeline, not a rating

If you run CI for a living, none of this is conceptually new. Health is your bus-factor signal. Review is dependency scanning plus build provenance — the same “can I rebuild what I shipped?” question that SLSA-style attestations ask. Disclosures are permissions, the blast radius. Read a plugin page the way you’d read a green check on a pull request: it means the checks ran, not that the code loves you.

Two specifics worth internalizing before you panic:

• “Malware scan not available” is not a red flag. It shows up on big, boring plugins like Dataview and Templater too. It means there is no result to display — absence of evidence, not evidence of absence.
• A reproducible build is the strongest signal on the page. If Obsidian could rebuild the plugin from source and get a file identical to the one you installed, then what’s sitting in your vault is code anyone can read. That beats every heuristic.

The audit, in twenty minutes

1. Open Settings → Community plugins and write down everything installed — including the disabled ones. The disabled ones are where the deletions come from.
2. Look each plugin up on the Community site and check three things: the Review bar, the Disclosures, and the last commit date.
3. Apply three rules:
   • Reproducible build plus live maintenance → keep, carry on.
   • Health and Review disagree → investigate or drop. A healthy-looking plugin that fails review, or whose description still references a model from three years ago, is a fossil with good PR.
   • Disabled for more than a few months → uninstall. Reinstalling takes thirty seconds. This boring rule improves your vault’s security more than any scanner ever will.

The October 30 cutoff the app never mentions

There’s a deadline attached to all this that Obsidian doesn’t surface in the app at all: scorecard results on existing plugins are informational-only until October 30, 2026. After that, a plugin whose latest release fails review — actual errors, not a mere “caution” rating — gets pulled from the directory and can no longer be installed from the app.

If one of your workhorses is on the wrong side of that line, you have three moves, in order of preference: check the plugin’s repository, since most failures will be build issues a maintainer is already patching; back up the plugin folder from .obsidian/plugins/ so a reinstall stays possible even if it’s delisted; or go find the replacement now, on your own schedule, rather than mid-project.

Why this matters more for work vaults

A personal vault leaking clipboard contents is annoying. A small-business vault holding client notes, meeting records, and the odd pasted credential is a different asset class entirely. Plugins are third-party code with filesystem access to all of it, and “it was fine when I installed it in 2023” is not a control — that’s a hope with a version number. Moving from one-time hand review of the first submission to automated scans of every version is the biggest security improvement the Obsidian ecosystem has made. But scorecards only work if somebody reads them.

Twenty minutes, once a quarter, with a delete-first bias. That’s the entire practice.

The build stops at the bare MDF

Every DIY arcade cabinet follows the same arc. Week one you’re flashing a RetroPie image, arguing with controller mappings, and feeling like a genius. Week three the controls work, the emulator frontend is configured, and the cabinet sits in the corner as a sheet of bare MDF with a screen bolted into it. Six months later it’s still sitting there, because the remaining work — the finish — is a completely different skill from everything you’ve done so far.

I’ve watched this pattern repeat across homelab projects of every flavour: the functional 90% ships in a weekend, and the cosmetic 10% dies in committee. With arcade cabinets the gap is worse, because a half-finished cab doesn’t just look unfinished — it looks like furniture that’s been in an accident. The wrap kit that kicked off this thinking is Arcade Revival’s full cabinet wrap, and it’s a good excuse to talk about the finishing decision every cabinet builder eventually faces.

Why paint is where arcade builds go to die

Painting an arcade cabinet properly is real work. MDF drinks paint, so you need to seal the edges, sand, prime, sand again, and only then think about colour. That’s before the dust control, the cure time between coats, and the near-certainty that the first side you do teaches you everything you’ll wish you’d known for the second side. A gloss black arcade side panel is one of the least forgiving surfaces in hobby woodworking — every sanding scratch and dust fleck reads like a headline.

None of this is hard in the way that debugging a kernel panic is hard. It’s just slow, physical, and unforgiving of impatience, which is exactly the combination that people who are good at software tend to underestimate.

The three realistic finishes

For a home-built upright, your actual options narrow to three:

• Paint. Cheapest per litre, most expensive in evenings. Fine if you enjoy finishing work; miserable if you don’t. Custom colour, but any artwork means stencils, decals, or artistic talent you may not have budgeted for.
• Printed side art. The classic route — big printed panels applied over a painted base. You still paint, but the art carries the visual load. Works well, but it’s two projects stitched together.
• A full wrap. Pre-cut adhesive vinyl covering every exterior panel, printed with the complete artwork. You skip the paint entirely and the artwork arrives as geometry rather than as a separate problem.

The interesting shift is that wraps have quietly become a DIY product rather than a signwriter’s trade. That’s down to the vinyl itself.

Air-release vinyl changes the maths

The old objection to wrapping anything yourself was bubbles. Traditional sign vinyl grabs immediately, and one trapped pocket of air means lifting the panel, stretching the film, and starting over with a heat gun and a vocabulary you didn’t plan on using. Modern cast vinyls with air-release adhesive channels — 3M’s 40C series is what Arcade Revival prints on — are a different material. The adhesive face is micro-channelled, so air migrates out along the channels as you squeegee the film down, and the initial grab is mild enough that you can peel a panel back up and reseat it when your alignment drifts.

For a cabinet, that repositionability matters more than the bubble resistance. Aligning a full-height side panel to a cabinet you built in your garage — with the tolerances of a cabinet you built in your garage — is the part that would scare me off, and forgiving adhesive is what makes it survivable.

The practical kit is refreshingly short:

• a fresh blade in a utility knife (dull blades drag and stretch the film — replace them mid-job if needed)
• the squeegee that ships in the box
• a clean cloth and some isopropyl for degreasing the panels first

No heat gun, no solvents, no spray equipment. If you’ve ever applied a phone screen protector badly and sworn off the entire category, the difference here is scale and time: a cabinet panel goes down over minutes, with room to correct, not seconds.

The panels that actually make it look real

A full wrap kit covers the sides, the front kick panel, the control panel strip, the control panel overlay, the screen bezel, and a translucent marquee. In my view the two that matter are the control panel overlay and the marquee, and they matter for different reasons.

The control panel overlay is the surface players actually touch. Bare MDF there announces “prototype” the instant someone rests their wrists on it, and it will slowly dissolve into grease. An overlay turns the most-abused surface into the most durable one.

The marquee is the soul of the machine. A translucent marquee print, backlit, is the moment a box of MDF becomes an arcade cabinet — it’s the light you see across the room. If you’re triaging a budget, those two panels are where I’d spend first, and a wrap kit that includes both plus the sides is effectively the whole decision made for you.

Two honest catches

Fit is cabinet-specific. These kits are printed for a specific cabinet profile — in this case Arcade Revival’s own uprights, with panels following the machine’s lines. If you’re building your own cab from plans, check the panel dimensions against yours before ordering, or accept that you’ll be trimming. Trimming vinyl is fine; discovering a four-centimetre shortfall on a side panel is not.

Fan art is fan art. The kit’s own disclaimer is worth reading: it’s an unofficial, unlicensed design inspired by classic games, not an endorsed product. That’s the honest way to sell this stuff, and it’s the same position most of the retro-cabinet artwork ecosystem operates in. Just go in knowing it’s a themed tribute, not licensed merchandise.

One more from the pragmatic column: kits like this generally don’t replace panels you wreck during installation. Dry-fit every panel before you commit. The repositionable adhesive makes alignment forgiving, but “forgiving” and “unlimited” are different words.

Build the guts, buy the skin

The broader lesson applies well past arcade cabinets. Every big project contains a subsystem that is someone else’s core competency, and finishing is almost always it for those of us who live in terminals. You wouldn’t mill your own screws. The version of you that’s good at firmware, emulation configuration, and wiring a control panel should not also be the version of you learning to spray a flawless gloss finish on a two-metre sheet of MDF.

Spend your evenings on the parts only you care about — the input lag tuning, the frontend theme, the coin-door wiring that makes guests smile — and buy the finish from people who print it for a living on a machine the size of your car. The cabinet gets finished, the room gets a centrepiece, and you get your weekends back. That’s a trade I’d take every time.

The unreachable machine is a design flaw, not a fact of life

Every homelab and every small IT shop eventually collects machines it can’t comfortably reach. The Raspberry Pi at a relative’s place, stuck behind carrier-grade NAT. The little server at a client’s office, where the router is owned by someone else and the firewall policy is “no”. The edge box in a workshop that you see twice a year. The traditional answers are all bad in familiar ways: forward port 22 and pray, keep a jump host alive, or bolt a VPN onto hardware you don’t fully control.

There’s a better shape for this problem, and a recent overview of ShellHub over at OpenSourceProjects.dev prompted me to write up why I think it matters. ShellHub flips the direction of the connection: instead of you fighting your way into remote machines, each machine calls out to a gateway you run. It’s an Apache-2.0 project from O.S. Systems, and it deserves a slot in more homelabs than it gets.

What ShellHub actually is

ShellHub is a centralized, self-hostable SSH gateway. You run the gateway — on your own hardware or a small VPS — and install a lightweight agent on every Linux device you want to manage. The agent makes an outbound connection to the gateway and registers the device. From then on, you reach that device through the gateway using the tools you already use: plain OpenSSH, PuTTY, scp, sftp. No proprietary client, no agent-side port openings, nothing listening on the remote network.

There’s also a web interface and a mobile app, so you can get a shell from a browser when you don’t have your keys handy — useful when the “incident” is happening on your phone in a supermarket queue. Port forwarding works too, including SOCKS proxying, which quietly covers a lot of “I just need to reach one internal service” scenarios. And it integrates with Docker, so you can drop into containers on a host without first SSH-ing in and running docker exec yourself.

The trick is the direction of the connection

Most remote-access pain is really about inbound connections. CGNAT breaks them, client firewalls block them, and every listening port is an attack surface you now own. ShellHub’s model removes the entire category: the only inbound-exposed thing is your gateway, which is one box you can harden, monitor, and put behind TLS and a reverse proxy you already trust.

That asymmetry is the whole product, and it’s why the setup story is so short. Install agent, accept the device in the web UI, done. No router configs, no dynamic DNS, no “can you open a port for me” emails to a client’s IT person who doesn’t exist.

Where it earns its keep: the audit layer

For me, the gateway plumbing alone wouldn’t justify another service to run. What makes ShellHub interesting is everything stacked on top of that plumbing:

• Per-user public keys. Multiple people can log in as the same system user without sharing a password, and you revoke one person’s access without touching anyone else’s. That is how access control should work, and it’s rare to get it for free.
• SSH firewall rules. Fine-grained control over which connections may reach which devices, enforced at the gateway.
• Audit logging. Every connection through the gateway creates a stored session record.
• Session recording. Interactive sessions are recorded and replayable in a built-in player in the web UI.

That last one is the feature small businesses keep wishing they had after something goes wrong. When a technician works on a client box at 11pm, “here’s the recording” beats an hour of reconstruction from shell history. It’s also a genuine compliance lever, not just a paranoia feature.

When I’d run it — and when I wouldn’t

Be honest about the shape of your problem before adopting this. ShellHub shines when the fleet is heterogeneous and partly not yours: client machines, family machines, embedded or IoT devices in the field, or contractors who need shell access but should never be handed a spot on your WireGuard mesh. Per-person keys, revocation, and recordings are exactly the controls that situation lacks.

If it’s three boxes that are all yours in one building, a mesh VPN is simpler and gives you the whole network, not just shells. I run Tailscale-shaped things for my own day-to-day access and don’t feel bad about it. ShellHub is the tool for the moment access needs to be managed, not just established.

Running it yourself

The fastest honest evaluation is the hosted ShellHub Cloud — connect one device, see whether the workflow fits your brain. If it does, self-hosting is the natural endpoint for this audience. The project ships a compose-based deployment; follow the self-hosting guide rather than hand-rolling your own compose file, because the stack has several services and its own wrapper scripts. To poke at the code locally, the development bootstrap is pleasantly short:

git clone https://github.com/shellhub-io/shellhub.git
cd shellhub
make keygen
make start
./bin/cli user create <username> <password> <email>

Two operational notes from the “things I do to my own infrastructure” file. First, the gateway is now critical infrastructure: it belongs in the must-be-up tier next to your reverse proxy, with its data backed up and updates applied on a schedule. Second, keep one out-of-band path to your boxes — a VPN that isn’t related to ShellHub, or console access. If your only door is the gateway and the gateway is down, you’ve rebuilt the unreachable-machine problem you started with, one level up.

Verdict

ShellHub doesn’t try to reinvent SSH, and that restraint is why it works. Your existing clients keep working, your muscle memory keeps working, and what you gain is the part SSH never had: a front desk. Devices call home, people get named keys, sessions get recorded, and port 22 stays closed everywhere but the one place you watch. For anyone supporting machines on networks they don’t control — which is most of us by the second client — that’s a clean upgrade to how you operate.

The last mile of a side project is a URL

Every side project has a graveyard stage, and it’s almost always the same one: fully working, completely invisible, running on localhost:3000. The project doesn’t become real until a stranger can load it over HTTPS. The good news is that getting there is now a ten-minute job — push to Git, connect a host, collect a URL. The better news, which nobody advertises on the pricing page, is that “free” on these platforms is a terms-and-quotas decision, not just a price. A detailed comparison of the five big free Git hosts got me thinking about how to frame that decision, because most people frame it wrong.

The map, sorted by what actually binds you

People compare free hosting tiers on bandwidth, and bandwidth is almost never the constraint. What binds you is builds, credits, cold starts, or the terms of service — in roughly that order of surprise. Here’s the honest map:

• Cloudflare Pages is the generous static default. Requests to static assets are unmetered, you get 500 builds a month, and custom domains just work. The trap in the word “unlimited”: Pages Functions share the Workers free cap of 100,000 requests a day. A brochure site stays free forever; an API-on-the-edge does not.
• Vercel Hobby is the best developer experience for Next.js and React — detected frameworks, instant preview deploys, roughly 100 GB of fast transfer a month. The trap is the licence, not the quota: Hobby is non-commercial, personal use only.
• Netlify Free now runs on credits: 300 a month, hard limit, no auto-recharge. A production deploy costs 15 credits and bandwidth costs 20 per GB, so the maths is unforgiving — about twenty deploys a month and not much traffic before visitors see “site not available”. Deploy previews are free, which is the one mercy.
• GitHub Pages is simplest: 1 GB site, a soft 100 GB monthly bandwidth cap, and a policy that flatly rules out stores and commercial SaaS. Perfect for docs and portfolios, wrong for anything with a checkout.
• Render static sites are free on a Git-connected CDN with 5 GB of bandwidth — but do not confuse them with Render’s free web services, which sleep after fifteen minutes and take a groggy minute to wake. Free web services are for toy APIs, not for anything with a deadline.

(All numbers move. Screenshot the usage page the week you launch anything real; the two that ambush people are Netlify credits and Vercel fair-use.)

The Stripe tripwire

Here is the part worth internalising, because it’s the same story on every platform wearing a different hat. The moment money touches the URL, the free tier is over — whether or not anyone bills you.

Vercel’s fair-use rules are the clearest example: payments, ads, donation buttons, affiliate-driven sites, and getting paid to build or host the site all count as commercial. There is no “under $10 MRR is still Hobby” clause. One paying customer, or even a tip jar, is the policy line — and crossing it quietly, then migrating during your first traffic spike, is far more expensive than the $20 a month the paid tier would have cost all along. GitHub Pages makes the same call as policy rather than pricing, and Cloudflare’s version is a quota: static business sites are fine, edge functions hit the cap.

So the mental model I use: a free tier is a staging environment with suspiciously good production qualities. Use it for demos, portfolios, experiments, and the version of the product that exists while you’re still deciding. The moment there’s an invoice in either direction, pay for the floor under it. Budget the paid tier as a line item of the first dollar of revenue, not as a response to it.

The homelab objection, taken seriously

Regular readers know my first instinct is to serve it myself: I have servers, a reverse proxy, and a suspicious relationship with uptime monitors. And yes, a static site behind your own proxy is a solved problem. But I’ve come around to a division of labour: the git-push CDN hosts the public-facing, must-be-up-when-my-power-isn’t things — the portfolio, the status page, the write-ups — and the homelab fronts the dynamic stuff, the dashboards, and everything that genuinely needs to run on my hardware.

“Free” is doing quiet work in that sentence. A free tier you treat as a staging environment gives you uptime you don’t personally own, TLS you don’t renew, and a CDN you don’t debug at midnight. That’s a fair trade for a side project. It stops being a fair trade the moment the project has customers, and the whole trick is noticing which side of that line you’re on this week.

Five rules that keep free hosting boring

• Env vars live in the dashboard, never in the repo. If a .env ever touched Git, rotate every key in it. This is the single most common way a free-tier side project becomes a paid incident.
• One canonical URL. Don’t dual-deploy to two hosts “for backup” — you’ll end up with two half-updated versions and no idea which one Google indexed.
• Share preview deploys, not localhost screenshots. The preview URL is the demo. It’s also a free smoke test on infrastructure that isn’t your laptop.
• Pick the host by your binding constraint. Deploying often? Netlify credits will bite. Edge functions? Cloudflare’s daily cap. Trying to impress a client? Don’t put it on a plan that cold-starts.
• Decide the money line up front. If Stripe is in the plan, a paid tier is in the plan. Write both names on the same line of the napkin.

Free hosting is genuinely one of the best deals in computing — for the thing you’re building before it’s a product. Treat it as that, upgrade the day it becomes one, and you get all of the free with none of the fine print.

The best bill of materials is the empty one

Every maker has a shelf of half-planned projects that stalled the moment the shopping list got long. Two sensors, a relay module, a buck converter, a case, some Dupont wire — and suddenly a weekend tinkering session has a lead time and a freight cost. That’s usually where the momentum dies. So there’s something quietly radical about the observation at the heart of a recent XDA roundup of ESP32 projects: there’s a whole class of genuinely useful builds where the parts list is one board and the USB cable already tangled in your drawer.

I want to take that idea seriously, because it’s more than a curiosity. When a project needs nothing you don’t already own, three costs disappear: the money, the wait, and — the expensive one — the decision fatigue. You can start on impulse and finish before dinner. Here are the four jobs that earn that status, and where I’d actually deploy each one.

A DNS sinkhole that fits in your palm

The first surprise: you can run a real ad-blocking DNS sinkhole on an ESP32. Projects like the ESP32_AdBlocker firmware hold a blocklist in memory and answer DNS queries directly, no Raspberry Pi or home server required. The catch is RAM — modern blocklists are chunky, so you want an ESP32-S3 with 8MB of PSRAM rather than the bare classic board.

My honest take: this is not a Pi-hole replacement, and you shouldn’t pretend it is. You lose the query logging, the pretty dashboards, and the group management that make Pi-hole feel like infrastructure. But as a disposable sinkhole it’s excellent — the DNS blocker you hand to a family member, drop on a guest network VLAN, or throw in a bag for travel. If it dies or gets replaced, you’ve lost a five-dollar board, not a server you have to rebuild.

Motion detection with no motion sensor

The cleverest trick in the bunch is ESPectre-style Wi-Fi sensing. Wi-Fi packets carry channel state information — a fingerprint of how the radio signal physically propagates through the room. Move around the room and the fingerprint shifts. An ESP32 sitting next to your access point can watch those shifts and turn them into a motion score, no PIR module anywhere in sight.

Treat this as a lighting convenience, not a security control. After calibration it’s surprisingly reliable for the low-stakes jobs: pantry lights, hallway LEDs, “did someone actually go into the server closet.” I’d still put a real presence sensor on anything where failure hurts — stairs, or anything that decides whether an alarm arms. But for automations where a false trigger costs you nothing, free motion detection from a board that’s already there is an absurdly good deal.

The watchdog that can’t die with your server

This is the one I’d push on every homelab and small business, because it solves a monitoring blind spot that bites people constantly. When your uptime monitor runs inside the stack it’s watching — a container on the same host, a check that depends on the same network path — it fails exactly when you need it. The fix is an out-of-band probe, and an ESP32 on the desk Wi-Fi is about as out-of-band as infrastructure gets.

Flash it with ESPHome, point it at your Proxmox UI or your NAS or the client portal, and let it report connectivity to Home Assistant as a binary sensor. A trimmed version of the config looks like this:

http_request:
  useragent: esp32-watchdog
  timeout: 5s

binary_sensor:
  - platform: template
    name: "Proxmox Web UI"
    id: proxmox_up
    device_class: connectivity
    lambda: return {};

globals:
  - id: failures
    type: int
    restore_value: no
    initial_value: '0'

interval:
  - interval: 30s
    then:
      - http_request.get:
          url: https://192.168.1.50:8006/
          capture_response: true

on_response:
  then:
    - lambda: |-
        id(failures) = 0;
        id(proxmox_up).publish_state(true);

on_error:
  then:
    - lambda: |-
        id(failures) += 1;
        if (id(failures) >= 3) {
          id(proxmox_up).publish_state(false);
        }

The three-strike counter matters: one dropped packet shouldn’t page you, three in a row should. And note what this enables beyond alerts. Because the probe is independent of your servers, it can be the trigger half of a dead man’s switch — if the ESP32 can’t reach the VPS for N minutes, it shuts the VPS down (or fires a webhook, or toggles a smart plug). That’s the shape of real failover logic, running on hardware that costs less than the coffee beside it.

A radio you’re not using yet

The fourth job depends slightly on which board you grabbed. Any ESP32 can act as a Bluetooth proxy, relaying BLE devices to Home Assistant — passive listening, or active control if you want to drive lights and blinds through it. If it’s a C6, the onboard 802.15.4 radio adds two more roles: a Zigbee router extending your mesh, or a Thread radio co-processor. Add a U.FL antenna and it’ll cover more than a room or two.

This is the least glamorous item and the one I’d bet gets the most daily use. Radio coverage problems are the silent tax on every smart-home rollout — pairing fails in the far bedroom, devices drop off the mesh, and the fix is usually “buy another hub.” A spare ESP32 plugged into a wall socket near the dead zone is the fix that’s already in the drawer.

The constraint is the feature

What ties these together isn’t the ESP32 specifically. It’s that each build works because it refuses to accrete parts. No sensors to mount, no modules to wire, no enclosure to print — flash, plug in, done. That’s why they escape the project graveyard: there’s no gap between deciding to do it and having it running.

So the next time you clear out a drawer and find a couple of ESP32s from an old order, don’t bin them and don’t “save” them. A spare board isn’t inventory, it’s unbuilt infrastructure: a travel DNS filter, a closet motion trigger, an independent pair of eyes on your Proxmox node, or a radio bridge for the far end of the house. The only thing you need to add is the cable — and you have that too.

Most hardware projects die of ambition, not difficulty

Look in any maker’s drawer and you’ll find the fossils: the ambitious build that was going to do everything, got 70% finished over three weekends, and now powers nothing. The lesson I’ve slowly accepted — and that a lovely XDA piece on afternoon-scale ESP32 builds states better than I have — is that the projects which survive aren’t the cleverest. They’re the ones that fix a real annoyance before bed.

Call it the afternoon rule: if a build can’t remove a genuine, current annoyance by tonight, it’s a solution to a hypothetical problem, and hypothetical problems are how drawers fill up.

What struck me reading that piece wasn’t the five builds themselves — a knock sensor identifying which door, a reed switch on the garage, a vibration sensor announcing the laundry, Bluetooth proxies locating lost headphones, a particulate sensor driving an air purifier. It’s that all five reduce to the same three-stage pattern, and the pattern is the part worth stealing:

• Sense. One cheap sensor on one cheap board, reporting one fact.
• Threshold. A rule that turns the raw reading into an event worth knowing about.
• Notify. A push to the phone of whoever is actually bothered by the problem.

That’s it. No dashboard redesign, no “platform play”, no graphing every metric because the graphing library looks nice. One annoyance, one signal, one notification.

The quality lives in the threshold

Here’s the detail that separates a build you forget about from a build you turn off in week two: the debounce. The laundry example is perfect — a vibration sensor taped to a washing machine can’t just alert “no vibration”, because washers go quiet between spin and fill. Alert fires mid-cycle, everyone learns to ignore it, the build is dead. A three-minute quiet buffer changes it from noise into signal.

The same thinking applies everywhere:

• A garage door sensor that alerts instantly will nag during a two-minute unloading. Alert on open for more than five minutes.
• A door sensor that triggers on any vibration will fire in a storm. Require a pattern, or a sustained event.
• A temperature alarm needs hysteresis, or it flaps around the threshold all afternoon.

In Home Assistant the whole pattern is a few lines, which is precisely why it clears the afternoon bar:

automation:
  - alias: "Washer finished"
    trigger:
      - platform: state
        entity_id: binary_sensor.washer_vibration
        to: "off"
        for: "00:03:00"
    action:
      - service: notify.mobile_app_garys_phone
        data:
          message: "Washer's done — go rescue the laundry"

And the sensor side is an ESPHome config file, not firmware development — YAML you can keep in git next to your compose files, redeploy onto a replacement board in minutes when one eventually dies.

The rule works double duty in a lab or small business

The pattern scales past the house. The same sense → threshold → notify shape, pointed at infrastructure instead of appliances, is most of what a small operation needs from monitoring:

• A reed switch on the server room or comms-closet door, alerting on open-for-more-than-a-minute. Cheap, dumb, and it will catch the contractor who “just checked something” at 6pm.
• A water sensor under the rack or the air-con drip tray. One of the least glamorous boards you’ll ever flash, and one of the few that can pay for the entire drawer.
• A temperature sensor near the switch stack in the cupboard with the closing door and no ventilation, alerting before the gear throttles rather than after it reboots.

None of these need dashboards on a wall. They need a push notification at the moment a fact changes, which is what the afternoon pattern delivers.

Know when to break the rule

Two honest caveats. First, anything involving mains wiring — doorbell circuits, HVAC control, the purifier’s power — moves out of “afternoon” territory the moment you open the case. A relay on the bench is a learning project; a relay inside a machine that’s plugged into the wall is an electrical decision. Use proper isolation, or stay on the sensing side and let the notification land with a human.

Second, safety-critical is out of scope entirely. The rule is for annoyances, and it works because annoyances are cheap to be wrong about. A false “garage open” is a shrug; a sensor trusted to fire a safety alert is a different class of engineering. Keep the two firmly separate.

But within those limits, the rule is the best scope-creep defence I know. The board costs five dollars, the sensor costs two, and the question isn’t “what could this become?” — it’s “what annoyance does this kill by tonight?” Answer the second question first, and the drawer stays a toolbox instead of a museum.

The most underrated job in the house is the one your smallest model can do

Every conversation about local LLMs eventually wanders into horsepower: which quantisation, how many billion parameters, whether the GPU can hold the whole context window. Meanwhile the workload that small models are genuinely best at — not “adequate despite their size”, but actually better suited than the big ones — sits quietly in every writer’s workflow: proofreading.

The case was put well in a piece on XDA where a journalist swapped their cloud writing assistant for a small model running on modest hardware, and I think the underlying idea deserves to be generalised across home labs and small businesses: constrained, boring, high-volume text jobs belong on small local models. Not because it’s cheaper — it is — but because the failure modes of a big model are exactly the failure modes you’re trying to avoid.

The problem with “writing assistants” is that they write

Grammar tools have spent the last few years drifting from checker to co-author. Flag a typo, and along comes the suggestion to restructure the paragraph, formalise the tone, and compress three sentences into one nobody would say out loud. If you’ve ever had a document come back sounding like a press release for itself, you know the mode. The tool stopped asking “is this correct?” and started asking “could this be more impressive?”

Here’s the twist: a small local model is largely immune to this, because ambition is a function of capability. A 3–4B parameter model doesn’t have the confidence to restructure your argument. Asked to fix what’s broken and leave the rest, it does mostly that. The model that can’t write a brilliant essay is also the model that won’t try to rewrite yours. What you want from a proofreader is a careful reader with a red pen, not a ghostwriter — and the red pen role is where the small models live.

The setup is smaller than you think

This job does not need the GPU you don’t own. A Qwen, Gemma or Llama model in the 3–4B class runs comfortably on:

• the mini-PC or NAS already running your containers,
• a 8–16GB laptop through Ollama or LM Studio,
• even a recent phone, if you’re curious.

Latency tolerance is the hidden advantage. Nobody cares if proofreading takes four seconds — there’s no chat stream to keep snappy, no autocomplete racing the typist. You paste, you wait, you diff. The job has no egos in it.

The part that actually matters is the prompt. Proofreading quality is mostly a contract about restraint, and it needs to be explicit:

proof() {
  ollama run qwen3:4b "$(cat <<'EOF'
You are a proofreader. Fix only: typos, duplicated words,
grammar errors, and phrasing that is genuinely ambiguous.
Do not rewrite sentences that are already correct. Do not
change tone, structure or word choice. Return the full text
with the smallest possible number of edits, then list the
changes you made in one line each.
EOF
)" "$1"
}

Two details in that prompt are doing real work. “Smallest possible number of edits” turns restraint into a measurable instruction. And “list the changes” means you review a diff instead of trusting a rewrite — which is the entire safety model. Never paste-blind-accept; make the model show its work.

Why local isn’t just a preference here

For individuals, running this locally is nice. For a small business, it’s close to mandatory. The documents that most need a second pair of eyes — quotes, tender responses, client emails, anything under NDA — are precisely the documents you should not be shipping to a third-party API for a typo fix. Cloud AI terms change, retention policies change, and “we pasted the tender document into a chatbot” is not a sentence anyone wants to explain in a security review.

The same privacy argument applies to the homelab journal, the incident postmortem, the email to the accountant. Proofreading is high-touch, low-stakes, repetitive work on sensitive text — the exact shape of workload that should never leave the LAN. Run the model on hardware you own, on a network you control, and the question of where your drafts go answers itself: nowhere.

Give the boring jobs to the small models

There’s a habit worth building from this: match model size to job stakes. Big models for reasoning, synthesis, anything where a wrong answer compounds. Small local models for the high-volume, low-stakes, sensitive-text jobs — proofreading, summarising your own notes, reformatting, extracting structure. Those jobs don’t need brilliance; they need consistency and containment.

The writing stays yours. That’s not a limitation of the setup — it’s the design goal.