Build the open-source column, for real.

Primary interface

index.html currently says: “Terminal, self-hosted web UIs (Open WebUI), Home Assistant voice for ambient pickup.”

Recommendation: Start with Home Assistant's Assist pipeline if ambient, hands-free pickup is the goal — it's the only one of the three actually designed for “walk up and talk,” and it's fully local end to end. Layer Open WebUI on top for a shared, multi-user chat surface, but budget time to read the 2025 license change before deploying it beyond a household. Keep oterm in the toolbox for quick, no-server terminal access to the same local models — it has near-zero setup cost, but it's single-user.

Plays well with: Core architecture — Home Assistant Assist needs a local inference backend, and Open WebUI and oterm can point at that same backend, so all three can share one self-hosted model server rather than three separate stacks.

Agrees with index.html's current claim. Open WebUI and Home Assistant's Assist voice pipeline are both real, current, actively-maintained projects that do what the claim says, and a terminal remains a genuine, low-overhead primary interface for this kind of self-hosted stack.

Touchscreen GUI

index.html currently says: “Linux touch support is real but patchy — and open computer-use agents can drive a screen too” (status: caveat).

Recommendation: If you already run a Linux desktop, don't add anything — GNOME's or Plasma Mobile's touch support (whichever your distro ships) is “good enough, patchy” out of the box and matches what index.html actually claims. Reach for Cua only for the narrower job of letting an agent operate a screen on your behalf. Don't reach for Open Interpreter for this job in 2026 — it's no longer a computer-use tool.

Plays well with: Natural language processing — Cua needs a vision-capable model to actually see and act on the screen, and this report's own NLP pick, Qwen3.6-27B, is already described as a multimodal model, so it doesn't need inventing a separate model for this job.

Agrees with index.html's current claim. Linux touchscreen support is genuinely inconsistent in current releases, and open, MIT-licensed computer-use agents (Cua) really can drive a screen today.

Natural language processing

index.html currently says: “Open-weight models are genuinely conversational — a step behind frontier on the hardest reasoning” (status: caveat).

Recommendation: For a home/self-hosted setup, start with Qwen3.6-27B — it's the only one of the three that realistically runs on a single consumer GPU. Reach for DeepSeek V4-Flash or Mistral Large 3 only if you have the hardware and want the strongest open-weight reasoning available, accepting both still trail the best closed frontier models on the hardest reasoning benchmarks. None of the three publish full training-data provenance, so “open-weight” should not be read as “fully auditable.”

Plays well with: Core architecture — all three need a local inference runtime to actually self-host, and can share the same backend already referenced by the Primary interface row and the Touchscreen GUI row's computer-use pick (Cua, if a multimodal variant is used).

Agrees with index.html's current claim. DeepSeek V4, Qwen3.6, and Mistral Large 3 are all genuinely conversational, currently-maintained open-weight models, and independent 2026 benchmarking confirms the best of them still sit a notch behind top closed frontier models on the hardest reasoning tasks, exactly as the claim states.

Ship terminal / console hardware

index.html currently says: “Framework laptop or desktop — modular, repairable, upgradeable; still no fixed bridge console.”

Recommendation: Start with Framework if the goal is a practical daily-driver stand-in for a bridge console — it's the literal product named in the claim, x86-performance-competitive, and its repairability is real even though its “openness” is partial. Add System76's open firmware if boot-level transparency matters more than modularity. Reserve MNT Reform Next for readers who want a genuinely 100%-open, OSHWA-certified machine and are willing to trade raw performance and mainstream software compatibility for it.

Plays well with: Primary interface and Core architecture — all three can run the same self-hosted stack referenced elsewhere in this report (a local-LLM backend, Open WebUI, Home Assistant Assist) as a home “ops console.” Also cross-links to Self-repair capability: Framework's published schematics/EC firmware are the same #1 pick there, for a different reason (repairability documentation rather than daily-driver modularity) — a reader who picks Framework for one gets the other for free.

Agrees, with a caveat, with index.html's current claim. Framework genuinely is modular/repairable/upgradeable and remains actively developed in 2026, but its “open source” framing should be tightened: it's open-ish (CAD, EC firmware, and Expansion Card specs are open; mainboard schematics are only partial), not a certified open-hardware design the way MNT Reform is.

Personal access device

index.html currently says: “Fairphone — a user-replaceable battery beats a PADD.”

Recommendation: Fairphone 6 remains the strongest default — index.html's specific claim about a user-replaceable battery is accurate today, repairability is independently verified, and performance is mainstream-competitive, at the cost of running a fairly ordinary (if de-Googleable) Android build. Choose the Librem 5 only if genuinely open-source software matters more than raw performance. Volla Phone sits in between: a smaller company with less mature repair support, but an OS that's open source out of the box.

