Aros

Today, operating a homelab estate means living across a dozen browser tabs — Proxmox for VMs, Portainer for containers, Unifi for networking, Vault for secrets, Grafana for metrics, PBS for backups, Traefik for routing, iDRAC for hardware, Cloudflare for DNS. Each tool is excellent at its job. None of them talk to each other. The operator is the integration layer, carrying context between tabs in their head.

Aros replaces that model. A single, tenant-aware control surface that absorbs every routine operation from every underlying tool — with better UX, a full audit trail, and the ability to hand routine work to AI agents under strict oversight.

The platform doesn’t replace the underlying tools; it wraps them behind adapter interfaces so the operator rarely needs to touch the native UIs for routine work. Proxmox, Unifi, iDRAC, Vault, PBS, Traefik, Cloudflare, ELK — they all become implementations of Aros capabilities, swappable without touching application code.

The development pipeline is the first piece of Aros infrastructure that had to work before any application code could land. It was designed to be boring and repeatable — the same flow whether deploying a health-check skeleton or a full domain module.

The flow: a git push to Forgejo triggers Woodpecker CI. The pipeline builds a multi-stage Docker image, pushes it to Forgejo’s built-in OCI registry, and SSH-deploys to the dev cluster (aros-dev-1/2/3 on pve2). Promotion to test and UAT is manual — a TARGET-gated trigger in the Woodpecker UI. Test VMs span pve1/pve2/pve3 for real HA validation. UAT mirrors test topology.

Every VM in the pipeline was provisioned via Terraform, hardened via Ansible, backed up via PBS, and has its credentials stored in Vault. No hand-built infrastructure anywhere in the chain.

The architecture mandates three-node minimum for every tier. The three PVE hosts (pve1, pve2, pve3) form a quorum-capable cluster. App-tier VMs are distributed one-per-host in test and UAT. The data tier runs a 3-node PostgreSQL cluster managed by Patroni with etcd for consensus.

The HA proof point: during Sprint 1 closeout, the Patroni leader was deliberately killed while a curl loop probed the application’s health endpoint every 2 seconds. The leader flipped from .231 to .233 inside one probe interval. Every probe returned 200. Zero “(no response)” lines in the captured window. libpq’s target_session_attrs=read-write found the new leader on the next reconnect without the application doing anything.

This same pattern extends forward. Redis will run Sentinel across three nodes. MinIO will run erasure-coded across three nodes. Traefik will run one instance per node. When the network tier gets its VLAN segmentation and dual-switch MLAG, even the switching fabric will have no single point of failure.

The adapter pattern is the architectural guarantee that Aros isn’t locked to any vendor or tool. Every external dependency sits behind a defined Python ABC (abstract base class) with capability declarations, health checks, and per-tenant configuration. The platform consumes adapters; it never consumes tools directly.

Concrete adapters in the v1 scope: Proxmox and UNRAID for Compute, ZFS and UNRAID and LVM for Storage, Unifi and Traefik and Cloudflare for Network, Authentik for Identity, Vault for Secrets, PBS and restic for Backup, ELK for Logs, Prometheus+Thanos for Metrics, CrowdSec for IDS, Trivy+Grype for Scanning, Falco for Runtime Security, Headscale for Mesh Networking.

Each adapter can be replaced independently. Each adapter declares its own sandboxing requirements. The same adapter interface that wraps Proxmox today could wrap a cloud hypervisor tomorrow — or a second homelab site across a Headscale mesh.

The agentic model is tiered. Routine, low-risk operations can self-heal automatically — a container that crashes gets restarted, a failed backup gets retried, a certificate nearing expiry gets renewed. Higher-risk operations get proposed by an AI agent and presented to the operator for one-click approval. The operator sets the policy boundary per tenant, per pillar.

AI agents are first-class identities with their own scope, audit trail, and cost budget. Every action an agent takes is logged with the same fidelity as an operator action. The platform tracks token usage per agent and alerts on cost drift. Agents can be local (Ollama) or cloud (Anthropic, OpenAI), with a complexity-scored routing engine that sends simple tasks locally and reserves cloud models for harder reasoning.

The end state: the operator gets a morning briefing from Aros showing what happened overnight, what was auto-resolved, what needs attention, and what the AI is proposing. The operator reviews, approves, rejects, or adjusts — then goes about their day knowing the platform is watching.

1. Year 1

   Single-operator, single-site, full-stack visibility

   All ten pillars at Tier 1 or 2 parity. One browser tab for the entire estate. Aros replaces the vm-provisioner, Portainer, Uptime Kuma, and most Grafana usage. Authentik SSO across every managed service. WYSIWYG dashboard builder for custom views. Full audit trail for every action. AI proposes routine remediations via the change pipeline.
2. Year 2

   Multi-tenant, multi-site, whitelabel-ready

   First non-system tenant onboarded. Whitelabel branding live. Buddy backup site federated via Headscale mesh. Edge nodes operating autonomously when central is unreachable. API consumed by external integrations (CLI, N8N, AI agents). Multi-tenant isolation verified. Cost tracking per tenant.
