Interactive Nabla architecture
AI platform, homelab services, functional dependencies, and observable integrations.
The page starts with foundations and components with the largest blast radius before leaf applications. The detailed view then keeps the complete relationship graph declared in nabla-compose.
Operations and troubleshooting
One read-only snapshot of FastAPI runtime, dependency health, TrueNAS, pfSense and Cloudflare evidence. Start here to identify the failing layer before changing configuration.
Impact and root-cause inspector
Select a service to separate local health, observed blocked_by causes, and structural blast radius across required topology relations.
Architecture health and filters
Services stay first; filters use operator presentation roles while the complete topology remains the basis for dependency criticality and blast-radius calculations.
70 declared services shown of 70
1 · Services & experimentsPrimary homelab outcomes: track service availability, errors, latency and traffic.RED52 components52 need attention
AnythingLLM - albandrieu
UnknownPrivate LLM workspace and RAG
LocalAI (GPU)
UnknownLocal AI models (GPU instance)
Ollama (GPU)
UnknownLarge language models (GPU instance)
Open SpeedTest
UnknownOpen SpeedTest - Network speed testing
PortTracker - albandrieu
UnknownPort tracking service
Scrutiny Collector - albandrieu
UnknownHard drive health monitoring
2 · Critical core platformFoundations whose failure can remove a whole layer: track availability, quorum/readiness, pressure, capacity and errors.USE2 components2 need attention
4 · Shared platform & dataShared backends: track availability, latency, saturation and capacity without conflating impact with required dependency.RED + USE11 components11 need attention
PostgreSQL
UnknownDatabase server (TCP — use a Postgres client, not a normal web browser tab)
5 · Observability & supportObservability and auxiliary tools: important for diagnosis without automatically marking monitored services unavailable.SUPPORT5 components5 need attention
Show critical dependency hierarchy
Critical dependency hierarchy
Foundational infrastructure and shared state are shown before applications, using declared required dependencies and their transitive blast radius.
1 · Infrastructure foundations
Inspect dependency impact
Inspect dependency impact
Inspect dependency impact
2 · Shared data and state
Inspect dependency impact
Inspect dependency impact
Inspect dependency impact
Inspect dependency impact
Inspect dependency impact
Inspect dependency impact
3 · Shared platform services
Inspect dependency impact
Inspect dependency impact
Inspect dependency impact
Inspect dependency impact
Inspect dependency impact
Inspect dependency impact
4 · Applications and consumers
Inspect dependency impact
Inspect dependency impact
Inspect dependency impact
Inspect dependency impact
Inspect dependency impact
Inspect dependency impact
5 · Support and low-impact components
Criticality is derived from blocking required relations (dependsOn, consumesApi, routesTo, storesIn, authenticatesVia and structural partOf). Databases, caches and storage kinds are treated as shared state when they have required dependents. Observability and exposure links do not artificially increase startup criticality.
Compact hierarchy
Mobile view of criticality tiers, effective health, and direct relations. The complete interactive graph remains available below.
Infrastructure foundations2 servicesunknown
Shared data and state4 servicesunknown
- Dockerrequired · hostedBy
- Dockerrequired · hostedBy
- Dockerrequired · hostedBy
Shared platform services7 servicesunknown
- Dockerrequired · hostedBy
- InfluxDBrequired · storesIn
- Dockerrequired · hostedBy
- Dockerrequired · hostedBy
- Dockerrequired · hostedBy
- Dockerrequired · hostedBy
- Ollamarequired · routesTo
Applications and consumers4 servicesunknown
- Dockerrequired · hostedBy
- Mimirrequired · storesIn
- Dockerrequired · hostedBy
- PostgreSQLrequired · dependsOn
- Dockerrequired · hostedBy
- MongoDBrequired · dependsOn
- OpenSearch Securityrequired · storesIn
- ClickHouserequired · storesIn
- Dockerrequired · hostedBy
Interactive service topology
Use the graph search and controls to switch between the AI platform, services, critical path, full catalog, and optional relations. On mobile, the compact hierarchy above provides a more direct view before the complete graph.
Compact mobile view: expand a layer, then a service, to inspect its visible relations.
Interfaces & agentsHuman-facing clients and coding/agent entry points.5 nodes · main flow ↓
- Codexinterfaces · coding-agent
1 relation
- required · API/data flow · model requestsLiteLLM
- Cursorinterfaces · coding-agent
1 relation
- required · API/data flow · model requestsLiteLLM
- Open WebUIinterfaces · interfaceapplication · blast radius 0
3 relations
- required · API/data flow · model requestsLiteLLM
- optional · API/data flow · tool callsFastAPI MCP
- optional · API/data flow · RAGOpenRAG
- OpenClawinterfaces · agent
1 relation
- required · API/data flow · model requestsLiteLLM
- OpenCodeinterfaces · coding-agent
1 relation
- required · API/data flow · model requestsLiteLLM
Control planeShared model gateway, routing policy and hot state.2 nodes · main flow ↓
- LiteLLMcontrol-plane · model-gatewayshared platform · blast radius 1
5 relations
- optional · dependency · cacheRedis
- required · API/data flow · routesToOllama
- optional · API/data flow · routesToOpenAI API
- optional · observation · telemetryLangfuse
- optional · observation · metricsPrometheus
- Rediscontrol-plane · cacheshared data · blast radius 6
InferenceLocal and remote model execution targets.2 nodes · main flow ↓
- Ollamainference · local-inferenceshared platform · blast radius 2
- OpenAI APIinference · remote-inferenceOpen ↗
Tools & knowledgeMCP tools, search, RAG and document knowledge boundaries.5 nodes · main flow ↓
- FastAPI MCPtools · mcp-serverOpen ↗
2 relations
- optional · API/data flow · tool boundaryOpen Terminal
- optional · API/data flow · searchSearXNG
- Open Terminaltools · agent-toolsupport · blast radius 0
- OpenRAGtools · ragOpen ↗
2 relations
- optional · observation · tracesLangfuse
- optional · observation · evaluationOpik
- Paperless-ngxtools · knowledgeOpen ↗
1 relation
- optional · API/data flow · knowledge flowOpenRAG
- SearXNGtools · searchsupport · blast radius 0
OrchestrationWorkflow engines coordinating long-running and automated work.3 nodes · main flow ↓
- Langfloworchestration · workflowshared platform · blast radius 2
1 relation
- required · API/data flow · workflowOpenRAG
- n8norchestration · workflowapplication · blast radius 0
1 relation
- optional · automation · automatesFastAPI MCP
- Temporalorchestration · workflowOpen ↗
1 relation
- optional · automation · document workflowPaperless-ngx
Observability & evaluationTracing, metrics, quality and evaluation feedback loops.3 nodes · main flow ↓
- Langfuseobservability · llm-observabilityshared platform · blast radius 2
- Opikobservability · evaluationOpen ↗
- Prometheusobservability · metricsapplication · blast radius 0
AI Platform is grouped by functional layers. The main flow moves from interfaces through control plane, inference, tools, orchestration and observability; edge semantics remain distinct from required/optional strength.
Homelab network and ingress paths
This React Flow diagram is the exact same component used on the TrueNAS page. For Garage, client HTTPS terminates at HAProxy on pfSense, HAProxy re-encrypts the backend connection with TLS to Traefik :443 on TrueNAS, and Traefik then routes to Garage. Cloudflare provides DNS only for Garage, while OpenWebUI uses a Cloudflare Tunnel terminated by the cloudflared Docker container.
Declared configuration, observed runtime, and health
The architecture deliberately separates what should exist, what is actually running, and what is operationally usable. This makes configuration drift visible without turning the website or the TrueNAS API into the configuration source of truth.
1. nabla-compose
Declarative source: x-nabla services, stable identity, runtime binding, and topology relationships. services.json and service-topology.json are generated from code.
2. TrueNAS API
Observed runtime source: the official truenas_api_client queries app.query for Apps, containers, states, and versions. It never decides that a service should exist or be public.
3. fastapi-sample
Reconciliation layer: joins declared bindings to TrueNAS workloads, classifies drift (in_sync, declared_only, observed_only, conflict), and keeps health checks separate.
4. albanandrieu.com
Presentation layer: visualizes topology, runtime status, and health without becoming a backend data source.
Declared ≠ Observed ≠ Healthy