Plays well with: Personal communicator — /e/OS (that row's recommended pick) runs on Fairphone 6 as Murena's flagship device, so choosing Fairphone here and /e/OS there is the same real-world combination that row's claim describes. The Librem 5 pairs with its own PureOS/Phosh stack instead.

Agrees with index.html's current claim. Fairphone genuinely offers an independently-verified user-replaceable battery and is the strongest currently-available repairable-phone pick, though the claim slightly conflates “open source” with “repairable/ethical.”

Handheld sensor device

index.html currently says: “Open hardware boards + SDR + thermal cams — more tricorder-like, more assembly required.”

Recommendation: If matching the claim exactly (SDR + thermal, DIY assembly) is the goal, M5Stack's modular Units are the most literal fit and cheapest entry point, but expect real soldering/coding/case-design work. HackRF One + PortaPack Mayhem is the better pick if RF-scanning is the priority and a finished, ready-to-use handheld matters more than modularity. Flipper Zero is the best starting point for someone who wants a low-assembly device today, accepting it covers a narrower set of “senses” and carries a small amount of firmware-roadmap uncertainty.

Plays well with: Ship terminal / console hardware — the Framework/System76 machines there are the natural flashing/development host for all three — HackRF/Mayhem firmware builds, Flipper Zero's qFlipper updater, and M5Stack's Arduino/UIFlow tooling all run from a normal Linux laptop.

Agrees with index.html's current claim. Real open hardware SDR (HackRF) and thermal-camera modules (M5Stack) exist and are tricorder-like, but none of the three is a single finished tricorder — all require meaningfully more assembly/configuration than the show's one-button device.

Personal communicator

index.html currently says: “Fairphone on /e/OS + Signal — E2E-encrypted comms on hardware you can open with a screwdriver.”

Recommendation: /e/OS + Signal best matches the claim as written — repairable Fairphone hardware plus a de-Googled OS plus E2EE messaging, all currently shipping and maintained. Recommend GrapheneOS + Signal instead only for readers who prioritize hardened security over repairable/ethical hardware. Signal itself is close to non-negotiable either way.

Plays well with: Personal access device — this row is the software/communications half of that row above; /e/OS is literally the OS Murena preinstalls on the Fairphone 6 recommended there, so “Fairphone 6 + /e/OS + Signal” is one coherent real-world stack across both rows. Choosing GrapheneOS here instead pulls a reader toward Pixel hardware, away from that row's Fairphone pick.

Agrees with index.html's current claim. Fairphone on /e/OS with Signal is a real, currently-shipping, actively-maintained combination that does deliver genuine E2E-encrypted communication on repairable hardware, exactly as claimed.

Storage medium

index.html currently says: “Self-hosted NAS or E2E-encrypted cloud (Proton Drive) — either way, only you hold the keys.”

Recommendation: Start with TrueNAS Community Edition if the goal is literally “self-hosted NAS” — it's free, open source, ZFS-backed, and its 2026 roadmap keeps it current. Reach for Nextcloud Hub instead of Proton Drive if self-hosting matters more than convenience. Proton Drive remains the right pick for readers who want the claim's specific named product and are comfortable trusting Proton's infrastructure rather than operating their own box.

Plays well with: Processing redundancy — TrueNAS is the natural home for that row's redundancy tooling (it ships OpenZFS directly) and can serve as the storage backend for the Core architecture row's local-LLM inference stack or the Primary interface row's Open WebUI chat/RAG document storage.

Agrees with index.html's current claim. Self-hosted NAS software (TrueNAS) and Proton Drive's E2E-encrypted cloud are both real, current, actively-maintained options that put encryption keys in the user's hands rather than a third party's, exactly as the claim frames the choice.

Core architecture

index.html currently says: “Same transformers, quantized (GGUF) onto a consumer GPU or unified-memory mini PC at home.” This row covers local-LLM inference runtimes — the software that loads a quantized GGUF-style model and serves it — not which model to run; model selection is the Natural language processing row's job.

Recommendation: Start with Ollama for the actual “consumer GPU or unified-memory mini PC at home” case — it's the lowest-friction way to run a quantized GGUF model locally today, and it's cleanly MIT-licensed with no outstanding ambiguity. Drop to bare llama.cpp for tighter control over quantization/build flags. Reach for vLLM only once “one model, one user” stops being the real workload.

Plays well with: Onboard AI personality — whichever runtime is picked here becomes the shared local backend for Primary interface's Open WebUI/oterm/Home Assistant Assist and Touchscreen GUI's Cua. Ollama in particular does double duty: the same instance that serves the model here also holds the household's persona via a Modelfile SYSTEM directive in the Onboard AI personality row — one install, two jobs, not two unrelated tools.

Agrees with index.html's current claim. llama.cpp, Ollama, and vLLM are all real, currently-maintained runtimes that do exactly what the claim describes: take a transformer, quantize it to GGUF, and run it on a consumer GPU or unified-memory mini PC rather than a hyperscaler cluster.

Processing redundancy

index.html currently says: “Whatever redundancy you build — RAID and a second box, or it's a single point of failure.”

Recommendation: If the storage medium is already TrueNAS, OpenZFS is not a separate install — RAID-Z plus zfs send/receive to a second TrueNAS box is the most complete real-world match for “RAID and a second box” in one stack. Choose SnapRAID+mergerfs instead only if the array is a JBOD of mismatched drive sizes with mostly write-once media. Layer restic on top of either as the actual off-site “second box” leg regardless of which parity scheme is chosen.

Plays well with: Storage medium — builds directly on that row's TrueNAS pick (ZFS is TrueNAS's native filesystem) and can back up the same TrueNAS box's config/datasets that host the Core architecture row's model weights and any chat/RAG data from the Primary interface row's Open WebUI.

Agrees with index.html's current claim. Real, current open-source tools exist for both RAID-style redundancy (OpenZFS, SnapRAID) and second-box replication (ZFS send/receive, restic), but none of them is automatic — a reader who does nothing really is left with the single point of failure the claim warns about.

Compute core hardware

Bonus row, not on the pricing table: Storage medium, Core architecture, and Ship terminal / console hardware between them cover the NAS software, the inference runtime, and the laptop you sit at — but none of them names the actual box that runs TrueNAS and Ollama around the clock. This row exists because the reference stacks below keep saying “the household runs TrueNAS as the box underneath all of this” without ever saying what that box is.

Recommendation: Framework Desktop is the most complete match for the “consumer GPU or unified-memory mini PC” framing this whole report is built around — one box, one purchase, no GPU passthrough configuration required, and it's already the same vendor as the laptop pick above. Choose System76 Thelio instead if a discrete GPU with room to upgrade later matters more than compactness. Reach for the Minisforum MS-02 Ultra specifically to combine NAS and GPU inference in one small, cheap box — and go in accepting its firmware isn't open, unlike the other two.

