Hansen IT Solutions

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.

A directory of car manuals sounds like an asset until you have one. Ten thousand PDFs in folders named by someone’s personal logic is indistinguishable from zero PDFs — the information is all there and none of it is findable. carmanualspdf.info is the fix: the whole tree, browsable as manufacturer → model → year → manual, with a URL for everything.

The filesystem is the database

The site’s engine is a Go web app that renders templates over a directory tree: brand folders hold model folders, model folders hold year folders, and the PDFs hang off the end of it. That’s the entire content model. There’s no CMS to log into, no admin interface to secure, no database schema that drifts out of sync with reality — the manuals on disk are the catalogue. Adding a thousand manuals means putting files where they belong; the site reflects it on the next request.

Why not a database?

Because the source of truth is already files, and every table you derive from them is a second copy that can rot. A database would buy fast arbitrary queries, but the access pattern here isn’t arbitrary — people arrive knowing the brand, narrow to the model, then the year. That’s exactly a directory walk, which Go does quickly and which maps straight onto URLs people can guess, share, and bookmark. When the question is “the 2011 diesel manual, please”, a tree answers it without an index. When the catalogue eventually wants full-text search across model names, that becomes a build-time index over the same files — a view, not a migration.

Cheap to run, cheap to grow

Serving mostly-static pages from a filesystem is the least demanding workload in computing, and the hosting reflects that: the whole site runs as a single small machine on Fly.io, comfortably handling browse traffic for the cost of a coffee a month. Growth is additive — more diskspace, more manuals, same architecture. There’s no scale cliff hiding in it, because there’s nothing in the request path heavier than template rendering and file reads.

The shape of the thing

What I like about this build is what it refuses to do. It doesn’t wrap a folder of PDFs in a framework with a login page and a database to feed. It takes the collection as it actually exists — messy, filesystem-shaped, growing — and makes it navigable with the minimum machinery that survives contact with real users. Pick your manufacturer and start browsing at carmanualspdf.info.

Most “AI-powered” shops mean one thing: every product description is an API call to somebody else’s meter. Get Punny Shirts is the other kind. It’s a t-shirt store where the product line — puns, matched to artwork, ready to print — is generated by an AI the shop owner also hosts. The punchline writes itself; the infrastructure is the interesting part.

The shop that drafts its own products

The premise is simple: give it a theme, and the model proposes puns. Behind that simplicity sits a deliberately flexible inference layer. The pun engine speaks to any OpenAI-compatible server — Ollama, llama.cpp, or whatever you point it at — so the shop isn’t married to a model vendor or even a model size. Want fast mistral-class generation for volume? Set the environment variable. Want a reasoning model like DeepSeek-R1 to chew on wordplay a little longer? That works too, with the model’s internal thinking tags stripped before the result hits the catalogue. The product pipeline treats the model as a swappable component, which is exactly how it should be treated.

Why host the brain yourself

Self-hosting inference in an e-commerce path sounds like extra work, and it is — but it buys three things a per-call API never will. Cost behaves: generating five hundred puns to find fifty good ones costs electricity, not a line item. Rate limits stop existing. And the content floor is yours: the catalogue is generated by a model you chose, against a prompt you control, with no surprise policy change in the middle of a product run. For a niche store where margin is everything, that’s not a hobbyist flourish, it’s the business model working.

Curation where it counts

The images are not generated. Pun text comes from the model; artwork comes from a curated library the engine matches to each pun. That split is the quiet design decision that keeps the output sellable — AI is genuinely good at wordplay and genuinely unreliable at print-ready art, so the pipeline uses it for the former and trusts humans for the latter. Every shirt that ships is a joke the model wrote on art somebody chose.

The boring parts are what make it a shop

None of the cleverness would matter if the money and the parcels didn’t move. Checkout runs through Stripe. Fulfilment runs through Printful, so production and shipping are automated the moment an order lands — nobody screens shirts in a garage. The whole platform is a Go service: one binary, one small machine, no framework zoo. It’s the same architecture instinct as the rest of the Hansen IT Solutions stack — few moving parts, self-hosted where control matters, boring where boring is a feature.

The result is a store that can spin up a product line in an afternoon and pays nobody rent on the imagination. Go get punny — the AI already did the writing.

claude-ops caught my attention for the least glamorous reason possible: its README opens with a morning briefing. One command, /ops:go, and your terminal agent reports infrastructure health, CI status, an inbox count across Slack, Telegram, Gmail and WhatsApp, open PRs, sprint progress, and a revenue snapshot from Stripe and AWS — then finishes with the line that matters: Next action: merge feat/user-profile · fix my-api CI · reply @alice.

