https://samplayskeys.github.io/Workspace/homelab/planning/adrs/index.htmlADRs capture decisions that are stable enough to reference later, with context and trade-offs. They supplement the narrative Decisions page. Document Status Per-environment Git branches via Komodo ResourceSync Accepted Baremetal Docker Host OS Selection Proposed Container Runtime Tradeoffs Proposed Skip local Docker registry, focus on git pipeline Accepted Docker vs Kubernetes for an Orchestration platform Inconclusive Tailnet-per-environment with declarative node sharing Rejected Workload isolation in a single tailnet — access pools ProposedHugoen-usWed, 26 Aug 2026 00:00:00 +0000https://samplayskeys.github.io/Workspace/homelab/planning/adrs/0006-tailnet-per-environment/index.htmlWed, 26 Aug 2026 00:00:00 +0000https://samplayskeys.github.io/Workspace/homelab/planning/adrs/0006-tailnet-per-environment/index.htmlStatus Rejected. The homelab will not split Prod/Test/Dev into separate tailnets. Environment separation stays as it is today: a single tailnet with tag-based grants. The investigation is retained in full because the rejection is the useful part — it documents why an appealing structural-isolation story doesn’t survive contact with an already-working Services deployment.https://samplayskeys.github.io/Workspace/homelab/planning/adrs/0007-workload-tailnet-separation/index.htmlWed, 26 Aug 2026 00:00:00 +0000https://samplayskeys.github.io/Workspace/homelab/planning/adrs/0007-workload-tailnet-separation/index.htmlStatus Proposed. Direction settled: workload/dev traffic stays in the current tailnet, separated by ACLs organized as access pools. The separate-tailnet option is deferred to a named trigger, not discarded. Extends ADR-0006, which rejected splitting Prod/Test/Dev into separate tailnets. That investigation’s useful finding was that the boundary axis was wrong, not the boundary idea. This ADR takes the next step of that finding: separation of workload from homelab is real, but the mechanism is pools within one boundary, with structural separation preserved as an off-ramp.https://samplayskeys.github.io/Workspace/homelab/planning/adrs/0005-docker-vs-k8s-orchestration/index.htmlTue, 25 Aug 2026 00:00:00 +0000https://samplayskeys.github.io/Workspace/homelab/planning/adrs/0005-docker-vs-k8s-orchestration/index.htmlContext The homelab currently standardizes on Docker (rootful, on Fedora Server baremetal hosts) managed through Komodo for GitOps. The prior narrative decision (“Komodo over Kubernetes (K3s + ArgoCD)” in planning/decisions.md) chose Docker-native Komodo over a K3s + ArgoCD stack on the grounds of complexity, risk tolerance, and concept alignment with existing familiarity with compose files.https://samplayskeys.github.io/Workspace/homelab/planning/adrs/0004-local-registry-skip/index.htmlWed, 19 Aug 2026 00:00:00 +0000https://samplayskeys.github.io/Workspace/homelab/planning/adrs/0004-local-registry-skip/index.htmlContext The homelab needs a strategy for managing container images between the local environment and production. Initial considerations included running a local container registry (Artifactory/Lightwell analog) or relying on Docker Hub with version pinning. The homelab already uses Komodo GitOps, GitHub Actions for rendering, and Ansible validation playbooks. Goals: Avoid infrastructure overhead — A local registry adds a running service, storage management, and maintenance burden for a feature (offline access) that isn’t actually required. Leverage existing pipeline investment — GitHub Actions, Ansible validation, and Komodo ResourceSync are already in place and can be extended to cover image governance. Security evaluation through PR process — Image scanning and review can happen in Git before anything gets deployed, rather than after images sit in a registry. Version pinning is already the pattern — Komodo configs and Git branches already provide effective version control; a registry would be redundant. Decision Skip running a local Docker registry as a stop-gap. Instead:https://samplayskeys.github.io/Workspace/homelab/planning/adrs/0002-baremetal-host-os/index.htmlTue, 09 Jun 2026 00:00:00 +0000https://samplayskeys.github.io/Workspace/homelab/planning/adrs/0002-baremetal-host-os/index.htmlContext The homelab needs a host OS for baremetal Docker nodes (LenovoMini 1 for Prod, LenovoMini 2 for Test, and the DevDocker VM on ProxMox). Requirements: RPM/DNF-based — user preference, already familiar with the ecosystem. Komodo GitOps compatibility — Periphery agent must be able to manage container workloads. Low-maintenance — set once and forget; not something to constantly troubleshoot. Easily automatable — host provisioning should be reproducible via Ansible, including Periphery agent setup. Options Considered Host OS Option Release Cadence Support Window Notes Fedora Server ~6mo ~13mo Latest kernel + tooling, frequent upgrades Rocky / Alma Linux Major (9.x) ~10yr RHEL-compatible, boring & stable Fedora CoreOS Auto-updating streams Per stream Immutable, no package management at runtime CentOS Stream Rolling between RHEL releases Continuous Between Fedora and RHEL Container Runtime Factor Docker Podman Komodo Periphery support First-class (native socket or API) Rough — community workarounds only (DOCKER_HOST to socket emulation) Rootless Available (opt-in via dockerd-rootless-setuptool.sh) Built-in, rootless by default Compose Docker Compose v2 podman-compose or podman play kube Research Findings Podman + Komodo Compatibility After investigation, Podman support in Komodo relies on workarounds:https://samplayskeys.github.io/Workspace/homelab/planning/adrs/0003-container-runtime-tradeoffs/index.htmlTue, 09 Jun 2026 00:00:00 +0000https://samplayskeys.github.io/Workspace/homelab/planning/adrs/0003-container-runtime-tradeoffs/index.htmlContext Selecting a container runtime for baremetal Docker hosts involves balancing security, operational convenience, and tooling compatibility. This ADR breaks down three approaches and the fundamental tension between central-socket management and daemonless isolation. The host OS decision is handled in ADR 0002: Baremetal Docker Host OS Selection. Runtime Options Docker (Rootful) The classic model: dockerd runs as root, exposes /var/run/docker.sock.https://samplayskeys.github.io/Workspace/homelab/planning/adrs/0001-komodo-resourcesync-branch-per-environment/index.htmlTue, 12 May 2026 00:00:00 +0000https://samplayskeys.github.io/Workspace/homelab/planning/adrs/0001-komodo-resourcesync-branch-per-environment/index.htmlContext The homelab uses Komodo with ResourceSync to declare servers, stacks, deployments, and related resources from Git (an “app-of-apps” style flow: Git remains the audit trail; Komodo reconciles). Goals: main shows the whole picture — dev/, test/, and prod/ (or equivalent komodo/{dev,test,prod}/) layouts exist together on main so reviews and long-lived docs match reality after merges. Per-environment steering — each environment’s sync can follow main or follow a named branch (for example to soak a stack change in Dev before it lands on main). Homelab-realistic ergonomics — accept some manual merge hygiene instead of building full release automation up front. An earlier sketch of this approach lived in wip/komodo-artifact-templates/scratch/branch_management_ideas.md.