Plays well with: Storage medium and Core architecture — this is the physical hardware TrueNAS and Ollama actually run on, and Processing redundancy's OpenZFS pool lives on its drives too. Distinct from Ship terminal / console hardware's laptops: that row is the machine a person sits at, this row is the machine that just runs, headless, around the clock.

Orchestration & deployment

Bonus row, not on the pricing table: every reference stack below says the household “runs TrueNAS and Ollama and Open WebUI and Keycloak on the same box” — but none of them names what actually makes a dozen services coexist on one machine. Almost everything in this report is normally deployed as a container, and the “all on one box” claim quietly assumes a runtime and, often, a hypervisor underneath it. This row is that missing substrate.

Recommendation: Start with Docker Compose — it's what almost every project in this report documents, and a per-stack compose.yaml is the lowest-friction way to bring up Open WebUI, Keycloak, Vaultwarden, Nextcloud, Headscale, Uptime Kuma, and CrowdSec reproducibly. Reach for Podman if rootless isolation or systemd-native management matters more than ecosystem ubiquity. Add Proxmox VE underneath both once you actually want TrueNAS and GPU-accelerated Ollama and a dozen containers on a single machine — virtualizing TrueNAS (with HBA passthrough) beside a container VM is the real-world shape of the “one box” every stack below assumes. A lighter alternative is to run TrueNAS on bare metal and use its own built-in app catalog — a Docker-Compose-based engine, separate from the LXC-style container instances noted in the Storage medium row — for the service layer.

Plays well with: Compute core hardware — this is the layer that actually runs on that box, and it's the unspoken dependency of nearly every software pick in this report: Open WebUI, Keycloak / Vaultwarden, Nextcloud, Headscale, Uptime Kuma, and the reverse proxy below are all normally deployed as containers on top of it.

Onboard AI personality

index.html currently says: “Any persona you like — the system prompt is yours to edit.”

Recommendation: Start with Ollama's Modelfile SYSTEM directive if you just want one or two fixed personas bound to specific local models — lowest-overhead option, no licensing caveats. Reach for SillyTavern if you want to swap between many distinct personas in a single session, accepting AGPL-3.0 copyleft terms if you redistribute a modified build. Open WebUI's Workspace/Models feature is the middle ground for a household, with the same branding-clause caveat already noted for the Primary interface row.

Plays well with: Core architecture — all three need a model to actually run, and Ollama is both a candidate here and the natural local-inference backend for the other two. This is the same Ollama instance doing double duty: one install, two jobs — serving the model (Core architecture) and holding the persona (this row) — not two unrelated discoveries of the same tool.

Agrees with index.html's current claim. Self-hosted tooling genuinely lets you write, edit, and swap any system prompt/persona you like, with no platform-imposed restriction on content, matching the “yes” status.

Autonomous decision-making

index.html currently says: “Open agent stacks run locally — capable, but you're the safety team.”

Recommendation: Start with CrewAI if the goal is a small, controllable multi-agent workflow — cleanly MIT-licensed, no platform lock-in, and its “Flows” mode keeps a human-in-the-loop checkpoint exactly where this row's caveat says you need one. Reach for OpenHands specifically for coding/dev tasks, and pair it with container-level sandboxing, not credentials wider than the task needs. Treat AutoGPT's classic agent as a historically important but now second-tier option, and note its newer “Platform” half is not MIT. None of the three ship a safety layer beyond basic sandboxing.

Plays well with: Known sentience risk — all three are LLM-agnostic orchestration layers that pair with the local-inference picks from the Core architecture row and can share the same open-weight model chosen for Onboard AI personality. For guardrails against exactly the unsupervised-action risk this claim flags, pair any of the three with the guardrail/red-teaming tooling in the next row.

Agrees with index.html's current claim. CrewAI, OpenHands, and AutoGPT are all real, current, self-hostable agent stacks capable of genuine autonomous multi-step action, and none of them include a built-in safety reviewer: the operator is unambiguously the safety team.

Known sentience risk

index.html currently says: “Same open question — but at least you can read the weights.” This row is a reinterpretation, not a literal sentience test: no open-source tool measures, detects, or rules out machine sentience — that remains a philosophical and scientific open question with no instrument that resolves it, in this codebase's fiction or in reality. The three candidates below are the closest real analog available — open-source tooling that tests whether a model or agent is behaving unexpectedly or unsafely (guardrail frameworks, vulnerability scanners, and red-teaming/jailbreak harnesses), reinterpreted onto AI safety and guardrails tooling rather than onto anything that answers the sentience question itself.

Recommendation: Closest real practice is guarding against unexpected/unsafe autonomous behavior — not measuring sentience, which no tool in this space claims or attempts to do. If running any of the agent stacks from the Autonomous decision-making row, start with NeMo Guardrails as the runtime layer, then use garak and/or PyRIT before deployment to probe for jailbreaks and prompt-injection weaknesses the guardrails might miss. All three are current, actively-maintained, permissively-licensed projects — but this row is a reinterpretation, not a real answer to “is it sentient”: that question has no open-source instrument, full stop.

Plays well with: Autonomous decision-making — directly complements that row's candidates (CrewAI, OpenHands, AutoGPT): NeMo Guardrails wraps around any of them as a runtime policy layer, while garak and PyRIT are used to red-team the underlying model before it's given agentic tool access. All three are model-agnostic and can point at the same local open-weight model chosen elsewhere in this group.

Disagrees with index.html's current claim, taken literally. The line plays along with the bit (“read the weights” as a stand-in for insight into sentience), which is fair satire, but taken literally it overstates what's real: no open-source tool, weight-readable or not, tests for or resolves the sentience question. The genuinely real practice available today is behavioral guardrails and red-teaming — a different (and answerable) problem than the one the row's label names.