That last line is the whole product. Everything else the project does — and it does a lot, 60-plus skills spanning deploys, monitoring, e-commerce and voice — is downstream of treating your ops information as a briefing that ends with a verb, rather than a dashboard you visit.

Dashboards render; briefings act

Most of us already own too many dashboards. Grafana for the cluster, a CI page per repo, Uptime Kuma for the services, a billing console for the cloud spend. The failure mode isn’t visibility — it’s that dashboards are passive. They wait for you to look, and looking is the thing mornings take away from you first.

A briefing inverts the flow. It comes to you, it’s assembled on a schedule whether or not you ask, and — if it’s built right — it ends with a prioritized next action instead of a wall of green. claude-ops didn’t invent this idea, but it’s the most complete implementation I’ve seen bolted onto a terminal agent: the briefing reads services you already pay for, through credentials you already hold, and the “dashboard” is just the model narrating a deterministic data pull.

The engineering worth stealing

You may never install this plugin. Three of its implementation choices are still worth copying.

Gather before you think

Every skill assembles its data with pre-execution shell blocks — deterministic scripts that run before the model’s context loads. The agent never burns tokens or seconds on asking “what’s the state of the ECS cluster?” and waiting for tool-call ping-pong. A background daemon pre-warms the expensive parts (infra health, git state, unread counts) on a two-minute cadence, so the briefing loads from warm cache in under three seconds instead of ~30 cold.

That’s the read-path/think-path separation that most agent projects still get wrong. Fetching state is a scripting problem; deciding what to do about it is a model problem. Keep them in that order and briefings become cheap enough to actually run daily.

Autonomy with a leash

The flagship autonomy feature is /ops:deploy-fix: after you merge a PR, it polls the deploy workflow, curls /health on success, verifies /version returns the merged SHA, retries transient failures, and only if that fails dispatches a headless fixer agent on a cheap model. The fixer is fenced in by per-repo budget caps (three runs an hour by default), single-flight locks so two agents can’t fix the same repo simultaneously, and content-hash dedup so identical failures don’t burn the budget twice.

That is the correct shape for letting an agent touch production: autonomy triggered by an action you initiated, bounded attempts, one actor at a time, and everything observable. Compare that to the popular alternative — an agent with broad write access and vibes-based restraint — and you can see why this pattern earns trust.

Hooks that don’t ask nicely

Always-on safety hooks do a secret scan on writes, hard-block rm -rf against anchor paths, warn on pushes to main, and route outbound one-to-one messages (Twilio, AI phone calls) through a per-message approval gate. None of these depend on the model remembering to be careful. Good defaults beat good intentions, especially at 6am when nobody is reading the output closely.

The homelab translation

You probably don’t run ECS or RevenueCat. The pattern still maps directly onto a homelab or small-business stack:

• Cluster health: kubectl get deployments -A filtered for anything not at full replicas, plus Argo/Flux sync status
• CI: gh run list for the repos that matter
• Services: Uptime Kuma’s status API for a single up/down rollup
• Backups: exit status of last night’s jobs, because silent backup failure is the homelab’s original sin

A twenty-line script does the gathering:

#!/bin/sh
# morning-ops.sh — deterministic gather; the agent only narrates
echo "== deployments =="
kubectl get deploy -A --no-headers | awk '$3 != $4 {print}' | grep . || echo "all healthy"
echo "== ci =="
gh run list --limit 5 --json displayTitle,conclusion --jq '.[] | select(.conclusion != "success")'
echo "== kuma =="
curl -fs localhost:3001/api/status-pages/lab | jq '[.summary.monitors[]? | select(.status != 1)] | length'

Point your agent at that output on a schedule and you have the briefing without adopting anyone’s plugin. The discipline to keep is the ending: make it propose the next action, not just report the state.

Where I’d pump the brakes

claude-ops wants to be a business operating system, and the breadth is where judgment comes in. Voice agents, Shopify operations, marketing dashboards and “four parallel C-suite agents” are a lot of surface for a small team, and every integration you wire in widens the blast radius — the AWS probes read everything your IAM allows, so wire up least-privilege credentials first. The multi-account subscription rotator sits in terms-of-service gray territory I wouldn’t touch. And the whole thing is shaped as a Claude Code plugin (with some harness support), so treat it as a source of patterns more than a platform: your briefing should degrade gracefully to plain scripts if the plugin ever goes away.

