For operators and builders
A home platform with clear boundaries.
Homenavi separates the control surface, home model, device protocol, workflows, and integrations so the system can grow without turning into a tangle.
Deployment choices
From small hardware to resilient clusters.
The Go microservices ship for ARM64 as well as x86, making a locally running core stack practical on capable Raspberry Pi-class homelab hardware. Validate storage and image support for your specific board before deployment.
Use Docker Compose for a local or small instance. Use the Helm chart when Kubernetes is the right fit; its HA profile scales selected stateless services, uses shared MQTT consumer groups, and supports CNPG PostgreSQL, VerneMQ broker clustering, and Valkey Sentinel.
Plan your deploymentLocal and small instances
Kubernetes deployment path
Configured replicas and resilient data services
MCP, scoped by design
Bring your own assistant.
Homenavi exposes a Streamable HTTP MCP endpoint with OAuth 2.1, PKCE, and dynamic client registration. Connect a compatible assistant without making that assistant part of your core deployment.
Scoped tools can read inventory and history, control devices and groups, create groups, and inspect or run workflows. Pairing, users, dashboards, events, and integrations are planned MCP surfaces that remain under development.
Read the MCP guideRealtime state path
From a physical device to every live surface.
A device change is translated once, published as an HDP event, and then used by each relevant surface. The live dashboard, history, and automation engine consume the same event instead of polling a vendor-specific device API.
Go microservices
A platform that can evolve without a monolithic knot.
Focused Go services own the parts of the platform they operate. HDP events carry state changes across service boundaries, so independently operated workloads do not need to share a runtime database.
- Focused ownership
- Identity, home inventory, device control, dashboards, automation, and history have clear responsibilities.
- Realtime contracts
- Mosquitto and HDP let services react to the same event while preserving their own data models; the HA profile uses VerneMQ.
- Practical operations
- Compose starts small; Helm can scale selected stateless services when Kubernetes is already the right fit.
Detailed service topology
The platform, mapped by responsibility and transport.
Client traffic enters the Core plane through Nginx and the API Gateway. This desktop map is still a simplified view, focused on how the core feature set works across the main service and transport boundaries.
On mobile, the diagram intentionally collapses to a plane-level view so the transport boundaries remain readable.
Service boundaries
Services own their data; consumers use contracts.
- Identity and access
- Auth Service issues RS256 sessions; API Gateway validates issuer, audience, token type, and signature before routing protected API traffic.
- Home inventory
- Entity Registry owns user-facing metadata: rooms, tags, groups, map placement, and HDP bindings. It does not replace realtime device state.
- Device state and commands
- Device Hub owns HDP devices, current state, capabilities, pairing, and persisted command lifecycles. Correlation IDs tie requests to acknowledged outcomes.
- Historical record
- History consumers ingest HDP state changes for charts and queries without making the dashboard poll the device runtime.
- Automation execution
- Automation resolves targets, subscribes to triggers, publishes commands, and persists workflow runs. Integration actions are resolved from the proxy's catalog.
- Integration lifecycle
- Integration Proxy maintains the installed integration runtime and exposes manifests, setup surfaces, widgets, and automation-step metadata to the platform.