--- name: project_varaverk description: Varaverk — self-healing mutually-redundant two-server Unraid home media ecosystem metadata: node_type: memory type: project originSessionId: ffec43cd-13e3-4911-878f-40459f7d16a9 --- **Varaverk** is a complete self-healing, self-maintaining, mutually-redundant two-server home server ecosystem. One codebase runs on both servers. No primary/standby — both servers run independently and cover each other when one goes down. ## The Two Servers **HOST1 — unRAID-Gmer4Lfe** - Hardware: Threadripper 1950X, 128GB RAM, ZFS cache pools - Location: Primary site - Domain: Gmer4Lfe.com - Runs: Arrs (Movies, TV, Music), Auth stack (source of truth), Emby (primary) **HOST2 — unRAID-Jayred365** - Hardware: Intel i5 10th gen, 64GB RAM - Location: Remote — different building, different power utility - Domain: Gmer4Lfe.us ## Architecture - Platform adapter layer (Plugin/unraid/adapter.sh) isolates OS-specific calls — scripts never branch on OS - Self-healing, not enterprise HA — goal is minimal media stack disruption - Tailscale for mesh networking between hosts ## Session State — 2026-06-13 **What was done this session:** - New Claude Code install after a reinstall. Old data was at /boot/config/claude and /boot/config/claude-bin. - Memory files restored from old install into current install. - claude_startup.sh run manually — created claude-data and claude-bin dirs under /boot/config/plugins/varaverk/, migrated all data, symlinks confirmed working. - Verified Varaverk is fully running from /boot — nothing in appdata. varaverk.cfg SCRIPTS_DIR, DATA_DIR, STATE_DIR, all point to /boot/config/plugins/varaverk. - No code changes made — session was setup/verification only. **Stale note in .plg:** The ###2026.05.31 CHANGES entry says "Scripts are git-cloned to appdata on first install" — this is wrong, the actual code clones to /boot/config/plugins/varaverk. Worth fixing on next package build. **Flash wear note:** /boot is on USB flash (flash/boot). HOST1_STORAGE_MODE_INTERNAL=true was designed for NVMe/SSD boot. Git writes, logs, and claude data all land on flash — acceptable for now but worth migrating boot to NVMe eventually. **Plugin install flow:** Plugin installs to appdata first, then during the setup wizard the user can select "normal" or set `internal_boot=true` to pin it to /boot. This is why the .plg note about appdata isn't wrong per se — it's the staging location before the wizard runs. ## Active To-Dos (from Notes_To-Do.md) - Fix fallback strike list timing: ~30s first, ~90s for 3-strike trigger — needs testing - Verify silent toggle switches back on good notifications - Rename folder Unraid_Scripts → Varaverk everywhere, update git script, all traces/scripts - Delete old /boot/config/claude and /boot/config/claude-bin dirs (migrated, no longer needed) ## Future Design Ideas - Shared auth stack for partner hosts to start shared services - When owner offboards with 2+ servers: auto-promote strongest server (by compute + bandwidth) - Overall setup script that pulls vars automatically (docker names, etc.) - App layer as king: no more direct git — app opens/edits settings, partnership deploys to servers, pushes correct host.conf - Web UI: on initial launch with no state file, open master.conf; lock orchs until setup complete - First-launch guide: owner sets up master.conf → host1.conf → Tailscale shares → onboard → host2/3 install and see state file, default to mirror mode **Why:** User is building this as a personal project on Unraid. Design philosophy favors simplicity and independence over enterprise tooling. **How to apply:** Understand the two-server mesh model when suggesting architecture. The app layer / web UI direction is the current strategic focus — moving away from raw git/scripts toward a proper application.