The takeaway

Ops information wants to be narrated and acted on, not rendered. The recipe claude-ops gets right is boring and portable: deterministic gathering scripts, a warm cache so the habit is cheap, autonomy that’s bounded and budgeted, and safety enforced by hooks rather than politeness. Steal those four things in whatever stack you run — and make sure every briefing you receive ends with a verb.

Nearly every Obsidian guide assumes you showed up to take notes — fair, it is a Markdown editor — but the people who stay discover that notes are the least interesting thing in the vault. Nolen Jonker’s piece at XDA on replacing an entire productivity workflow with one vault is the best recent tour of why: the vault is just a folder of plain Markdown and JSON on your disk, which means every other tool you own — git, sync clients, backup jobs, and increasingly your agents — can read and write it too. Once that clicks, Obsidian stops being a notes app and becomes the user interface for a folder that everything else can participate in.

A dashboard layer without a plugin stack

Jonker’s first move is a folder called /index/: separate Markdown files for active projects, this week’s priorities, stalled work, orphaned notes. Each dashboard is nothing but a table and some wikilinks, so it renders natively in Obsidian — no Dataview, no plugin stack — and an agent (Claude Code, in their setup) crawls the vault’s frontmatter and file modification times to keep the tables honest. Add a deadline to a project brief, ask for a regenerate, and this-week.md picks it up.

Project trackers die of two failure modes: nobody updates them, and nobody opens them. A dashboard that lives with the work kills the second one — it’s one click from the notes you’re already in — and an agent that regenerates it from the source files kills the first. The information was already in the vault, scattered across folders; it just needed a view on top of it. Bonus: the index folder becomes the spine of the graph view, which used to be a disconnected mess and is now something you can actually navigate.

The vault as a cache, not just a source

Most AI-plus-notes setups run in one direction: feed your notes into a chatbot, get an answer, lose the answer. The pattern worth copying runs the other way. A /Cache/ folder holds the synthesis-heavy answers your agent has already produced — named Markdown notes — and a root instruction file (CLAUDE.md) tells the agent to check that folder before re-reading the same thirty raw sources.

The first payoff is arithmetic: you stop burning tokens re-deriving the same synthesis every time you ask a variant of the same question. The second payoff matters more. Those cache notes are ordinary files in an ordinary folder, so they ride the same sync and backup pipeline as everything else. If the provider’s app went away tomorrow — or just got worse — the work the agent did for you is still yours: on your disk, greppable by anything. Chat history in a vendor’s app is rent; a Markdown cache in your own vault is ownership.

Canvas is JSON, so diagrams become programmable

The Canvas whiteboard looks like a drawing tool, but a .canvas file is a small JSON document — the JSON Canvas spec has been public since March 2024: one array of nodes, one array of edges, a handful of node types, coordinates in pixels. That’s simple enough for an agent to write correctly, which changes what the tool is for. Low-fi wireframes, UX flows, persona maps: generate the JSON in your design directory where the agent already has context, copy the file into the vault, and refine it by hand in the app. Opening a full design tool for a rough sketch is overkill; opening a programmable one is a workflow.

Ops notes: keep generated and hand-written apart

Once agents write into your vault, you owe the folder the same discipline you’d give any generated artifact tree:

• Scope by folder. Generated content lives in /index/ and /cache/; your own writing lives everywhere else. Don’t hand-edit generated files — fix the source and regenerate, the same rule as any Terraform output.
• Put the vault in git (or at least snapshot it). Agent writes become reviewable diffs instead of silent mutations, and “regenerate the dashboard” becomes reversible.
• Your backup pipeline already covers it. The vault is a folder, so Syncthing, rsync or restic handle it with zero new machinery — no export button, no lock-in ritual, no vendor watching your export limits.

The note-taking is fine. It’s just the least of it. What replaces a whole workflow stack is the substrate: a folder of plain files your editor, your scripts, your sync, your backups and your agents can all treat as home turf. Apps are rentable; that folder is yours.

The first service worth standing up in a home lab isn’t a dashboard or a media server — it’s the front door. The reverse proxy is the one box every future service has to pass through: it terminates TLS, hands out friendly names, and quietly decides how much friction each new container will cost you. So which one would I hang today, starting from zero? Brandon Lee’s answer at Virtualization Howto is Pangolin, and having run the alternatives across different labs, I agree. Not because Pangolin is the simplest tool on the list — it isn’t — but because it’s the only one whose growth path doesn’t begin with “migrate”.

What each candidate actually optimizes for