Holodeck / holo-environments

index.html currently says: “Not available — SteamVR on Linux exists, still no photons with mass.”

Recommendation: There is no real candidate that rebuts “no photons with mass” — that stays true. For the closest practical open stack for room-scale shared VR today: start with Monado as the runtime layer (it's now a shared foundation several commercial headset vendors build on), add WiVRn if the headset is a standalone Android device that needs to talk to a Linux PC wirelessly, and use Hubs for the actual shared/social/persistent-space experience once hardware and runtime are sorted.

Plays well with: Monado and WiVRn are complementary layers (WiVRn is built on Monado), not competitors — pick both if the headset is a standalone Quest/Pico-class device. For local AI-driven characters populating a Hubs space, pair with Holographic crew — the persona/memory tooling in the next row.

Agrees with index.html's current claim. The verdict that full sensory, forcefield-assisted holodeck matter is “not available” remains accurate; SteamVR-on-Linux (and its genuinely open alternatives Monado/WiVRn) get you shared immersive VR, never tangible photons.

Holographic crew

index.html currently says: “Self-hosted personas persist exactly as long as your backups do.”

Recommendation: Start with Letta if the goal is one persistent named persona with a simple, inspectable memory model — it's a complete self-hosted agent server, and “restart and it remembers” is the most direct real-world match to the claim. Reach for Mem0 if there's already an agent/chat stack in place and only a memory layer is needed on top. Choose Graphiti specifically when the persona needs to track changing facts over time, but budget for running and backing up a real graph database. All three make the caveat literal: the persona is data, and it is exactly as durable as the database backups protecting it.

Plays well with: Onboard AI personality (Ollama Modelfiles, SillyTavern, Open WebUI) to give a persona both a personality/voice and a durable memory, and with the local-inference runtimes from Primary interface / Core architecture (Ollama, llama.cpp, vLLM) as the model actually doing the talking.

Agrees with index.html's current claim. Letta, Mem0, and Graphiti are all real, currently-maintained, self-hostable projects whose entire value proposition is that a persona's continuity is stored data; if you don't back that data up, the persona is gone, exactly as the row states.

Authorization method

index.html currently says: “Passkeys, FIDO2 hardware keys, Bitwarden / Proton Pass — auditable end to end.”

Recommendation: Start with Vaultwarden — it's the lowest-friction option and covers “Bitwarden” directly, with the one honest caveat that logging into the vault itself via passkey is still an open PR, not shipped. Reach for KeePassXC instead if “auditable end to end” needs to mean literally zero network dependency. Add Keycloak on top of either once there's more than one self-hosted service to protect — the closest real analog to a ship-wide command-code system.

Plays well with: Vaultwarden and KeePassXC are both password/passkey stores, not identity providers — either can hold the credentials a person uses to reach a Keycloak-protected login screen, and Keycloak in turn can be the OIDC provider in front of self-hosted apps like Primary interface's Open WebUI. All three are independent of model/inference choice.

Agrees with index.html's current claim. Passkeys, FIDO2 hardware keys, and self-hosted Bitwarden-compatible vaults are real, current, and (with a self-hosted server) genuinely auditable end to end; the one nuance is that this is strongest for KeePassXC (no server at all) and weakest for Vaultwarden's own login flow specifically.

Hostile takeover incidents (logged)

index.html currently says: “Same prompt-injection problem, and you're your own security team — but the attack surface is inspectable.” Reinterpreted row: there is no real-world “hostile takeover incident log” analogous to a starship being boarded. The honest real-world analog is home-lab/network-layer intrusion detection and hardening — the firewall, IDS/IPS, and log-based threat-detection tooling a self-hoster actually runs to notice and stop unauthorized access to their own infrastructure. The candidates below are evaluated against that real practice, not a literal takeover log.

Recommendation: Layer all three rather than picking one: OPNsense as the perimeter firewall, Suricata (bundled or standalone) watching the wire for known attack signatures, and CrowdSec tailing application/service logs to catch brute-force and scan behavior a signature-based IDS alone would miss. None of these produce anything like a “confirmed boarding” count — what a self-hoster actually gets is a stream of blocked-IP and rule-match log entries they have to review themselves.

Plays well with: CrowdSec and Suricata both benefit from being fed logs/traffic from whatever else is self-hosted elsewhere in this project (reverse proxies, SSH daemons, the local-LLM web UIs from Primary interface), and both can run natively on or alongside an OPNsense box. None of the three are specific to AI/LLM tooling.

Disagrees with index.html's current claim, taken literally. The claim is about AI agent security, and there is no real “hostile takeover incident log” to compare it against for a self-hosted setup, fictional or otherwise. The genuinely real practice available today is network/log-based intrusion detection and hardening (OPNsense, Suricata, CrowdSec) — a different, narrower, and answerable problem than “has my system been taken over,” but the self-hoster genuinely is their own security team, and the tooling above is what makes the attack surface inspectable rather than a black box.

Secure device networking

Bonus row, not on the pricing table: Authorization method covers who's allowed in, and Hostile takeover incidents covers watching the perimeter for attackers — neither answers how the Fairphone in your pocket actually reaches the TrueNAS/Ollama box at home once you've left the building. Personal communicator's Signal pick encrypts chat, not this. This row is that missing transport layer.

Recommendation: Start with Headscale — it gets Tailscale's actual day-to-day convenience (MagicDNS, exit nodes, works through most NATs) while keeping the one piece that matters for this project's whole premise, the coordination server, on hardware in the house. Tailscale itself is the right call only for readers who've decided the peer-discovery trust trade-off is acceptable in exchange for zero maintenance. Drop to plain WireGuard only if the household is small and static enough that manual peer configuration isn't a burden.

Plays well with: Compute core hardware — Headscale's coordination server is one more service that runs on the same box as TrueNAS and Ollama, and once it's up, every device on the mesh (the Fairphone, the Framework laptop) can reach Open WebUI/oterm and Nextcloud/TrueNAS exactly as if it were on the home LAN, from anywhere.

Reverse proxy & TLS

Bonus row, not on the pricing table: Authorization method puts Keycloak “in front of Open WebUI and any other dashboard,” and Secure device networking gets your devices onto the same mesh — but nothing in either row actually terminates HTTPS, routes a hostname to the right container, or presents a single trusted certificate. Every web UI in this report is served over plain HTTP by default. This row is the layer that fixes that.

Recommendation: Start with Caddy — automatic HTTPS with a near-trivial config is exactly what a home stack wants, and it removes the single most common reason self-hosters skip TLS entirely. Choose Traefik instead if the deployment is many short-lived containers and label-driven auto-discovery saves real toil. Nginx Proxy Manager is the right pick only if a browser GUI matters more than a version-controllable text config. Whichever you pick, note that Keycloak only gates apps that speak OIDC natively — for the ones that don't, add a forward-auth layer (Authelia, licensed Apache-2.0, or oauth2-proxy) at the proxy so the SSO front door actually covers them.

Plays well with: Secure device networking and Authorization method — behind Headscale, the reverse proxy is the one service every request lands on first, so it's the natural place to enforce TLS and hang forward-auth off Keycloak. It fronts every browser-facing pick in this report: Open WebUI, Nextcloud, and Uptime Kuma. It is itself deployed via Orchestration & deployment.

DNS & network-level filtering

Bonus row, not on the pricing table: Secure device networking's Headscale gives you MagicDNS across the mesh, but that only names devices on the tailnet. Nothing in the report resolves names for the home LAN, blocks ads and tracker/telemetry domains network-wide, or lets you avoid handing every DNS query to a public upstream resolver. This row is that piece.

Recommendation: Start with Pi-hole — it's the ubiquitous choice, covers network-wide blocking and local LAN records in one place, and has the deepest community documentation. Choose AdGuard Home instead if you want encrypted upstream resolution and per-client policies without bolting on extra pieces. Add Unbound behind either one when “only you hold the keys” should extend to DNS too: a Pi-hole + Unbound pair depends on no public resolver at all.

Plays well with: Secure device networking — Headscale's MagicDNS handles names on the mesh while this handles the LAN and egress filtering, and the two compose cleanly (point the tailnet's global nameserver at Pi-hole). It also complements Hostile takeover incidents: DNS-level blocklists cut off command-and-control and telemetry domains that packet-inspecting IDS/IPS would only see after the connection opens. Deployed via Orchestration & deployment.

