Home Lab v2 — Roadmap📋

From existing typed components to an integrated HomeLab, then a broader development platform

Anything-as-Code provides the direction: describe a development environment in C#, compose its typed modules, generate configuration and operate the resulting instance. The existing libraries, wrappers and infrastructure models provide the starting point. The complete reproducible HomeLab is the integration target within Diem.

This roadmap orders that integration and the later platform capabilities. Its phases describe proposed work, including example APIs and tools to evaluate. They do not assert that a complete v1 platform already builds, deploys or monitors itself. HomeLab overview.

Current State (v1) — What Exists📋

The foundation consists of components with their own implementation and validation scope. The earlier v1 label does not denote a completed integrated Lab.

See the source-linked building blocks for concrete implementations. The complete orchestrator and reproducible end-to-end workflow remain under development.

Phase 1 — Finish the Foundation📋

Goal: Select and verify the foundation needed for one integrated Lab instance before extending the platform.

1.1 Complete Docker BinaryWrapper📋

• Finish scraping Docker CLI --help across versions
• Parity with Podman wrapper (180+ commands target)
• Shared IContainerRuntime abstraction over Podman & Docker

1.2 Pipeline Hardening📋

• Dependency graph resolution — build only what changed (git diff → affected .csproj → topological sort)
• Parallel stage execution — independent projects build concurrently
• Artifact caching — NuGet restore cache, intermediate build outputs persisted across runs
• Pipeline-as-code in C# — replace .gitlab-ci.yml with typed C# pipeline definitions generated via Roslyn

1.3 Test Infrastructure📋

• Centralized test runner — orchestrate relevant dotnet test runs across the monorepo with unified reporting
• Mutation testing at scale — Stryker integration per project, aggregated mutation scores in QualityGate
• Integration test containers — spin up Podman containers for database/service dependencies in tests

Phase 2 — Deployment & Environments📋

Goal: Extend a verified instance lifecycle to deployment across explicit environments.

2.1 Environment Management📋

• Typed environment model — Dev / CI / QA / Staging / Prod as first-class C# types (not strings)
• Configuration-as-code — environment-specific settings generated at build time, no runtime appsettings.json swapping
• Secret management — integrate with GitLab CI variables or HashiCorp Vault, typed access via source generators

2.2 Deployment Pipeline📋

• Blue/Green deployments via Podman + Traefik
• Health checks — typed health check contracts per service, Traefik health routing
• Rollback automation — keep N previous container images, one-command rollback via GLab wrapper
• Deploy-on-merge — GitLab webhook → C# orchestrator → Podman pull + restart → Traefik reload

2.3 Multi-Node Support📋

• Vos cluster mode — orchestrate multiple VMs as a deployment target (not just single-node)
• Service placement — declare which services run on which nodes (typed topology)
• Shared storage — NFS or similar for persistent volumes across nodes

Phase 3 — Observability📋

Goal: Know what's happening at every layer.

3.1 Logging📋

• Structured logging pipeline — Serilog sinks → centralized log store (Seq or Loki)
• Correlation IDs — trace a request across pipeline stages, from git push to deployed container
• Log aggregation dashboard — Grafana or Blazor-based viewer (leverage DockAi's Lucene.Net experience)

3.2 Metrics & Monitoring📋

• Build metrics — duration per stage, failure rates, flaky test detection
• Runtime metrics — container resource usage (CPU, memory, network) via Podman stats wrapper
• QualityGate trends — track complexity, coverage, mutation scores over time per project
• Typed metric model — Metric<T> with labels, timestamps, and aggregation — not raw Prometheus strings

3.3 Alerting📋

• Threshold-based alerts — quality gate regression, build failure streak, container OOM
• Notification channels — email, webhook, or Claude.PoSh integration for AI-assisted triage

Phase 4 — Developer Experience📋

Goal: Make the platform pleasant to use daily.

4.1 CLI Orchestrator (fed command)📋

• Single entry point — fed build, fed test, fed deploy, fed status
• Built on BinaryWrapper — the orchestrator itself is a typed CLI
• Project-aware — knows the dependency graph, runs only what's needed
• Interactive mode — fed watch for continuous build/test on file changes

4.2 Dashboard📋

• Blazor Server dashboard — real-time view of:
  • Pipeline status per project (green/red/running)
  • QualityGate scores with sparkline trends
  • Container health across nodes
  • Recent deployments with rollback buttons
• Built on Diem CMF — work toward dashboard scaffolding through the evolving Content/Admin models

4.3 Documentation Generation📋

• Auto-generated API docs — Roslyn-based extraction of public API surfaces per library
• Changelog automation — conventional commits → typed changelog entries → markdown generation
• Architecture diagrams — Mermaid generation from actual dependency graph (not hand-drawn)

Phase 5 — Advanced Patterns📋

Goal: Push the type-safe philosophy further.

5.1 Event-Driven Pipeline📋

• Pipeline events as domain events — BuildStarted, TestFailed, PackagePublished using the DDD DSL
• Event store — persist pipeline events for replay, audit, and debugging
• Reactive orchestration — subscribe to events instead of polling for stage completion

5.2 Multi-Repo Federation📋

• Open the monorepo — publish selected libraries to public NuGet.org
• Versioning strategy — SemVer with automated breaking change detection via Roslyn API diff
• Dependency update bot — C# tool that checks for updates across federated repos

5.3 Self-Hosting the CV Site📋

• Containerize stephane-erard-cv — Podman container with Traefik routing
• CI/CD for the CV — push to GitLab → build → deploy on Home Lab infrastructure
• Validation target — demonstrate that the CV site can be built and served through the integrated platform

Priority Matrix📋

                    High Impact
                        │
     Phase 2.2          │         Phase 1.2
     (Deploy pipeline)  │         (Pipeline hardening)
                        │
                        │         Phase 4.1
                        │         (CLI orchestrator)
  Low Effort ───────────┼─────────── High Effort
                        │
     Phase 1.1          │         Phase 3.2
     (Docker wrapper)   │         (Metrics)
                        │
     Phase 5.3          │         Phase 5.1
     (Self-host CV)     │         (Event-driven)
                        │
                    Low Impact

Suggested Execution Order📋

The sequence follows dependencies, without new delivery dates:

1. Verify the selected building blocks — Phase 1. Choose tool and schema versions, exercise their configuration and command paths, and record the remaining gaps.
2. Compose one instance — Phase 4.1 and the Diem Lab model. Describe the instance in C#, prepare its images and VMs, select Docker contexts, and connect configuration to service lifecycle operations.
3. Exercise reproducibility. Generate and apply the instance configuration in a controlled environment, inspect its state, and repeat the lifecycle with diagnostic evidence.
4. Connect delivery — Phases 1.2 and 2.1–2.2. Integrate the forge and runners, builds, verification, package delivery and deployment; test failure and recovery behavior.
5. Add operational visibility — Phases 3 and 4.2–4.3. Connect logs, metrics, alerts, a dashboard and documentation to the working lifecycle and delivery path.
6. Validate a hosted workload — Phase 5.3. Use the CV site as a later end-to-end integration example.
7. Extend when justified — Phases 2.3 and 5.1–5.2. Evaluate multi-node operation, event-driven orchestration and repository federation against concrete needs.

Built with the conviction that if the compiler can enforce it, a human shouldn't have to remember it.