Why build a homelab?

Most home technology starts simple and slowly becomes hard to reason about.

A smart home hub here. A media server there. A dashboard. A few automations. A local app you built for yourself. A remote access setup. Some secrets. Some DNS. Some reverse proxies. A handful of things that are important enough to rely on, but not always documented enough to rebuild confidently.

homelab-zero exists to answer a simple question:

Can a home server become understandable infrastructure instead of a one-off collection of machines and services?

The goal is not to build a giant enterprise platform at home. The goal is to make a personal home environment that is private by default, understandable, reproducible, operator-controlled, and useful today.

The idea behind homelab-zero

homelab-zero is a NixOS-powered home platform for running the things I want close to me: smart home services, private media tools, dashboards, local utilities, self-hosted experiments, safe public access for selected apps, and controlled deployment and rollback workflows.

It is built around a simple philosophy: the home should have infrastructure that feels like it belongs to the person living there.

That does not mean pretending the cloud does not exist. Public DNS, certificates, a VPS edge, and services like Cloudflare can still be useful. The difference is that those pieces are used intentionally, while the core system remains something I can inspect, rebuild, and control.

What is working now

homelab-zero control plane dashboard showing status cards, system metadata, and deploy state
The redesigned homelab control plane: status, service publication, secrets, deploys, and operator actions in one place.
mobile view of the homelab-zero control plane dashboard
The same control surface on a small screen.

Smart home foundation

The homelab runs the base services needed for local smart home control, including Home Assistant, MQTT, dashboards, and local network plumbing. The goal is to keep smart home control close to the home, with automations and integrations that do not require every interaction to depend on a remote vendor dashboard.

Private media and local services

The system supports private media workflows and local service hosting. Media-related services, dashboards, and utility apps can be exposed only on the local network or over VPN, depending on what they are meant to do.

The access model is intentionally explicit. A service can be LAN-only, LAN plus VPN, or public. That makes it easier to reason about what is private and what is intentionally exposed.

Self-hosted apps

The homelab can host small personal apps and experiments behind the same service publishing layer. Recently, the Broccoli Labs static site was deployed this way: www.brolabs.ai serves the site, brolabs.ai redirects to www.brolabs.ai, certificates and routing are handled by the homelab platform, and the site source is pinned to a specific Git commit for reproducibility.

This is a good example of the direction: small apps should be easy to publish without turning the whole system into a manual snowflake.

Public and private access

The homelab uses a split access pattern: private services stay on the LAN or VPN, selected public services are routed through a public edge, HTTPS certificates are managed automatically, and DNS/service publication is derived from declared service metadata where possible.

This is not marketed as “no cloud dependency.” A more accurate statement is: local-first where practical, public when intentional.

control plane services page listing published endpoints grouped by core services and apps
The services view shows what is published, how it is exposed, and whether it is LAN, VPN, or public.

Deployment and rollback

A major focus is safe operation. The system uses a candidate deployment flow instead of treating every change as an immediate permanent switch. A deploy can be built, activated, health-checked, confirmed, or rolled back.

That matters because home infrastructure is still infrastructure. If a router, DNS, reverse proxy, or core service breaks, the fix should be structured — not a late-night guessing session.

control plane deployd page showing deploy request, confirmation, rollback, and status controls
The deployd view keeps rollout actions explicit: request, inspect, confirm, or roll back.

Secrets stay human-controlled

Secrets are treated differently from normal configuration. The repository can describe that a service needs a credential, what it is for, and whether it has been fulfilled. It does not need to store the secret value itself.

The control plane keeps this boundary visible. Secret values are write-only: an operator can paste a value to fulfill a request, but the dashboard never displays stored contents back. That means the system can track readiness without turning the UI into a place where sensitive material leaks.

This is also an important AI boundary. AI-assisted tools can help draft service definitions, explain why a secret is needed, or point out which requests are still pending. They should not receive plaintext secrets, invent credentials, or silently publish a service that depends on a human-controlled key. The human remains the authority for creating, approving, and rotating secrets.

control plane secrets page showing write-only secret fulfillment and secret inventory statuses
The secrets view shows pending and present requests without exposing secret values. Fulfillment is a deliberate operator action.

Status snapshot

  • Smart home base: working and actively used
  • Local dashboards and utilities: working
  • Private media/service hosting: working and evolving
  • Public HTTPS service publishing: working for selected services
  • Broccoli Labs website deployment: live at www.brolabs.ai
  • Multi-domain support: now in place for mundus.in and brolabs.ai
  • Deployment safety: candidate deploy and confirmation workflow is working
  • Secret handling: metadata-driven; plaintext secrets stay out of the repo
  • AI-assisted operations: experimental and bounded, not a replacement for operator control

What is next

Better app onboarding

Adding a new app should become more repeatable: define what the app is, where it should be reachable, what state or secrets it needs, prove the generated config with tests, and deploy through the candidate workflow.

The goal is not one-click magic. The goal is fewer hidden steps and fewer fragile manual edits.

More complete multi-domain support

The platform now supports more than one domain, which makes it possible to separate personal infrastructure from public project sites. For example, mundus.in can remain the homelab/platform domain while brolabs.ai serves public project pages and experiments.

Safer operator tools

There is ongoing work around operator-facing tools: dashboards, status summaries, logs, and controlled actions. The important constraint is that tools should expose safe, bounded operations instead of becoming unrestricted remote shells.

AI-assisted operations, carefully scoped

AI-assisted workflows are part of the direction, but they are being treated carefully. The goal is not “an AI runs the house.” The goal is more practical: help draft configuration, explain service state, propose safe changes, generate tests, summarize deploy status, and interact through bounded control-plane interfaces.

Human/operator approval remains central, especially for deployment, secrets, public exposure, and rollback decisions.

Why this matters

A homelab can easily become a hobby that only works because one person remembers how it works.

homelab-zero is trying to become something better: a home platform where the important decisions are written down, the system can be rebuilt, and changes are made through a workflow that respects the fact that this infrastructure actually matters.

It is still evolving. Some pieces are polished; others are prototypes. But the direction is clear: private, understandable, reproducible, operator-controlled home infrastructure.