Universal translator

index.html currently says: “Whisper + open translation models run locally — near-real-time, fewer languages, no cloud required.”

Recommendation: Start with whisper.cpp for the speech-to-text leg — it's the most actively developed of the group and its stream example is a working near-real-time local transcription pipeline out of the box. Feed its output into Argos Translate directly for a single-device/single-user setup, or LibreTranslate if multiple devices/apps need to share one translation service. The honest caveat the row already states holds up: local models cover a real but limited language list, and end-to-end latency is “near-real-time,” not instant.

Plays well with: Primary interface's Home Assistant Assist voice pipeline for wake-word-triggered translation, and with local TTS engines (e.g. Piper) to close the loop into spoken output — note Piper is archived upstream (last pushed 2025-08-26), still functional and widely used, just not actively developed (see the Primary interface row's own caveat). None of these three depend on any AI-autonomy or data-storage picks from other groups.

Agrees with index.html's current claim. Whisper-family speech recognition plus locally-run open translation models is a real, currently-maintained, no-cloud-required stack, and “fewer languages” than a commercial cloud service is an accurate, not exaggerated, limitation.

Stellar cartography

index.html currently says: “Stellarium + open sky-survey data — the actual star charts are already open source.”

Recommendation: Start with Stellarium if the goal is literally “open star charts” — it's the most direct match for the row's own wording, the most active of the three by commit cadence, and its NavStars plugin is a genuine celestial-navigation dataset. Add KStars instead (or alongside) if the point is to actually use the charts to navigate. Reach for OpenSpace only if the ambition is the full “flying through a 3D star field” cartography-deck experience — real and actively maintained but a heavier, more specialized install.

Plays well with: KStars' INDI backend is the same protocol used by most open-source telescope-control and astrophotography tooling, so it extends naturally into any Handheld sensor device picks involving telescopes/mounts. All three consume the same class of open astronomical data (Gaia, Hipparcos, DSS), so none of these choices are exclusive.

Agrees with index.html's current claim. Stellarium and the open star-survey data behind it (Hipparcos, Gaia) are real, currently maintained, and genuinely open source; the row's own caveat framing is honest, since a planetarium app viewing public survey data is a much smaller thing than a starship's active-sensor stellar cartography deck.

Self-repair capability

index.html currently says: “The system can't fix itself, but you can — schematics, parts, and source are all published.”

Recommendation: Start with Framework if buying new: it's the only one of the three that is itself a vendor selling the exact parts and schematics the claim describes, at real consumer prices, with an official repair guide for every part. Keep iFixit as the go-to for anything you already own that wasn't designed this way. Treat PINE64 as the “as-open-as-it-gets” option for readers who want hardware with zero vendor lock-in and are willing to trade some polish and support responsiveness for it.