Every popular proxy is good at something specific, and the marketing rarely says what:

• Nginx Proxy Manager optimizes for the first hour: point, click, done. It’s a single-node GUI over Nginx, and it stays simple right up until that one container is the dependency for every friendly name you own.
• Traefik optimizes for infrastructure-as-code: labels on containers, config that lives with the workload, nothing to drift out of sync. Inside a Kubernetes shop it’s close to a default; standalone, it’s more ceremony than a small lab needs.
• Caddy optimizes for minimal machinery: a two-line file, automatic HTTPS, done. Lovely for a static site. Not a platform.
• Pangolin optimizes for a different question entirely — not “how do I terminate TLS” but “how do I reach my stuff safely, from anywhere, as it grows”: proxying plus user access, tunneling, DNS coordination and clustering behind one dashboard.

That last bullet is the tell. Most home labs answer the TLS question first and discover the access question two years later — usually the week someone needs to reach a service from another country. Pick the tool that answers the second question without a migration.

The quick setup is genuinely quick

Pangolin’s installer collapses install, DNS and certificate issuance into one flow instead of three tools duct-taped together:

curl -fsSL https://digpangolin.com/get-installer.sh | bash
./installer

Answer the wizard — say no to the cloud-managed beta node if you want a purely local, NPM-style experience — then adopt the node in the dashboard using the ID and secret the installer printed. Three containers come up: traefik for HTTP/HTTPS routing, pangolin as the control plane and API, and gerbil for WireGuard ingress. From there the mental model is three objects: a site (a network location), a domain (NS delegation for a whole zone, or a CNAME for a single name), and a resource (a hostname plus the backend it forwards to). Create a resource and the Let’s Encrypt certificate goes from pending to valid on its own.

What’s worth appreciating isn’t the speed — it’s that the DNS record, the cert and the proxy rule are one integrated object instead of three config stores that can silently disagree with each other. Most “the proxy is down” incidents are really “two of those three drifted”.

Newt is the feature that changes your architecture

A Newt is a small agent you run on a machine in some other network — a VPS, a relative’s house, a client site behind consumer NAT — and it tunnels back to your Pangolin. You can publish a service from behind that NAT without opening a single port on its router. If you’ve used Cloudflare Tunnel or a Tailscale funnel, you know the shape; the difference is that the edge, the policy and the logs sit on your box, not a vendor’s. For a small business that’s the whole pitch: remote access with vendor-shaped ergonomics and self-hosted ownership. And if all you ever wanted was NPM-style proxying inside the lab, you can simply never install a Newt — the simple case stays simple.

The trade-offs to walk in knowing

• It’s a platform, not a proxy. Cloud coordination, DNS handling and failover run through a fossorial.io account (the dashboard at pangolin.fossorial.io). Local-only mode covers the NPM-style case, but read the coordination terms before you delegate a zone you care about.
• It’s young. Traefik and Nginx have decades of production scar tissue; Pangolin is still earning its calluses. Pin versions and treat upgrades as events, not chores.
• More moving parts than NPM. Three containers before you’ve configured anything — and if you later chase high availability, the parts list grows again: PostgreSQL, Valkey, and a load balancer you provide yourself. Clustering went self-service in 1.23, and that build has its own real costs — it’s a weekend project, not a checkbox.

When I’d still pick something else

• Everything already runs in Kubernetes — use Traefik. Its CRDs and label-based discovery are the native answer there, and a second proxy in front of an ingress is just noise.
• You need exactly one public site with automatic HTTPS and nothing else — Caddy is less machinery to own.
• Everything is strictly LAN-side and you want a GUI — NPM is lighter than a platform, and “never tunnels, never clusters” is a perfectly fine constraint to hold.

The default answer has changed because the question changed. Remote access and per-user control stopped being exotic the moment other people started depending on your services. The front door is the last component you want to replace under load — pick one you won’t have to. For a fresh build today, that’s Pangolin.

There’s a genre of GitHub repo that’s more interesting as an engineering artifact than as a product, and 199-biotechnologies’ deep-research skill for Claude Code is a clean specimen. On the surface it’s a research tool: point it at a question, get a citation-backed report out. Under the surface it’s something I find far more worth talking about — a working demonstration that the difference between “an LLM wrote me a plausible report” and “a report I can actually act on” is not a smarter model. It’s process.

What’s actually in the box

