Category: Uncategorized

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

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

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

The filing tax

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

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

One container, one volume

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

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

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

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

Tags do the filing for you

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

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

Where it sits next to a vault

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

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

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

The honest limits

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

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

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

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

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

Audit the jobs, not the tools

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

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

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

The chat habit: Jan

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

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

Search with receipts: Vane

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

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

The coding agent that doesn’t own you: OpenCode

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

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

The remaining seats

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

What I’d still pay for

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

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

Your app stack is a state-replication problem

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

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

The vault is the database

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

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

Dashboards are generated, never hand-edited

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

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

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

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

What it actually replaced

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

Where text honestly loses

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

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

Guardrails before you hand over the keys

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

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

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

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

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

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

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

Buy for the drawer, not the project

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

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

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

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

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

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

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

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

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

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

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

Infrared: making dumb appliances honest

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

The garage door, back under local control

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

The one I’d skip

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

The pattern worth taking away

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

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

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

First, the uncomfortable truth about trackers

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

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

What Plane actually is

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

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

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

Self-hosting is the point

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

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

When you shouldn’t do this

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

The pattern I’d run

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

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

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

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

What Thunderbolt 5 actually buys you

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

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

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

Keychron’s port math

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

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

The catches that should shape your decision

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

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

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

The field at $350

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

Should a homelab buy it?

My checklist, having watched this category for a while:

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

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

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

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

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

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

What you get around one saved server

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

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

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

The two features that earn the install

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

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

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

The honest caveats

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

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

Who should switch

My decision list after a week with it:

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

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

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.