Plays well with: Ship terminal / console hardware — both rows independently rank Framework Computer's Laptop 13/16/Desktop line as their #1 pick, for two different reasons (that row: modular/repairable daily driver; this row: schematics/parts/EC-firmware openly published). A reader who picks Framework for one gets the other for free. PINE64 also overlaps with Handheld sensor device — a repairable body is only half the story if the internals (SBCs, displays, batteries) aren't also documented. iFixit's documentation is generic reference material that applies regardless of which hardware picks a reader makes elsewhere in this report.

Agrees with index.html's current claim. The caveat framing is accurate: none of these projects make hardware self-repairing or self-diagnosing, they simply guarantee that a human doing the repair has schematics, parts, and documented procedure, which is exactly what the claim says.

Uptime (malfunction-free episodes)

index.html currently says: “Your homelab, your SLA — exactly as good as your backups.” Reinterpreted row: there is no real-world “malfunction-free episode” percentage for a self-hosted stack. The honest real-world analog is the self-healing/monitoring practice a self-hoster actually runs to keep uptime high and notice failures fast — status/uptime monitoring, heartbeat/dead-man's-switch checks for scheduled jobs, and auto-restart/auto-remediation tooling for containers. The candidates below are evaluated against that practice, not a literal malfunction-free-episode count.

Recommendation: Run Uptime Kuma first — it's the lowest-effort, highest-visibility piece and covers the “is anything down right now” question the claim gestures at. Add Healthchecks.io specifically to watch backup/cron jobs, since silent backup failure is the actual risk the claim calls out and a service-uptime monitor alone won't catch it. Treat nicholas-fedor/watchtower as optional and lower-priority — if adopting it, use the fork, not the archived containrrr/watchtower.

Plays well with: All three assume something is already self-hosted to monitor — they pair with whichever storage/processing stack a reader runs from Storage medium and the AI/model-serving stack from Core architecture. Healthchecks.io in particular is only useful once a reader has scheduled backup jobs to watch, so it depends on a real backup routine existing first.

Agrees, with reinterpretation, with index.html's current claim. There's no real percentage to compare against a fictional malfunction-free-episode figure, but the claim's underlying point (“your homelab, your SLA — exactly as good as your backups”) is accurate: a self-hoster's real uptime is a direct function of the monitoring and backup discipline they build themselves, not a vendor guarantee.

Support channel

index.html currently says: “You are the chief engineer — plus forums, Matrix rooms, and GitHub issues.”

Recommendation: Start with r/selfhosted for general “what should I run” and troubleshooting questions — it has the widest reach and fastest response for common problems. Use a project-specific forum like Home Assistant's Discourse once you've committed to a specific piece of software and need deep, searchable history on that project's quirks. Reach for a Discord like LinuxServer.io's when you need real-time back-and-forth on a live problem — but verify the specific community you land in is still the active one for that project.

Plays well with: These are general-purpose human support channels that apply regardless of which specific software picks a reader makes across the other seven groups in this report — r/selfhosted and Home Assistant's forum in particular will have existing threads on almost any project named elsewhere in this research (Uptime Kuma, Open WebUI, Immich, etc.), so they're a first stop for troubleshooting any of this project's other recommendations.

Agrees with index.html's current claim. “You are the chief engineer — plus forums, Matrix rooms, and GitHub issues” is an accurate summary of self-hosted support reality: there's no vendor on-call engineer, but large, currently-active peer communities genuinely substitute for one, which is exactly what the claim says.

Observability — metrics & logs

Bonus row, not on the pricing table: Uptime's Uptime Kuma answers “is it up?” — but not “why is inference slow tonight?”, “is the ZFS pool filling up?”, or “what did the firewall actually block?” Also, OPNsense, Suricata, and CrowdSec emit a stream of security logs that, as that row admits, a self-hoster “has to review themselves” — with nothing aggregating or correlating them. This row is the metrics-and-logs layer that closes both gaps.

Recommendation: Start with Netdata — it's the highest insight-per-minute-of-setup of anything here, and on a single-box homelab it may be all the metrics you need. Graduate to Prometheus + Grafana once you want retention, historical dashboards, and unified alerting across several machines (add Grafana Loki, AGPL-3.0, for logs into the same Grafana). Add Wazuh specifically for the security-log half of the problem: it's the SIEM that turns Suricata/CrowdSec/OPNsense's review-it-yourself log stream into correlated, searchable alerts.

Plays well with: Uptime — Uptime Kuma answers up/down, this answers why and since when. Wazuh in particular is the missing correlation layer over Hostile takeover incidents's logs, and Netdata's ZFS and Docker collectors watch exactly the TrueNAS pool and container runtime that everything else in this report runs on.

Power & UPS

Bonus row, not on the pricing table: this whole report's premise is that your data lives on hardware you own — and a ZFS pool that loses power mid-write, with no clean shutdown, is exactly how you lose the data the “only you hold the keys” theme is built to protect. Nothing anywhere else in the report handles graceful shutdown on power loss. This row is that safeguard.

Recommendation: Use NUT — one UPS signalling every box on the network to shut down cleanly is exactly the coordination a multi-machine homelab needs, and it's the only option here that isn't vendor-locked or dormant. Reach for apcupsd only for a single directly-attached APC unit where its simpler setup outweighs its stalled development. In practice, if you took this report's TrueNAS pick, NUT is already there — enable its UPS service and this row is mostly done.

Plays well with: Compute core hardware and Storage medium — it's what protects the ZFS pool and any in-flight writes on the always-on box, and it turns a yanked-power event (the classic cause of a failed pool import) into a non-event. It's the physical-world complement to Processing redundancy: RAID and backups protect against disk failure, a UPS protects against the power failure that can cause it.

Stack 1: Home Assistant-centric smart home