Strip away the branding and the repo is two things: a markdown skill file that tells Claude Code how to behave, and a handful of plain Python scripts that check its homework. The pipeline runs in phases — scope the question, plan, retrieve with parallel searches, triangulate sources, refine the outline, synthesize, critique, package — and you pick your pain: Quick mode runs three phases in a few minutes, Standard runs six, Deep runs all eight, and UltraDeep grinds for the better part of an hour. Reports land on disk as markdown plus a formatted HTML copy and a print-ready PDF.

None of that is exotic. That’s the point. There’s no fine-tuning, no exotic infrastructure, no API beyond the model you’re already running. It’s a checklist, a file layout, and some scripts. The whole thing installs by cloning a directory:

git clone https://github.com/199-biotechnologies/claude-deep-research-skill.git ~/.claude/skills/deep-research

The unglamorous parts are the whole point

Read the feature list and the eye-catching stuff — “multi-persona red teaming,” “adaptive quality thresholds” — matters less than the boring lines. Three of them are worth stealing outright.

First: Step 0 fetches the current date before any searching. The stated reason is that models assume their training-data year, and one stale year silently corrupts every “latest” claim downstream. That’s a bug I’ve personally watched happen in production agent work, and the fix costs nothing — a single cheap tool call up front that de-risks the entire run. It’s the research equivalent of checking the timezone before you build a cron schedule.

Second: citations are persisted to disk, not held in context. The sources file survives context compaction and hand-offs between sub-agents. Anyone who’s run long agent tasks knows the failure mode: halfway through, the context gets trimmed, and the thing quietly forgets where its facts came from. Making the bibliography a file — state on disk, not memory — is the same lesson as keeping your infrastructure config in a repo instead of in someone’s head.

Third: validation is automated and loops. A script checks the report’s structure, another chases the citations — real URLs, real DOIs, hallucination detection — and if validation fails, it fixes and retries, up to three cycles. The spec is refreshingly concrete: at least ten sources, at least three per major claim, no placeholder URLs in the bibliography. That last line is doing more for trust than any amount of model cleverness, because it’s not asking the model to be honest. It’s checking.

The critique loop is just retry-with-error-messages

The phase I find most quietly satisfying is the critique loop-back: if the critique phase finds critical gaps, the pipeline returns to retrieval with delta-queries — “go find these specific missing things” — rather than starting over. Anyone who’s written CI recognizes this instantly. It’s a failing test with a useful error message, applied to prose. The naive approach to bad research output is “regenerate and hope”; the engineered approach is “fail, state precisely what failed, and retry only the failed part.” The fact that this works as well as it does on a language model is a small, practical argument that agents respond to structure — you get better behavior by constraining the workflow than by pleading with the model in the prompt.

The same goes for the red-team personas — a skeptical practitioner, an adversarial reviewer, an implementation engineer, each reviewing the draft from their own seat. It sounds fancy until you notice what it really is: making the reviewer’s checklist explicit and running it more than once, from different angles, which is what a decent design review has always been.

The honest costs

To be fair about what this needs: the good path uses an aggregated search CLI that wants at least one paid or free-tier search API key (the repo lists Brave, Serper, Exa, Jina, Firecrawl), with the harness’s built-in web search as a rate-limited fallback. Time is the other cost — minutes for quick modes, 20–45 for UltraDeep — so match the mode to the stakes. And read the README’s “outperforms OpenAI, Gemini, and Claude Desktop” claim the way you’d read any vendor benchmark: skeptically. The repo can’t validate itself into being the best; what it can validate is internal consistency — sources exist, citations resolve, structure holds. That’s the part worth copying regardless of whose leaderboard you believe.

Steal the pattern even if you never run it

Where this actually earns its keep for a small business or a homelab is the pattern, not the tool. The task class is “produce a document someone will make a decision from” — comparing two vendors, choosing a self-hosted stack, sizing a backup strategy. The failure mode of doing that with a chat model is a confident, well-formatted answer whose sources are half-invented, and the cost of acting on it is real money and real time.

So steal four things. Write the acceptance criteria before the research starts — “every claim names a source I can open” is a spec, and specs beat vibes. Persist evidence as files, not conversation. Separate the producing step from the checking step, and give the checker a script instead of a feeling. And when the check fails, loop back with the specific errors rather than starting from scratch. None of this is AI magic. It’s the same discipline you already apply to deployments — the novelty is just that the artifact under test is a document instead of a build.

The model provides fluency. The pipeline provides trust. Watching them split cleanly across a repo’s directory layout makes that distinction impossible to unsee — which is why this one’s worth a browse even if you never clone it.