3. Year 3

   MSP-capable, AI-native, self-managing

   Aros manages itself. AI agent proposes, tests, and promotes a production fix end-to-end. 10+ self-healing patterns in production with verified positive outcomes. MSP-ready: customer-facing surfaces, per-tenant billing data, SLA tracking, whitelabel deployment. Multi-site federation with cloud drift backup. The operator's only browser tab during 95% of operational work.

Open Aros in a single browser tab. The dashboard shows the entire estate: 4 bare metal servers, 30+ VMs, 100+ containers, network topology, storage pools, backup health, security posture, active incidents. Everything green, or the things that aren’t green are already being handled by the self-healing layer with an audit trail of what was done.

A morning briefing notification lists overnight events: two containers auto-restarted after OOM, a certificate was renewed 14 days before expiry, a Proxmox node ran a scheduled scrub and passed, a backup verification drill succeeded, an AI agent proposed a resource rebalance across the cluster (pending approval).

Click into Infrastructure and browse the estate tree: bare metal → hypervisor → VM → containers. Click a VM and see everything about it — CPU, memory, storage, network, backups, security scan results, dependencies, owner, runbooks, recent changes, active alerts — all from one view without switching tools.

Deploy a new service from a template: one click creates 3 VMs across 3 PVE hosts, installs the application stack via Ansible, configures Traefik routes, creates DNS records in Cloudflare, sets up monitoring, schedules backups, registers the service in the catalog, and posts to the changelog. The template parametrises everything the operator wants configurable and hardcodes everything they don’t.

When something breaks, the alert promotes to an incident with a timeline. The AI agent suggests a remediation based on similar past incidents. The operator reads the proposal, clicks approve, and the platform executes the fix through the same change pipeline that every other operation uses. The postmortem template is pre-filled with timeline, root cause candidates, and affected resources.

A tenant — a friend with a buddy-backup arrangement, or a future MSP client — sees their own branded view of the platform. Their own resources, their own users, their own SLOs, their own status page. They can’t see the operator’s resources or other tenants. They can request changes that route through an approval flow.

That’s the destination. Every sprint between now and then adds one more structural layer that makes the next layer possible.

1. Sprints 0–2

   Foundation: pipeline, HA Postgres, app skeleton, multi-tenancy + audit

   ~30 VMs via Terraform, hardened by Ansible, backed by PBS, secrets in Vault. FastAPI modular monolith on a 3-node Patroni cluster (2s failover, zero dropped requests). tenant_id + row-level security from day one. A hash-chained, tamper-evident audit log from the first migration.
2. Sprints 3–4

   Tasks, approvals, platform health — then discovery + monitoring

   Dramatiq task framework, a policy + approval pipeline, tier-by-tier platform health. Then the adapter framework lands and Aros starts absorbing tools: Proxmox, UniFi, Traefik, Redfish, Docker, domains — discovering the estate into a containment hierarchy with cross-adapter correlation.
3. The inflection

   Sprints → runs

   A failure analysis found the process drift (ceremony free to produce, expensive to read; statuses marking themselves; operator enthusiasm absent from the risk register). Sprint ceremony died; the RUN — one operator-authored prompt, ratifications up front, ship-gated priorities each with a demo — became the unit of planning. Six working agreements ratified.
4. The runs

   The platform speaks, then deploys

   Health truth with reasons, a findings attention queue, platform/estate scope — then the ADR-0025 action framework live: Aros clones, configures, boots, and audit-chains its own VMs through a policy gate, human approval, and a single correlation chain from request to discovery.
5. This stretch

   Correlation, consolidation, the Approvals pipeline

   End-to-end network visibility for any node; the cross-adapter thread surfaced everywhere and persisted at discovery; Network + UniFi merged into one section; the top-level menu de-sprawled; entity-detail tabs consolidated with zero information loss; a follow-the-chain Approvals pipeline; a genuine tenant-creation crash and six type-suppressions cleared.
6. Next

   Correlation backbone + connector registry + edge HA

   ADR-0032, scoped and awaiting ratification: one normalized network-address table (consistent IPs, click-to-trace, route internals, hardware de-dup, and the resolver for east-west flows); a connector registry generalising the BMC pattern so any adapter is GUI-registered and Vault-backed — the unlock for multi-estate; and removing the edge single-point-of-failure, cheapest move first.
7. The horizon

   Pillar build-out + multi-tenant, multi-site

   Storage, Backup, Security adapters; service catalog; incident management; a GUI-driven install that takes an operator from bare metal to a running, tenanted Aros; first non-system tenant; sites federated across a mesh. The ten-pillar end state.

The sprint cadence is deliberately slow at the foundation layers. Sprint 0 built infrastructure. Sprint 1 built the application skeleton. Sprint 1.5 hardened the pipeline and secrets model. None of this is user-facing. None of it ships a feature. All of it means that when the first real domain module lands, it lands on a platform that’s reproducible, version-controlled, HA-tested, and pipeline-validated — not on a pile of shortcuts that need unwinding at scale.

The discipline extends to every architectural decision. Multi-tenancy is designed in at the schema level from day one, even with a single operator. Adapter interfaces are defined before the first adapter is written. The audit log is append-only and tamper-evident from the first migration. These choices cost time now and save rewrites later.

This is the deliberate opposite of “ship fast and fix it later.” When Aros reaches its first real user-facing feature, the runway beneath it will be three sprints long and battle-tested.