The hub is Home Assistant Core with the Assist voice pipeline (Primary interface): wake-word detection, faster-whisper speech-to-text, the Assist conversation agent, and Piper text-to-speech, wired together over the local network via the open Wyoming protocol. The actual smart-home devices reach Home Assistant over open local protocols rather than a vendor cloud: Zigbee bulbs and sensors via a coordinator and Zigbee2MQTT (or the built-in ZHA integration), Matter-over-Thread devices via a Thread border router, and DIY ESP32/sensor nodes over MQTT — so the “ambient computer” has a nervous system, not just a voice. Assist's conversation agent calls out to a local model server — Ollama (Core architecture) — over its OpenAI-compatible HTTP API, serving Qwen3.6-27B (Natural language processing) as the default self-hostable, single-consumer-GPU model. That same Ollama instance holds the household's Onboard AI personality (Onboard AI personality) via a Modelfile SYSTEM directive, so the voice assistant, the persona, and the model are one running process, not three. Open WebUI layers on top as the shared browser front end for family members (also Primary interface), inheriting the same backend. For “hands doing things, not just talking,” CrewAI (Autonomous decision-making) orchestrates multi-step home-automation tasks against the same local model, wrapped in NeMo Guardrails (Known sentience risk / guardrails) as the runtime policy layer — since nothing in CrewAI's open core stops it from calling a destructive tool, guardrails are the operator-supplied safety net the row's own honest framing calls for. whisper.cpp + Argos Translate (Universal translator) hangs off the same Wyoming/local-network pattern for translating incoming speech before Assist ever sees it. The household runs TrueNAS Community Edition (Storage medium) on top of a Framework Desktop (Compute core hardware) as the box underneath all of this — HA's config, Open WebUI's chat/RAG storage, and Ollama's model weights all live on the same ZFS-backed volume, on the same physical machine — and Keycloak (Authorization method) sits in front of Open WebUI and any other self-hosted dashboard as a single WebAuthn/FIDO2 SSO login, rather than a separate password per app. Underneath all of it, every service here is a container brought up by Docker Compose (Orchestration & deployment), fronted by Caddy (Reverse proxy & TLS) so each dashboard is reached over real HTTPS rather than plain HTTP, with Pi-hole (DNS & network-level filtering) serving LAN names and blocking tracker domains, and a NUT-managed UPS (Power & UPS) standing by to shut the box down cleanly if the power drops. Netdata (Observability) gives per-second visibility into the host, while Uptime Kuma (Uptime) pings HA's own health endpoint and the Ollama server; when something breaks, the fallback is r/selfhosted and the Home Assistant Community Forum (Support channel).

Stack 2: Mobile / daily-driver privacy

The phone is a Fairphone 6 (Personal access device) running /e/OS (Personal communicator) — the same hardware/software pairing both rows independently converge on, since /e/OS is Murena's stock build for that device. Messaging and calls run over Signal, whose AGPLv3/GPLv3 client and protocol keep both the transport and the crypto auditable end to end — the Signal Protocol's double-ratchet key exchange is the actual “E2E-encrypted” mechanism the pricing table's claim gestures at. Credentials for everything else — Wi-Fi, self-hosted service logins, any passkeys the phone holds for third-party sites — live in Vaultwarden (Authorization method), an unofficial Rust reimplementation of the Bitwarden API that the phone's Bitwarden app talks to over the household's own server instead of Bitwarden's cloud; WebAuthn/FIDO2 hardware keys back up the vault unlock itself. Files sync to Nextcloud Hub's folder-level end-to-end encryption (Storage medium) — chosen over Proton Drive here specifically because Nextcloud's server is one you run, keeping the “only you hold the keys” property intact for the mobile-daily-driver use case rather than trusting Proton's (open-client, closed-server) infrastructure. Reaching any of this — Vaultwarden, Nextcloud, Open WebUI — from outside the house runs over Headscale (Secure device networking): the phone joins the same self-hosted WireGuard mesh as every other device in this project, so “self-hosted” doesn't quietly become “only reachable on the home Wi-Fi.” On that mesh every request first lands on the household's Caddy reverse proxy (Reverse proxy & TLS), so the phone always talks HTTPS to a valid certificate rather than dismissing a self-signed warning, and the phone's DNS points at Pi-hole (DNS & network-level filtering), so ad and tracker domains are sinkholed network-wide — on the home Wi-Fi and, via the tailnet's global nameserver, when the phone is out in the world too. A Framework Laptop (Ship terminal / console hardware) is the pairing/flashing workstation for the phone — ADB, /e/OS updates, and Vaultwarden's desktop client all run from it — and its own repairability (Self-repair capability) mirrors the phone's user-replaceable-battery ethos. When something needs fixing or explaining, the fallback is the same r/selfhosted/Matrix-room community (Support channel) as Stack 1.

Stack 3: Self-hosted AI & local-LLM