I saved a link last week titled “How to tell if a USB-C cable supports video” because I’ve spent enough hours in meeting rooms watching a presenter’s laptop mirror to a monitor at 30Hz to know the punchline before the article does: the culprit is almost never the laptop, the monitor, or the dock. It’s a $12 cable that somebody grabbed off a shelf, and it charges the laptop just fine, so nobody ever suspected it. The article’s advice — look for the DisplayPort logo, the Thunderbolt lightning bolt, or a 10Gbps speed rating — is correct as far as it goes. But if you run desks for a small business or a homelab bench, the real takeaway is bigger than the glyphs: USB-C cables are not a commodity, and the moment you buy them like one, you’ve outsourced your desk’s reliability to whoever had the cheapest three-pack.

One connector, four different cables

The reason the article exists at all is that “USB-C” names the shape of the connector, not what flows through it. Behind an identical oval plug you can find a USB 2.0 cable that maxes out at 480Mbps and can’t carry a video signal at all, a 5Gbps cable that can, a full-featured cable with the DisplayPort Alt Mode wiring and an e-marker chip that negotiates 100W or 240W of charging, and a Thunderbolt or USB4 cable that turns the port into a PCIe bus. Any of them will charge a phone. Only some of them will drive a monitor. That asymmetry — works for power, fails for video — is exactly why bad cables survive in the wild. The one symptom you’d notice (no picture) gets blamed on the screen, and the one test people do run (does it charge?) passes.

So the glyph-checking advice is genuinely useful: the DisplayPort logo means DP Alt Mode, the lightning bolt means Thunderbolt, and a cable printed with USB 3.1 Gen 2 / 10Gbps or better almost always carries video. A cable with no markings at all should be treated as a charging cable, because that’s usually what it is.

The audit beats the glyph hunt

Here’s the part the article leaves out: you don’t need to read logos mid-crisis if you spend one afternoon getting ahead of it. Count the cables in your life — desk drawer, laptop bag, meeting room, media bench. In a typical small business I’d bet at least two-thirds of them are 480Mbps charging cords, and nobody knows which two are the good ones. So audit once:

• Pull every cable that might ever touch a display or a dock. Check for the DP logo, the lightning bolt, or a printed speed rating. Anything unmarked goes in the “power only” pile and stops pretending to be more.
• Physically test the survivors. Laptop with a DP-capable USB-C port, monitor, one cable at a time. Thirty seconds each. (On Linux, the mode line in your display settings — or xrandr on the command line — tells you instantly whether you negotiated 4K60 or got stranded at 1080p.)
• Label them. A bit of tape or a label maker: “4K/DP” on the ones that pass. This is the homelab lesson applied to the office — you label the patch leads in the rack so 2am-you isn’t guessing, so label the desk leads too.
• Throw out the anxiety ones. The cable that worked once and flickers sometimes is worse than no cable. It will work in front of a client and fail in front of you.

Buy certified where it matters, stop at the drawer

My purchasing rule has two tiers, and the opinionated part is that they’re not the same cable. For the fixed desk — laptop to dock, dock to the monitor that matters — buy certified cables: Thunderbolt-certified if the dock is Thunderbolt, USB-IF certified full-featured otherwise, and buy two of each so the spare exists the day you need it. These are the paths where a mystery cable costs you an hour of someone’s meeting or an afternoon of “the monitor keeps dropping out.” For the junk drawer and the loaner bag, cheap cables are fine — if they’re honest about being charging cables. The failure mode isn’t cheap, it’s unknown.

One more trap from the article worth repeating: adapters don’t rescue bad cables. A USB-C-to-HDMI adapter converts the signal but still needs the source cable to be full-featured enough to carry it. People “upgrade” to an adapter, keep the same dead cable upstream, and conclude adapters don’t work. The cable is the path — the adapter is just a different door at the end of it.

Why this is an ops problem, not a shopping problem

If this reads like a lot of ceremony for cables, consider what a flaky cable actually costs you. Not $12 — an unexplained dropped screen share, a support ticket that says “the dock is broken,” a spare-parts scramble five minutes before a video call, or a monitor blamed and RMA’d for a fault it never had. That’s the same shape as every other “it’s probably the network” mystery: an unverified component silently inside the blast radius. Cables sit in the same category as patch leads and power bricks — boring until they’re the outage.

Three lines, then. Buy certified for anything that moves pixels or a laptop’s full power. Test and label what you already own, once. And the next time a monitor “breaks,” the cable is now the first suspect instead of the last — which, if you’ve ever watched someone reboot a projector in front of a room full of people, is worth the afternoon.