Home Lab v2 — Roadmap📋

From self-hosted dev platform to production-grade internal PaaS

v1 proved that a single developer with the right abstractions can build and maintain a 57-project monorepo with typed CI/CD. v2 takes the platform from "it builds and packages" to "it deploys, monitors, and self-heals."

Current State (v1) — What Exists📋

✅ Foundational Patterns    Result<T>, Builder<T>
✅ BinaryWrapper            7 CLI wrappers (Podman, Docker Compose, Vagrant, Packer, GLab, Podman Compose, Docker⚠️)
✅ CI/CD Pipeline           GitLab CE → Build → Test → QualityGate → NuGet Package Registry
✅ Infrastructure           Vos (VM orchestration), Packer.Alpine (image building)
✅ Applications             QualityGate, DockAi, Doc2Pdf, Alpine.Version
✅ DSL Framework            M3 meta-metamodel, DDD DSL, Requirements DSL, Diem CMF
✅ PowerShell               40 modules (DevPoSh, Infra, Containers, Networking)
⚠️ Docker wrapper           In progress

Phase 1 — Finish the Foundation📋

Goal: Close the gaps in v1 before building upward.

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 dotnet test across 57 projects 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: Go beyond "it packages" → "it deploys to real 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 — use the existing Content/Admin DSL for the dashboard scaffolding

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
• Proof of concept — the CV site itself runs on the platform it describes

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📋

Q2 2026    Phase 1 — Finish Docker wrapper, pipeline hardening, test infra
Q3 2026    Phase 4.1 — CLI orchestrator (fed command)
Q3 2026    Phase 2.1–2.2 — Environments + deployment pipeline
Q4 2026    Phase 3.1–3.2 — Logging + metrics
Q1 2027    Phase 4.2 — Blazor dashboard
Q1 2027    Phase 5.3 — Self-host CV site
Q2 2027    Phase 5.1–5.2 — Event-driven pipeline + multi-repo federation

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