The model layer is Qwen3.6-27B (Natural language processing), a 27B-parameter dense multimodal model chosen specifically because it fits on one consumer GPU and its multimodal support covers the vision-agent use case below without a second model. It's served by Ollama (Core architecture) as a GGUF-quantized local endpoint speaking an OpenAI-compatible HTTP API — the same endpoint every other tool in this stack points at, so there is one model server, not several. That same Ollama instance carries the household's persona via a Modelfile SYSTEM directive (Onboard AI personality) — the identical mechanism Stack 1 uses, reused rather than reinvented, since it's the same Ollama install either way. The day-to-day human interface to it is oterm (Primary interface), a terminal client built specifically to talk to Ollama and other OpenAI-compatible local servers with no browser or web server required, matching this stack's no-GUI-overhead ethos better than Open WebUI's browser front end does. All of it — the model weights, oterm's local SQLite chat history, and Letta's memory database (below) — lives on TrueNAS Community Edition (Storage medium) running on the same Framework Desktop (Compute core hardware) as Stack 1, whose OpenZFS layer (Processing redundancy, below) actually protects it — one physical machine, shared by both stacks, not a separate box per use case. Every piece of that service set — Ollama, oterm, the agent stacks below, and Letta's Postgres — is brought up by Docker Compose or, for OpenHands' agent sandbox specifically, rootless Podman (Orchestration & deployment), on a box a NUT-managed UPS (Power & UPS) can shut down cleanly before a power cut corrupts a mid-write ZFS pool, with Netdata or a Prometheus + Grafana stack (Observability) watching GPU load and token throughput so “why is inference slow tonight?” has an answer. CrewAI and OpenHands (Autonomous decision-making) orchestrate agentic work — CrewAI for multi-step planning/delegation, OpenHands specifically for real terminal/file/browser tasks — both LLM-agnostic and both pointed at the local Ollama endpoint rather than a hosted API key. Because neither ships a safety reviewer, NeMo Guardrails wraps the runtime as a policy layer (blocking unsafe tool calls before they execute), while garak and PyRIT (Known sentience risk / adjacent-real-practice row) are run offline beforehand to probe the model/agent combination for jailbreaks and prompt-injection weaknesses the guardrails might miss. For an agent that also needs to see and drive a screen — the Touchscreen GUI row's actual computer-use use case (Touchscreen GUI) — Cua provides the sandboxed virtual-desktop layer, and it's Qwen3.6-27B's own multimodal capability (not a separate model) that gives Cua the vision it needs. Persona continuity across restarts is handled by Letta (Holographic crew): its Postgres/SQLite-backed core-memory blocks are literally what makes “the persona” survive a process restart, exactly matching the pricing table's “persists exactly as long as your backups do” framing — which is also why OpenZFS snapshots plus restic off-site backups (Processing redundancy) matter here specifically: they're what makes that survival real rather than aspirational. Though it sits outside this stack's home-network/local-LLM focus, this same Letta-backed persona can be given a body: see the standalone Holodeck / holo-environments pairing below for readers who want that persona actually populating a shared VR space.

Stack 4: Field hardware, network hardening & reliability

This stack covers the rows the first three don't reach: physical field equipment, home-network defense, and the operational discipline that keeps any of the above running. The field kit is built around M5Stack's modular ESP32 sensor “Units” (thermal, environmental) for the most literal “open hardware boards + thermal cams” match, or HackRF One + PortaPack Mayhem for RF-scanning priority (Handheld sensor device) — both flashed and developed from the same Framework laptop named in Stack 2 (Ship terminal / console hardware). For sky/space work, Stellarium renders real Hipparcos/Gaia star-survey data and ships a NavStars plugin of the 57 traditional celestial-navigation stars, with KStars's INDI-protocol backend added when the goal is actually pointing a telescope rather than just viewing a chart (Stellar cartography). Perimeter defense is OPNsense as the edge firewall/router, running Suricata in-line as IDS/IPS against known attack signatures, with CrowdSec tailing service logs (SSH, reverse proxies) and sharing its 10M+-IP community blocklist (Hostile takeover incidents) — three layers feeding a stream of inspectable log lines rather than a fictional boarding count. A fourth, cheaper layer sits in front of all of it: Pi-hole with Unbound behind it (DNS & network-level filtering) resolves the whole network's queries recursively — no public upstream resolver trusted — and sinkholes command-and-control and telemetry domains at the DNS layer, before a connection the packet-inspecting IDS would only catch mid-flight ever opens. Stack 2's Headscale mesh (Secure device networking) sits behind this same OPNsense edge — OPNsense's firewall rules still gate which sources can even reach the coordination server's port, and CrowdSec can watch Headscale's own application logs for abuse, but the WireGuard tunnel itself is encrypted, so Suricata's signature-based IDS/IPS cannot inspect traffic once it's inside that tunnel. Uptime Kuma watches service availability and Healthchecks.io watches whether scheduled backup jobs actually ran (Uptime) — watching, not owning, Stacks 1 and 3's own Storage medium and Processing redundancy picks (TrueNAS, OpenZFS, restic), since neither protects anyone who silently stopped running them, and Stack 4 doesn't introduce a separate storage or redundancy architecture of its own to replace them. The logs those three security layers emit don't review themselves: Wazuh (Observability) ingests OPNsense, Suricata, and CrowdSec output into one correlated, searchable SIEM — the “something has to actually read these” piece the Hostile-takeover row leaves to the operator — with Netdata or Prometheus + Grafana watching host and service metrics alongside it. A NUT-managed UPS (Power & UPS) signals every box on the network to shut down cleanly on power loss, the physical-world complement to Stacks 1/3's OpenZFS-and-restic discipline, and the whole assembly rides on Proxmox VE (Orchestration & deployment) as the hypervisor beneath the shared box — and the reverse proxy CrowdSec is already tailing is the Caddy/Traefik layer from the security group. When self-repair is needed, Framework's published schematics/EC firmware and iFixit's crowd-documented repair guides (Self-repair capability) cover, respectively, the report's own hardware picks and everything else a household owns. r/selfhosted, project-specific Discourse forums, and Matrix/Discord channels (Support channel) are the shared fallback across every stack in this report, not unique to this one.

Holodeck / holo-environments (Monado + WiVRn + Hubs) doesn't fit cleanly into any of the four stacks above as a home-network, mobile-privacy, or local-LLM component — it's a standalone XR/VR runtime stack in its own right. Rather than force it into one of the four named stacks with a stretched justification, it's presented here as an independent, self-contained pairing: Monado + WiVRn for the runtime, and Hubs for the shared-space content layer — cross-linked from Stack 3's Holographic crew entry (Letta) for readers who want an AI persona actually populating a shared VR space.

Compatibility matrix