Part 55: What's Still Missing — And Why
"A spec that does not enumerate its omissions is hiding something."
Why
We have built a lot in this series. Six pipeline stages, an event bus, a plugin system, eight Ops.Dsl sub-DSLs, three topologies, the dogfood loops, the secrets store, the observability stack, the backup framework, multi-host scheduling, cost tracking, GPU passthrough, and a clean teardown. By any reasonable measure, HomeLab v1 is a substantial tool.
But it does not do everything. There are concerns we deliberately deferred — not because they are unimportant, but because they would have ballooned the v1 scope past the point of usefulness. This part is the honest catalog: what is not in HomeLab v1, why it was deferred, what shape it would take when it lands, and which Ops.Dsl sub-DSL it would slot into.
The thesis of this part is: a spec that does not enumerate its omissions is hiding something. Honest deferral is part of the design.
1. ARM hosts
What's missing: HomeLab assumes x86_64 throughout. The Packer base image is alpine-virt-x86_64.iso. The container images we pull (gitlab/gitlab-ce, postgres:16-alpine, etc.) are mostly multi-arch but occasionally not. The Vagrant box names hard-code virtualbox (which does not run on ARM macOS).
Why deferred: ARM support means a parallel path everywhere — a parallel ISO URL, a parallel Packer source, a parallel Vagrant provider (Parallels supports ARM, VirtualBox does not, libvirt with KVM works on ARM Linux), a parallel image-pull check. None of the work is hard, but all of it is width rather than depth — the same patterns repeated for a second architecture.
What shape it would take: A Packer.Alpine.Arm64 companion contributor that mirrors the existing one but with aarch64 URLs and parallels/libvirt provider defaults. A pre-pull check that verifies every container image has a matching arm64 manifest. An architecture flag in the config (arch: x86_64 | arm64) that flows through every contributor.
Sub-DSL: Ops.Infrastructure — the architecture is part of the host spec.
2. Windows containers
What's missing: HomeLab runs Linux containers on Linux VMs. There is no support for Windows Server containers, Windows base images, or Windows-specific compose features.
Why deferred: Windows containers are a different ecosystem with different tooling (docker run --isolation=hyperv, different image registries, different base image lifecycles). They also require a Windows host to run them. The audience for HomeLab is overwhelmingly Linux/macOS developers; the value of Windows container support is low for the v1 scope.
What shape it would take: A Packer.Windows.Containers contributor that produces a Windows Server Core box, a WindowsContainerEngineContributor that wraps docker on Windows, and a compose serializer aware of Windows-specific service options.
Sub-DSL: Ops.Infrastructure (host kind) + Ops.Deployment (image format).
3. mTLS service mesh
What's missing: HomeLab uses Traefik as a reverse proxy with TLS termination at the edge. Internal traffic between services (e.g. GitLab → Postgres) is plaintext on the Docker network. There is no mutual TLS, no service identity, no Istio/Linkerd-style sidecars.
Why deferred: A real service mesh is a substantial new dependency (10+ MB sidecar per service, control plane, mTLS cert rotation, observability layer). For a homelab where the network is private and the threat model is "one developer", the value is small. For production-equivalent labs, the value is real.
What shape it would take: An IServiceMeshContributor plugin contract with implementations for linkerd (the lightweight option) and istio (the heavy option). The contributor injects sidecars into compose services, manages the service identity store, and rotates mTLS certs via the existing Tls library.
Sub-DSL: Ops.Networking + Ops.Security.
4. Federated multi-site labs
What's missing: A HomeLab instance is bound to one workstation (or multiple workstations via Part 46's SSH-based multi-host). There is no support for multi-site labs where, for example, you have one DevLab on your home network and another on your office network, and you want them to cooperate — sharing a Vagrant box registry, federating GitLab instances, replicating MinIO across sites.
Why deferred: Federation is a different problem from "one lab on N hosts". It involves cross-site discovery (mDNS won't work, you need DNS), cross-site authentication (the registry token has to be valid in both sites), cross-site replication (eventual consistency is hard), and conflict resolution. Each one is a research project.
What shape it would take: A IFederationProvider plugin with implementations for "DNS-based discovery + manual sync" (the easy mode) and "Tailscale-based mesh + automatic replication" (the harder mode). Plus a federation-aware variant of the box registry, the NuGet feed, and the secret store.
Sub-DSL: Ops.Networking (cross-site routing) + Ops.Configuration (cross-site secret distribution).
5. IaC drift detection against existing cloud accounts
What's missing: HomeLab is the source of truth for the resources it manages. It does not check whether the live state has drifted from the declared state — it assumes idempotence and re-applies. For users who run HomeLab against pre-existing cloud accounts (which is not the v1 use case but could be), drift detection would be valuable.
Why deferred: HomeLab targets local Vagrant VMs, not cloud accounts. Drift detection against cloud is a Terraform/Pulumi concern. The few users who want HomeLab to manage cloud resources can use Terraform alongside it.
What shape it would take: An IStateInspector plugin that compares the declared state with the live state and produces a drift report. Implementations for AWS, Azure, GCP, Hetzner. The drift report would feed into a homelab drift verb.
Sub-DSL: Ops.Deployment + a new Ops.Drift (which would itself be a candidate for a future sub-DSL).
6. HA GitLab on Kubernetes
What's missing: HomeLab supports HA GitLab via the Omnibus Reference Architecture on bare VMs (Part 39 — topology: ha). It does not support HA GitLab via the cloud-native Helm chart on Kubernetes.
Why deferred: HomeLab targets local Vagrant VMs, not a Kubernetes scheduler. The Helm-chart variant of GitLab requires a working Kubernetes cluster, which is itself a substantial substrate that HomeLab does not (yet) provision.
The future: When K8s.Dsl lands as a C# library, HomeLab gains a fourth topology — topology: ha-k8s — that provisions a small k3s or k0s cluster on Vagrant VMs and runs the GitLab Helm chart on it. The integration is one new contributor set; the core does not change. The IComposeFileContributor pattern is replaced by IKubernetesManifestContributor for the K8s-specific services, but the rest (TLS, DNS, secrets, observability, backups) works unchanged because those concerns are abstracted.
Sub-DSL: K8s.Dsl (future), feeding Ops.Infrastructure and Ops.Deployment.
7. Multi-tenant teams (per-user RBAC)
What's missing: HomeLab assumes a single user (or a small team that trusts each other). There is no per-user authentication on the CLI, no RBAC on the verbs, no audit log distinguishing one user from another.
Why deferred: A homelab is, by definition, a personal or small-team tool. Multi-tenant features (per-user tokens, RBAC, audit trails) are appropriate for shared platforms. The line between "homelab" and "platform" is where this feature would land.
What shape it would take: An IAuthnProvider plugin (OIDC, GitHub OAuth, local users), an IAuthzProvider plugin (RBAC rules), and a per-user audit log subscriber. Every CLI invocation would carry a user identity. Every event would be tagged with the user.
Sub-DSL: Ops.Security (RBAC) + a new Ops.Audit.
8. Encrypted backups at rest with key rotation
What's missing: The backup framework from Part 45 uses restic, which encrypts at rest with a single password. The password is in the secret store. There is no key rotation: rotating the password requires re-encrypting the entire backup set, which restic cannot do incrementally.
Why deferred: restic's encryption model is sufficient for the homelab threat. Key rotation matters more for long-term cold storage with regulatory requirements (which is not the homelab use case).
What shape it would take: An IBackupKeyRotation plugin that, on a schedule, generates a new password, re-encrypts each backup set against the new password (via restic copy), and updates the secret store. The current backup remains usable during the rotation; only after a successful copy does the old password get retired.
Sub-DSL: Ops.DataGovernance + Ops.Security.
9. Per-environment cost-aware scheduling
What's missing: The cost tracking from Part 47 reports cost after the fact. It does not schedule based on cost. A "cost-aware scheduler" would, for example, halt unused VMs after N hours of inactivity, or wake them on demand when traffic arrives.
Why deferred: Wake-on-demand requires either a request gateway that can boot VMs (substantial new component) or pre-booted VMs that consume cost anyway. The benefit is small for a homelab where VMs are usually all-on or all-off.
What shape it would take: A IIdleVmDetector subscriber that watches the event bus and proposes halts. A homelab vos auto-halt mode that the user opts into.
Sub-DSL: Ops.Cost + Ops.Capacity.
10. Web UI
What's missing: HomeLab is CLI-only. There is no web dashboard, no TUI, no GUI.
Why deferred: Part 02 made the case: CLI-first is testable-first. A web UI would be a second test surface, and we explicitly chose not to maintain two. The CLI is the contract.
The future: A web UI can be built on top of HomeLab without changing its architecture. The lib already has a clean API surface (the request/response handlers); a small ASP.NET Core wrapper could expose the same handlers as REST endpoints, and a SPA could call them. The UI consumes the lib; the lib does not change. The CLI continues to be the canonical interface.
Sub-DSL: none — this is presentation, not domain.
What this gives you that bash doesn't
A bash homelab does not have an "honest catalog of omissions". A bash homelab has whatever its author managed to write before getting bored. There is no spec, so there is nothing to be honest about.
A typed HomeLab with a published roadmap of what is not in v1 gives you, for the same surface area:
- A clear v1 scope — the user knows what they are getting
- A clear set of plugin opportunities — each missing item is a NuGet someone could ship
- A clear migration path — when
K8s.Dsllands, the integration point already exists - No silent gaps — nothing is in the codebase that pretends to do something it does not
The bargain pays back the first time a user reads this list and decides whether HomeLab is the right tool for their use case, with the actual scope in front of them.