Network configuration management, architected for 100,000+ nodes
The rConfig reference architecture for senior network architects and NetOps leaders running multi-tenant fleets, AI-driven remediation, and on-prem reach across MSP and tier-1 enterprise networks.
At a glance
- Fleet ceiling
- 100k+
- MTTF target
- < 5s
- Inference
- 42ms
Configuration management was a utility. Until somebody architected it.
For nearly three decades, network configuration management lived in the same drawer as network scanners and script utilities. Diffs, rollbacks, compliance evidence. Useful, never strategic. Nobody architected it because nobody had to.
That is no longer true. AI-native operations, multi-tenant MSP workloads, and 100,000-node fleets pulled NCM out of the utility drawer and put it on the critical path. We built rConfig around that shift, and we are publishing the full reference architecture, every layer, every trust boundary, every product, so the people evaluating these platforms can see how the pieces actually fit.
“rConfig is the first NCM stack where the configuration ground truth, the AI engine, the on-prem reach, and the multi-tenant operator console are designed and shipped together as one architecture.”
Read the full breakdown of why this architecture, and not the alternatives, further down the page.
Six architectural pillars. Each one ships as product.
Click any tile to jump straight to the deeper section, or to the dedicated product page where one exists.
- Read more
01 · Substrate
Continuous configuration ground truth
rConfig V8 is the foundation: multi-vendor backup, diff, rollback, compliance, automation. Every layer above reads from it and writes back to it. No drift between tools, because there is only one source.
- Read more
02 · Reasoning
AI diagnostics and remediation
Vector reasons over telemetry, parsed configuration topology (OSPF, BGP, L2 and L3 paths), and policy. Sub-second inference, risk-scored remediation proposals, sub-5-second mean time to fix on clean changes.
- Read more
03 · Reach
On-prem reach without data exfiltration
Vector Agent runs inside the customer trust boundary, talks SSH, SNMP, HTTP locally, and ships only the metadata Vector needs over a single mTLS outbound channel. Raw configs and credentials never leave site.
- Read more
04 · Operator surface
Multi-tenant operator console
Vector Prism gives MSPs a single console scoped per tenant. Per-customer device counts, health posture, change history, and audit. Zero shared blast radius between tenants, by design.
- Read more
05 · Inputs
Inventory and integrations layer
Statseeker, Zabbix, NetBox, Nautobot, PRTG, AKIPS, Tufin, Checkmk feed inventory and topology context into rConfig. Connective tissue between your existing observability stack and the configuration plane.
- Read more
06 · Services rail
Bespoke services rail
rConfig Bespoke runs alongside the stack. Network configuration and automation engineering, delivered by our own engineers, for fleets up to 20,000+ devices. Carriers, government, global enterprise.
The first NCM stack architected for AI, multi-tenancy, and regulated networks at the same time.
From top to bottom, the managed fleet is the “why”, the business reason any of this exists. Everything below it earns its place by serving that fleet, under the cost, audit, and risk constraints that real network operators actually live with.
Until now, getting, multi-tenant operator isolation, AI-supported, on-prem reach without exfiltration, and continuous configuration ground truth meant stitching together four or five separate vendors and writing the glue yourself. rConfig is the first stack to ship them as one designed architecture, and the first to publish it openly.
Vector Prism sits above Vector Agent because an MSP customers demand transparency and control over the on-prem data collection. The agent is a data plane component, not a control plane one. It is designed to be invisible and hands-off, and the MSPs become the operator on a white label solution. The Prism UI is the only way to interact with the platform, and the only way to get data out of it. No other reference architecture in this category draws that line.
Vector is built on V8, not next to it because regulated networks demand a single, signed configuration record-of-truth. If V8 and Vector were peers, you would end up with two competing models of the network and two diverging audit trails. Instead Vector reads topology, drift, and policy state directly out of V8. One source, one history, one answer when an auditor asks who changed what at 03:14 last Tuesday.
Vector Agent is on-prem by design, not by accident because NIS2, DORA, GDPR, ISO 27001, and most carrier-grade customer contracts will not let raw running configurations leave the customer perimeter. The agent ships parsed metadata and config hashes over a single mTLS channel, and nothing else. AI reasoning at the centre, sensitive payloads at the edge. No other reference architecture in this category draws that line.
Bespoke is a rail, not a layer, because regulated, large-fleet engagements touch every layer at the same time. A 20,000 CPE rollout needs V8 backups, Vector policy hooks, Agent deployment, and Prism handover inside a single change-control window. Treating Bespoke as a horizontal layer would lie about how the work actually happens, and lying about that costs customers six-figure overruns.
Business case
One stack, one vendor, one upgrade path. The buyer signs a single contract instead of stitching five. The operator runs ten tenants from one console instead of ten.
Compliance case
One signed audit trail. One trust boundary at the customer edge. Direct alignment to NIS2, DORA, GDPR, and ISO 27001 technical-control language, with the evidence already in the store.
Industry-first
No other vendor in the network configuration management space has shipped continuous ground truth, an AI engine, on-prem reach, and a multi-tenant operator console as one designed architecture. We are publishing it openly because nothing like it exists yet.
Why this architecture, and not the alternative `tools`.
Most network configuration and automation tooling falls into one of three patterns. None of them are wrong. They just stop short of what a modern, multi-tenant, AI-native NCM stack actually has to do.
- 01
Source-of-truth platforms
Strong intent models, no remediation engine, no multi-tenant operator layer.
e.g. Infrahub (OpsMill), standalone NetBox usage
- 02
Automation runners
Execute change against someone else's data plane. No AI reasoning over configuration state.
Push-only tooling on top of an external SoT
- 03
Traditional NCM
Backups and diffs. Not designed for AI-native operations or multi-tenant MSP workloads.
The category rConfig grew up in
We respect the work in each of those categories. Infrahub (OpsMill) does intent and data modelling well, and the source-of-truth space has matured enormously. NetBox is part of how a lot of networks are documented today. Nautobot is an inventory source-of-truth that we plug into directly: it feeds rConfig the device context we need, rather than competing with us.
The line we draw is architectural. rConfig is the only stack where the configuration ground truth (V8), the AI engine (Vector), the on-prem reach (Agent), and the multi-tenant operator console (Prism) are designed and shipped as one continuous architecture. Bespoke runs alongside as a services rail for fleets too large to take on alone.
For a layer-by-layer breakdown, read on. The next six sections go deep on V8, Vector, Vector Agent, Vector Prism, the worked production case study, and the integrations layer.
The base platform: rConfig V8
V8 is the substrate. Three editions on a continuous upgrade path: V8 Core (open source, multi-vendor backups, diff, rollback), V8 Pro (RBAC, SSO, the compliance and policy engine), V8 Enterprise (HA, advanced concurrency, the central manager that handles the integrations layer for fleets in the ten-thousands).
Every layer above reads from V8 and writes back to V8. Vector reasons over the configuration history that V8 stores. Vector Agent ships its results into V8. Prism queries V8 for tenant state. This is the whole point of treating ground truth as a substrate: the rest of the stack stops needing to maintain its own model of the network.
If you take only one thing from this layer, take this: the policy engine and the configuration history are the same system. A compliance violation is a query against the same store that gives you yesterday's running config. That tight coupling is what lets Vector turn a config diff into a risk-scored remediation plan in a single inference pass.
Fig. 1 · V8 editions on the configuration ground truth · © rConfig 2026
Fig. 2 · Telemetry into Vector, three labelled outputs · © rConfig 2026
Vector: the Config Backup engine that thinks in topology, not text
Vector parses configuration as topology. OSPF area 0 is a graph. BGP confederations are a graph. ECMP fan-out is a graph. When a config changes, Vector does not diff the text first, it diffs the graph the text describes. That is the difference between a tool that finds a missing semicolon and a tool that tells you which routing adjacencies just collapsed.
Three things come out of every inference pass: drift detection against the policy baseline, a root-cause inference that explains why a state shift happened, and a risk-scored remediation proposal with an explicit blast radius. Inference lands in roughly 42 milliseconds on a typical 30-device blast-radius scope. End-to-end mean time to fix on a clean change-window edit is under 5 seconds.
A point that catches senior architects out: Vector tells the difference between drift and an authorised change-window edit by checking the change source and the policy hooks attached to the affected scope. A push from an authenticated CI runner inside an active maintenance window is not flagged. A manual edit from a console outside that window, on the same line, is. Same diff. Different verdict.
Vector Agent: on-prem reach, without exfiltration
Vector Agent is the lightweight on-prem collector. One per customer, often one per site. It runs inside the customer trust boundary, talks SSH, SNMP, and HTTP locally to the devices it owns, and ships only what Vector actually needs back to the central engine.
Senior architects always ask the same two questions, so let us answer both directly. What leaves the customer environment: config hashes, parsed structural metadata, telemetry samples, and the audit metadata Prism needs to render an operator view. What does not leave: raw configuration files, plaintext credentials, or customer secrets. Credential storage stays inside the agent, encrypted at rest with a per-tenant key.
The channel is a single outbound mTLS connection on 443/tcp. Mutual auth on both sides: the agent presents a per-tenant certificate, the central control plane presents one signed by the customer-known CA. No inbound ports are opened on the customer firewall. If you can reach a public web URL, you can run an agent. If you cannot, the agent buffers locally and resyncs cleanly when the link returns.
Fig. 3 · Trust boundary, single outbound channel · © rConfig 2026
Fig. 4 · Prism with isolated tenant panels · © rConfig 2026
Vector Prism: a multi-tenant operator console with zero shared blast radius
Prism is the newest layer in the stack and, for an MSP, often the most consequential. One operator, several customers, one console. Each tenant gets a fully scoped panel: device counts, health posture, recent changes, current compliance state, the running tally of inflight remediations. Switching tenants is a scope change inside Prism, not a separate session.
Tenant isolation is enforced at the data layer, not at the UI. A query in tenant A cannot return a row from tenant B, even by accident, because the query rewriter prepends the tenant scope before the database ever sees it. Operator actions are similarly scoped: a push from a Prism operator cannot touch a device outside the active tenant.
The point of all this is not security theatre, it is reduced blast radius. When a TenantTwo operator does the wrong thing at 3am, the consequences land in TenantTwo. Not the global Prism. Not TenantOne. Not the MSP control plane.
In production: from a Zabbix inventory event to a Prism operator view
An illustrative end-to-end flow, the kind that runs every few minutes inside any MSP using rConfig at scale. The architectural point is that one event crosses every layer and never breaks tenant isolation.
- 01
Zabbix discovers a new device
A new CPE comes online in TenantTwo, region EU. Zabbix updates its inventory, tags the host, and emits the event over the standard integration webhook.
- 02
Central Manager reconciles against ground truth
The rConfig Central Manager (V8 plus the Vector control plane) ingests the inventory update, normalises it, and reconciles it against the existing configuration ground truth for that tenant. New device, expected vendor, no immediate match in the running config: queue for first-touch.
- 03
Vector Server applies policy hooks
Vector reasons over inventory plus configuration. Identifies the device, runs the golden config policy hook for the tenant's CPE class, finds two policy gaps (NTP source and SNMPv3 view scope), generates a risk-scored remediation plan. Inference, 42 ms.
- 04
Vector Agents execute locally
The TenantTwo agent on-site applies the two safe remediations under the active change-window policy. The third, a higher-risk routing-protocol change, is left as a proposal for an operator. Raw config never leaves the customer site.
- 05
Prism surfaces the whole flow to the right tenant
The TenantTwo operator opens Prism. The new device appears, the two auto-applied remediations are listed with their risk score and policy hook, the third sits in the queue with a one-click approve. Tenant scope is enforced, no other operator sees this view.
Concrete spec, one
Mean time from inventory event to a fully reconciled tenant view, on a clean change, under five seconds. Inflight concurrency, 200 events per second sustained on a single Vector Server in the reference HA pair.
Concrete spec, two
If the inventory event arrives during an active maintenance window with a registered change ticket, the policy hooks relax the drift threshold and the auto-apply scope expands. Outside that window, the same event is quarantined and operator approval is required. Same diff, different verdict.
That single flow is the architecture of section 4 actually working. It is why V8 sits at the bottom, why Vector reads from V8 directly, why the agent never opens an inbound port, and why Prism is a scope on top of the central control plane and not a federated collection of per-tenant UIs.
Inventory and integrations: the connective tissue
The integrations layer is what makes the architecture real in production. rConfig pulls inventory and topology context from the tools your network team is already running. Statseeker, Zabbix, NetBox, Nautobot, PRTG, AKIPS, Tufin, and Checkmk all feed in. We treat the integration as a normalisation step: each source emits its own shape, the central manager dedupes and tags, and Vector sees one consistent inventory.
That matters because senior architects rarely get to pick a single source-of-truth and stick to it. There is always a Statseeker dashboard nobody is going to retire, and a NetBox instance that the network design team owns. rConfig joins what you have rather than asking you to migrate it.
Fig. 5 · Partners feed inventory ingest, ingest feeds the stack · © rConfig 2026
rConfig Bespoke: the services rail
Bespoke runs alongside the stack. Network configuration and automation engineering, delivered by our own engineers, for fleets up to 20,000+ devices. Carriers, government networks, global enterprises. We bring the engineering hands. The customer keeps the platform when we leave.
Treating it as a rail rather than a layer is deliberate. A Bespoke engagement touches V8 backups, Vector policy, Agent rollout, and Prism handover all at once. Slotting that into the layered architecture as a horizontal layer would lie about how the work actually happens.
Fig. 6 · Bespoke runs as a rail alongside the stack · © rConfig 2026
Talk to a network architect, or try V8 Core for free
V8 Core is open source. The reference architecture starts there. Run it locally, or talk to one of our network architects about Vector, Prism, Agent, or a Bespoke engagement.
All architectural diagrams, illustrations, and reference architecture content on this page are © 2026 OS Informatics Ltd, T/A rConfig. Reproduction, redistribution, or derivative use requires written permission. rConfig® is a registered trademark.