Self-Hosted Network Management

Why Self-Hosting Matters for Network Management

Network management platforms occupy a uniquely sensitive position in your infrastructure. They store device credentials — the SSH passwords and API keys that provide direct access to every router in your fleet. They store configuration data — the complete running state of every managed device. They store monitoring history — traffic patterns, bandwidth utilization, and device health data that reveals your network's architecture and capacity.

When you use a cloud-hosted network management service, all of this data lives on someone else's infrastructure. Your router passwords are stored in someone else's database. Your config history is backed up to someone else's object store. Your monitoring data flows through someone else's ingestion pipeline.

For many organizations, this is a non-starter. MSPs with contractual obligations around client data handling can't send device credentials to a third party. ISPs in regulated markets may have compliance requirements around where network infrastructure data is stored. Government and defense contractors operate under frameworks that prohibit cloud-hosted management of network devices. Even without formal compliance requirements, sending your complete device credential set to a SaaS platform is a risk that many network engineers are uncomfortable with.

Self-hosted network management eliminates this class of risk entirely. Your data stays on your hardware, behind your firewall, under your control.

Deployment Options

Docker Compose

The primary deployment method is Docker Compose. A single docker-compose.yml file brings up the entire stack: the React frontend, the FastAPI backend, the Go poller, PostgreSQL with TimescaleDB, Redis, NATS JetStream, and OpenBao for credential encryption.

Prerequisites are minimal: a Linux host (or macOS for development) with Docker and Docker Compose installed. The included setup wizard (setup.py) walks through initial configuration — database credentials, admin user creation, and basic platform settings. From clone to running platform with your first connected device takes about ten minutes.

Docker Compose is the right choice for most deployments. Single-server installations handling up to several hundred devices run comfortably on modest hardware. The compose file handles container orchestration, networking between services, and volume management for persistent data.

Kubernetes via Helm Chart

For organizations that run Kubernetes, the project includes a Helm chart. This provides the same stack deployed as Kubernetes resources: Deployments, Services, ConfigMaps, Secrets, and PersistentVolumeClaims.

The Helm chart is useful for teams that want to integrate the platform into existing Kubernetes infrastructure, take advantage of Kubernetes features like auto-restart and resource limits, or deploy across multiple nodes for availability. It's not required — Docker Compose is simpler and sufficient for most use cases.

What Runs on Your Infrastructure

Everything. There is no external service dependency for core functionality. Here's what the stack includes:

• PostgreSQL + TimescaleDB — All device data, config history, user accounts, audit logs, and time-series metrics are stored in PostgreSQL. TimescaleDB extensions handle the high-frequency metric data efficiently.
• Redis — Session caching, rate limiting, and ephemeral state. No persistent data — Redis can be flushed without data loss.
• NATS JetStream — Real-time event bus between the poller and backend. Device status changes, metric updates, and command results flow through NATS. Also provides durable streams for reliable delivery.
• OpenBao — Manages encryption keys for device credentials. Per-tenant envelope encryption means each tenant's credentials are encrypted with a unique key. OpenBao runs as a container within the stack — no external vault service required.
• Go Poller — Connects to MikroTik devices via the RouterOS binary API over TLS (port 8729). Handles metric collection, config backup retrieval, command execution, and health monitoring. Maintains persistent connections with automatic reconnection.
• FastAPI Backend — REST API, authentication (SRP-6a zero-knowledge protocol), RBAC enforcement, task orchestration, and SSE for real-time browser updates.
• React Frontend — The web UI. Fleet dashboard, config editor, monitoring views, WinBox-in-browser, SSH terminal, and all management interfaces.

No Cloud Dependency

The platform makes no outbound network connections for its core functionality. There is no license server to validate against. There is no cloud API that needs to be reachable. There is no telemetry that phones home by default.

The single optional external connection is a check for new MikroTik firmware versions, which queries MikroTik's public version endpoint. This is disabled by default and only used to show firmware update availability in the fleet view. Disabling it has no impact on functionality.

Optional anonymous telemetry is available for development diagnostics — it's disabled by default, opt-in only, and the exact data it would collect is documented in the source code so you can inspect it before enabling. No usage tracking, no analytics, no data collection that you haven't explicitly opted into.

Air-Gapped Deployment

Because there are no external dependencies, the platform can run in air-gapped environments with no internet access. Pull the Docker images on a connected machine, transfer them to the isolated network, and deploy. The platform functions identically whether it has internet access or not.

This is relevant for government networks, classified environments, industrial control system networks, and other contexts where internet connectivity is either unavailable or prohibited for management infrastructure.

Comparison with Cloud-Hosted Alternatives

Cloud-hosted network management platforms solve real problems and many are well-engineered. The tradeoff is the trust model:

• Credential exposure. Cloud platforms need your device credentials to connect to your routers. Those credentials are stored on infrastructure you don't control, protected by security practices you can't audit (unless the platform is open source, which most commercial ones aren't).
• Data sovereignty. Config history, monitoring data, and audit logs live in the provider's cloud. Depending on your jurisdiction and your clients' requirements, this may conflict with data residency obligations.
• Vendor lock-in. Your operational history — config versions, monitoring trends, audit trails — is in the provider's database. Switching platforms means losing that history or undertaking a complex data export.
• Availability dependency. If the cloud provider has an outage, your network management goes offline. Your routers keep running, but you lose visibility and management capability until the service recovers.
• Cost scaling. Cloud platforms typically charge per device per month. At fleet scale, this adds up. A self-hosted platform's cost is the hardware it runs on, which you likely already have.

Self-hosted management trades operational convenience (someone else runs the infrastructure) for control (you run the infrastructure, you own the data, you control access). For network management specifically — where the platform holds the keys to your entire routing infrastructure — that tradeoff often favors self-hosting.

Open Source

The platform is open source and available on GitHub. You can audit the code that touches your device credentials. You can verify the encryption implementation. You can read exactly what API calls the poller makes to your routers. Self-hosted plus open source means you have both operational control and code-level transparency.

Getting Started

The Quick Start guide covers the full deployment process. Clone the repository, run the setup wizard, connect your first device. The platform is running on your infrastructure in about ten minutes.