Appearance
Ifeanyi Counsel — Self-Hosted Hinata Architecture
project: hinata-infrastructuretype: counselstatus: livingcreated: 2026-05-24 Architectural advice from Michael's cousin Ifeanyi, who runs a multi-monitor self-hosted setup with Samsung DeX as primary compute, daily Bitwarden discipline, and a documentation-first approach to home-lab infrastructure. He is on a two-month Claude Max sprint to set up his own gig and stress-tested the same setup arc Hinata is now entering.
This counsel is upstream of the entire Jimmy Neutron infrastructure backlog. Any open loop in this domain should be re-checked against the sequencing implications below before execution.
1. The three-tier documentation axis
Ifeanyi's exact framing — verbatim weight, this is the load-bearing recommendation of the call:
"You need to design your architecture for your system. You're going to have the architecture. You're going to have the infrastructure. You're going to have your services. Those are the three main things you need to really deep, deep down."
TierWhat it captures
ArchitectureThe "why" — system intent, doctrine, decisions, principle hierarchy InfrastructureThe "where" — hosts, VMs, networks, naming registers, hardware tier ServicesThe "what runs" — application stacks, dependencies, ports, configs
Current state vs counsel:
home-lab-doctrine.htmlcovers Architecturehome-lab-hardware.htmlcovers part of Infrastructure (procurement) but no naming register, no host inventory, no VM ledgerhome-lab-stacks.htmlcovers Services at the doctrine level only — no per-service install scripts, no port maps, no dependency graphs
Gap: Infrastructure and Services tiers exist as doctrine but not as operational artefacts. Hinata writes about home-lab; it does not yet operate a home-lab.
2. Install scripts are first-class artefacts
"You're going to be resetting, starting from scratch, so many VMs, so many times. And it's going to be running this using the same scripts. You don't want to keep Googling. Capture those, like neatly, the neater and easier you capture it." Translation: every system Hinata stands up (VPS, future Pi 5, future Tiny-Mini-Micro, every container) gets a versioned, runnable install script committed to the vault at the moment of standing it up — not retrofitted later, not screenshotted, not "I'll remember." If it's not a script, it doesn't exist.
Implication for #831042 (VPS sleep mode stack): the build itself must produce projects/hinata-infrastructure/install-scripts/nnamah-vps-sleep-stack.sh as the deliverable, not just a live system. Jimmy's brief for this loop must be updated.
3. Naming registers / schemas must be documented
"You might have a specific particular schema for naming your computers or your systems or your VMs. So it makes sense. Make sure it's clear that you documented somewhere. So three months down the line when you've moved on, your head is full on another passionate area, you don't want to be scratching your head — 'oh, what was this one again?'" Translation: create a naming register covering hostnames, VM names, container names, user accounts per host, and domain / subdomain conventions. Decide the schema before the next host is provisioned.
4. Bitwarden as foundation — a real contradiction with Itachi
"First thing I'd say before you even do all this is set up Bitwarden. Zero-trust layer. They don't keep anything. Even your password is hard for them to access. So if you forget your password, you're fucked — that's why I like it." This contradicts the live memory rule for Itachi-direct credential storage. Both positions are coherent:
Itachi-direct: single source of truth, file-grep-able, vault-backed-up, no external dependency
Bitwarden: encrypted at rest, zero-knowledge, multi-device, per-credential rotation tooling
Recommended framing for the decision: Itachi remains canonical for high-trust low-rotation secrets (root credentials, recovery keys, family/legal). Bitwarden adopted for high-volume operational secrets (per-VM users, per-service API keys, ephemeral lab credentials).
Michael decision 2026-05-24: Bitwarden adoption deferred until self-hosting equipment is delivered. Until then, Itachi-direct remains the sole credential store. Re-evaluate when the first home-lab host (Pi 5 / TMM) arrives. Open loop tracked at #840019.
Superseded 2026-06-10: Vaultwarden (self-hosted, Bitwarden-class) is live on CT103 (192.168.1.250); the "Bitwarden" naming is deprecated. Itachi remains credential source of truth. Loop 840019 resolved.
5. Per-VM unique credentials
"All the VMs that you create, the usernames you create for each VM, you might decide to use the same user and password for each VM. I wouldn't recommend that." Rule: never share credentials across VMs. This is partly why §4 matters — a shared-password model is tolerable with two hosts and unmanageable with twenty.
6. Claude Max sequencing — confirms current trajectory
"Me, I don't plan to pay Max forever. Two or three months back to Pro. Once I get everything set up. Ad hoc day-to-day, all I'll need to do is process my inbox. I won't need to continue the setup. Once it's all set up, that's it. 100%." Ifeanyi is on the same Max-for-setup, Pro-for-steady-state arc Hinata is on. The frame is correct: aggressive Max use is justified during the build, not as a permanent posture. After ~2 months of build-out the load is inbox-processing and ad-hoc — Pro tier.
7. Off-vault notes (low priority)
* **Samsung DeX** — phone-as-PC with multi-window, keyboard/mouse, three-monitor support. Off-topic for vault infrastructure but worth an inbox note if Michael ever considers the next-phone decision.
* **Kodi** — media-streaming alternative when self-hosted Jellyfin isn't yet up. Client-side of the Jellyfin choice.
8. Implications for current open loops
LoopImpactRecommended action
#831042 VPS sleep mode stackBuild must emit a committed install script as primary deliverable, not just a running systemUpdate brief: deliverable = install-scripts/nnamah-vps-sleep-stack.sh#840003 CSV parser toolNo impactProceed as planned #840004 docx extractorNo impactProceed as planned NEW Naming registerRequired before next host provisionNew loop, owner Jimmy Neutron NEW Install-script disciplineRequired before #831042 buildsNew loop, owner Jimmy Neutron NEW Bitwarden vs Itachi-direct decisionResolved 2026-06-10 — Vaultwarden live on CT103 (192.168.1.250); Itachi remains source of truth
10. Second-pass counsel (recording 1)
Parsed from Sandpit/hinata/transcripts/Ifeanyi Architecture Design.md (553-line Whisper transcript, 2026-05-24). Recording 1 ("most important") skews towards physical architecture rather than the documentation/security/credential axes that dominated recording 2.
10.1 Three-node physical topology
NodeRoleHardware biasAlways-on?
Front doorFirewall + reverse proxy + ZT tunnelRaspberry Pi (or small NUC) — low-power, low-RAM workloadYes NASCold storage, backups, cloud-replacement filesMin 2 HDDs in mirror; SSD optional as cacheYes (except maintenance) BrainVM host running services/agents/dev sandboxesNUC/mini-PC class with ≥16 GB RAM, ≥6 coresToggleable
Order of acquisition: Pi/front-door first (cheapest, validates network gateway thinking), then brain (so VMs can run), NAS last (storage scales when there's actually data to store).
10.2 Storage economics — HDD-first, NVMe-as-cache
* **NVMe is NEVER main storage.** It's a cache layer, an OS disk, or a VM-disk drive — not where you put media/photos/backups.
* **HDD + small SSD cache ≈ pure SSD performance at ~10× the capacity per pound.**
* **Bottleneck reality for 1–4 users:** network bandwidth and CPU (transcoding) hit first, not disk.
10.3 Redundancy posture — mirror minimum
* **Minimum:** 2 HDDs in mirror. Usable capacity = single-drive capacity (e.g. 2× 4 TB → 4 TB usable).
* **Disaster recovery:** second NAS at family house = point-to-point off-site backup.
* **Capacity reference:** Ifeanyi runs 70 TB total / ~40 TB usable across 7 years; doesn't justify Michael starting beyond 2× 4 TB.
10.4 Cloudflare as default fronting layer
Ifeanyi was emphatic: if you have a public IP and you're not fronting it with Cloudflare, fix that now. Anonymises the origin IP, WAF basics, DNS, tunnel, and anti-bot are all free. Already partly satisfied by michael-engineer.dev.
10.5 Zero Trust tunnel vs public-IP exposure
Two access models: ZT tunnel (recommended — only devices with VPN credentials reach the network) vs public IP exposure (bot-scanned within hours). Every host post-front-door should be tunnel-reachable only. Public IP only for michael-engineer.dev and equivalent low-trust public surfaces.
10.6 AI as connective tissue, not soul
* AI is not automation. Web-hooks + workers + sensor pipelines = automation.
* AI's actual leverage is pattern inference across the data the automation collects.
* Don't gate the rest of the stack on "AI is ready." Build the automation surface first; AI plugs into it later.
10.7 Step-wise hardware upgrade philosophy
"You'll never not use what you have. When you upgrade the brain, the old brain becomes the IoT server or file server. Nothing ever gets thrown out — it just gets demoted."
* Don't over-buy now to "future-proof" — features you don't use today rot.
* Buy the feature-richest gear at the lowest viable price _today's_ workload justifies.
* Plan node count to grow: 3-node start → 4-node when brain is upgraded → repurpose, not replace.
10.8 Media-server / Spotify-clone — legal posture
* Personal/family scale: government tolerant, copyright not enforced in practice.
* Moment it opens to "classmates / friend group / public": mass-distribution territory.
* Mitigation if scaling beyond family: ZT-tunnel-only access, no public surfaces, no monetisation.
10.9 Updated open loops after recording 1
LoopStatus
Naming registerUnchanged — still required before next host provision Install-script disciplineUnchanged — still required before #831042 Bitwarden vs Itachi-directResolved 2026-06-10 — Vaultwarden live on CT103; Itachi remains source of truth NEW 3-node procurement orderOpen loop — Pi first, then brain, then NAS. Owner Michael. NEW HDD-first / NVMe-as-cache ruleDecided — record in hardware-procurement doc when one exists NEW Cloudflare fronting defaultDecided — already partial; extend to every future public surface NEW ZT-only access for non-public hostsDecided — operating rule for new home-lab nodes NEW Step-wise upgrade / nothing-thrown-out principleDecided — pin in procurement doc