Diagram: Deployment Options
Relevant source files
The following files were used as context for generating this wiki page:
The AI Network Operations Platform provides flexible deployment models to suit network engineering teams ranging from small lab environments to large-scale enterprise productions. This platform serves as a self-hosted AI Network Engineer that automates discovery, troubleshooting, and configuration management across multi-vendor environments.
The platform is designed with a "local-first" philosophy, meaning all data and AI reasoning stay within your infrastructure. It supports two primary deployment methods: Docker Compose for simple, single-server setups and Kubernetes/Helm for hardened, production-grade environments.
Sources: README.md:1-10, CLAUDE.md:3-10
Overview
The platform functions as an AI assistant for network operations, solving the problem of manual infrastructure management and fragmented troubleshooting. It acts as a specialized team of "Agents" (Discovery, Troubleshooting, DDI, etc.) that can read your network state and propose changes.
Key Principles
- Local-First & Self-Hosted: No sensitive network data or credentials leave your environment.
- Human-in-the-loop: Every change requested by the AI requires a human approval before execution.
- Auditability: Every decision made by the AI agents is logged and explained in plain English.
- Multi-Vendor Support: Native integration for Cisco (IOS/NX-OS), Juniper, Arista, Palo Alto, Fortinet, F5, BlueCat, Infoblox, and major cloud providers (AWS/Azure/VMware).
Specialist Agents
The platform routes your requests to specialized team members:
- Master Architect: The supervisor who decides which specialist should handle your request.
- Discovery Agent: Enumerates inventory and maps neighbors.
- Troubleshooting Agent: Diagnoses live routing, BGP, OSPF, and ACL issues.
- DDI Agent: Manages DNS, DHCP, and IPAM records.
- Security Agent: Audits firewall policies for overly permissive or redundant rules.
Sources: CLAUDE.md:12-30, README.md:15-25, backend/app/llm/prompts/init.py:250-350
System Overview
This diagram shows how engineers interact with the platform and what external systems the platform connects to.
The system acts as a bridge between the engineer's natural language and the technical commands required by various hardware vendors.
Sources: CLAUDE.md:12-25, README.md:15-25
Architecture Components
The platform consists of seven core components that work together to manage your network.
- frontend: The web interface where you chat with the AI, view your topology map, and approve changes.
- api: The central brain that handles requests, verifies who you are, and manages agent conversations.
- worker: The background engine that runs long-running tasks like discovery scans, configuration backups, and document generation without freezing your screen.
- postgres: The main database (system of record) that stores your device inventory, audit logs, and AI memory.
- neo4j: A living topology map that tracks how every device, interface, subnet, and application connects to everything else.
- redis: A fast message broker that coordinates communication between the API and the background workers.
- ollama: An optional local service that runs the Large Language Models (LLM) so no data goes to the cloud.
Sources: README.md:25-35, deploy/docker/README.md:5-15
Vendor Plugin System
The platform uses a standardized connector for each vendor. Whether you are talking to a Cisco router or a BlueCat Address Manager, the platform normalizes the output into a consistent format before any analysis is performed. This allows the AI to troubleshoot a path across different hardware brands seamlessly.
Sources: README.md:35-40, backend/app/plugins/vendors/cisco_nxos/parsers.py:1-20
Deployment Options
Docker Compose (Lab / Small Team)
Docker Compose is the target for small on-premises installs. It runs the entire platform on a single server using a single command. It is ideal for testing vendor plugins or managing a small lab.
Kubernetes & Helm (Production)
The Helm chart provides a production-grade deployment. It includes advanced security features, such as "NetworkPolicies" to isolate traffic and "Pod Security Standards" to ensure containers run with minimal privileges. While P1 is single-replica, it provides the foundation for high availability (HA) in future updates.
Sources: deploy/docker/README.md:1-5, deploy/kubernetes/netops/README.md:1-15
Side-by-Side Comparison
This diagram illustrates the difference between the single-server Docker setup and the multi-node Kubernetes architecture.
Docker Compose groups all services on one machine, whereas Kubernetes distributes them across multiple nodes for better security and resource management.
Sources: deploy/docker/docker-compose.yml:1-50, deploy/kubernetes/netops/README.md:10-40
Change Approval Workflow
Safety is a core design requirement. The platform never makes a change directly; it always follows a strict lifecycle.
- Draft: The AI specialist (e.g., DDI Agent) creates a proposed change.
- Pending: The change is visible in the frontend awaiting a human signature.
- Approved: A network engineer reviews and approves the change.
- Executing: The Automation Agent takes a pre-change backup, applies the config, and verifies the result.
- Completed/Rollback: If the change fails verification, the platform can use the pre-change backup to restore the original state.
Sources: README.md:15-20, CLAUDE.md:40-45, backend/app/agents/ddi/agent.py:15-25
Approval Flow Diagram
This flow ensures that no command is sent to a production device without human oversight and a verified safety net.
Sources: backend/app/agents/ddi/agent.py:15-30, deploy/docker/docker-compose.yml:60-70
Data Model: The Topology Map
The platform maintains a "living topology map" in the Neo4j database. This allows the AI to understand the relationships between different network entities rather than just seeing them as a list of IPs.
| Entity | Plain English Translation |
|---|---|
| Device | A physical router, switch, or firewall. |
| Interface | A physical or logical port (e.g., GigabitEthernet0/1). |
| Subnet | An IP network range (e.g., 10.0.1.0/24). |
| VLAN | A layer 2 broadcast domain. |
| DNS Zone | A naming domain (e.g., example.com). |
| Application | The end-user service that depends on all the above. |
Sources: CLAUDE.md:30-35, backend/app/agents/documentation/agent.py:50-60
Topology Relationships
The topology map allows the AI to answer questions like "Which application breaks if I shut down this specific switch interface?"
Sources: CLAUDE.md:30-40, backend/app/agents/documentation/agent.py:50-60