Back to rConfig Vector

MSP network configuration management architecture

Vector, built the way MSPs really work

Your devices sit in your customers' networks. You do not own those networks, you cannot always open their firewalls, and some customers need data kept in-country. So Vector puts an agent in each customer network and one server in the middle. Add a Central Manager when you grow into many countries.

The Vector architecture, light: agents in four customer networks reporting to one Vector ServerOne Vector Server for every customer network, with an optional Vector Central Manager above it for many countries. Vector Agents in four customer networks connect to it: two over the internet using outbound TLS by default, and two over a customer VPN or MPLS link in the optional bidirectional mode.Central ManagerOptional, for many countriesVector ServerCentral platformCUSTOMER AVector AgentInternetCUSTOMER BVector AgentInternetCUSTOMER CVector AgentVPN or MPLSCUSTOMER DVector AgentVPN or MPLSOutbound TLSby defaultOptionalbidirectionalmodeThe Vector architecture, light: agents in four customer networks reporting to one Vector ServerOne Vector Server for every customer network, with an optional Vector Central Manager above it for many countries. Vector Agents in four customer networks connect to it: two over the internet using outbound TLS by default, and two over a customer VPN or MPLS link in the optional bidirectional mode.Central ManagerOptional, for many countriesVector ServerCentral platformCUSTOMER AVector AgentInternetCUSTOMER BVector AgentInternetCUSTOMER CVector AgentVPN or MPLSCUSTOMER DVector AgentVPN or MPLSOutbound TLS by defaultOptional bidirectional mode over VPN or MPLS
View full size
The problem

Three Questions
Every MSP Gets Asked

  • What do we need to open?

    Every new customer starts with a firewall change request. Weeks disappear before the first backup runs.

  • Where does our data live?

    Customers and regulators want to know exactly where their network configurations are stored, and who can reach them.

  • What happens when you grow?

    One more customer, one more region, one more country. Most NCM tools answer with another server to patch and license.

The Vector architecture answers all three by putting each job where it belongs.

The layers

Three Layers.
Most MSPs Need Two.

Vector splits the work into layers. Each layer can grow on its own, and you can put it wherever your rules say it must go. Most MSPs only need a Vector Server and its agents.

  1. LAYER 1 · CUSTOMER EDGE

    Vector Agent

    A lightweight Go collector deployed inside each customer network. It connects to routers, switches, firewalls and more over SSH, collects configurations close to the devices and applies changes. Holds device credentials in memory only, per job. Horizontally scalable.

    • Backups
    • Config retrieval
    • Command execution
    • Policy checks
    Secure connectivity
  2. LAYER 2 · SERVER

    rConfig V8 Vector Server

    The heart of the deployment. It stores configurations, backups and change history, schedules jobs through its agents and provides the full V8 Pro feature set: search, diff, rollback, compliance, reporting and notifications. Hosted in your data centre or private cloud.

    • Storage
    • Jobs
    • Compliance
    • Reporting
    • Customer separation
    Intelligence layer
  3. LAYER 3 · OPTIONAL

    Vector Central Manager

    For multi-server and multi-country estates. Holds the global inventory, users and roles, and orchestrates work across every Vector Server over a RabbitMQ message bus. Deployed with rConfig Professional Services.

    • Global inventory
    • Orchestration
    • RabbitMQ
    • Central user management
    Inventory and scale layer
Connectivity

Outbound by Default.
Two-Way When You Need It.

Every customer network is different. Some will never open a port. Others are already connected to you over MPLS. Vector supports both, and a single Vector Server can mix them across customers.

Secure unidirectional and bidirectional connectivity compared
Secure unidirectionalBidirectional
TransportInternetVPN, MPLS or private WAN
Who connectsThe agent opens an outbound, encrypted connection to the Vector ServerEither side. Through the Vector Hub, the Vector Server can also start sessions into the customer network
Customer firewallNo inbound rules. An outbound-only agent is all that is neededUses the routed path you already have
Backups and changesScheduled backups and configuration changes, fully supportedScheduled backups and configuration changes, fully supported
AddsBaseline, nothing extra to configureVector Access to end devices through the agent · Real-time backups started by the Vector Server through the Vector Hub · Live interrogation of devices
Best forNew customers, small offices, locked-down networksLarger accounts already on your WAN, NOC-driven operations

Start every customer outbound only. Move them to bidirectional when the link exists and the operation calls for it. Nothing about the agent changes.

Core architecture

Single Vector Server.
One Hub for Every Customer.

The standard model. One Vector Server, with a Vector Agent in each customer network.

Vector architecture for MSPs: one rConfig V8 Vector Server connected to Vector Agents in four customer networks, over secure unidirectional internet and bidirectional VPN or MPLS links
Figure 1. One Vector Server for every customer network. Internet and VPN customers sit side by side on the same server.
  • One hub for every customer. Configurations, jobs, policies and reports in one place, with customer separation.
  • Internet and VPN/MPLS side by side. Each customer uses the connection mode that suits their network, on the same server.
  • No Central Manager needed. A Vector Server and its agents cover most deployments, including MSPs with many customers.
Core architecture

Multi-Country.
Data Stays In-Country.

Your customers may be in many countries, and each country has its own rules on where data can live. Run a Vector Server in each country, inside its own border. The Central Manager gives you one list of devices and one set of users across all of them.

Multi-country Vector architecture: Vector Central Manager and RabbitMQ orchestrating Vector Servers in Ireland, Germany and Australia, each inside a sovereign data boundary
Figure 2. Vector Servers in Ireland, Germany and Australia, each inside its own sovereign boundary, orchestrated by the Vector Central Manager over RabbitMQ.
  • Configs stay in-country. Configurations, backups and change history are stored on the Vector Server in the country they came from.
  • Orchestration over RabbitMQ. Queues per region carry jobs down and status back over AMQP with TLS. Only orchestration data and job messages cross borders.
  • One Central Manager. Global inventory, users and roles. Each device is assigned to its home region and work is dispatched to the right server.

Where regulation requires that no metadata at all leaves a region, Vector can also run as fully separate deployments per jurisdiction. Our team will help you choose the right pattern.

Reference architectures

More Reference Architectures

Four more designs, documented in depth on Uplink: what each implements, how traffic flows, and honest pros and cons.

  • One Vector Server above two shared access nodes, each running one Vector Agent per customer
    Validated design

    Single server with customer access nodes

    Best for: MSPs reaching many customer networks from shared infrastructure.

    Read the guide
  • A Vector Server with Vector Prism giving each customer a branded, read-only view of its own configurations
    Reference design

    Co-managed MSP with Vector Prism

    Best for: MSPs whose customers want to see their own configs.

    Read the guidePrism product page
  • Vector Agents at points of presence across one provider network, reporting to a Vector Server
    Reference design

    ISP: distributed by point of presence

    Best for: Providers running one network across many PoPs.

    Read the guide
  • One Vector Agent in each security zone of an enterprise network, connecting out to a Vector Server
    Reference design

    Enterprise: agent per security zone

    Best for: Segmented networks (PCI, OT, DMZ, cloud) with no inbound rules into any zone.

    Read the guide
Vector Access

Jump Straight to Any Customer Device

Your team logs in to a device in a customer's network through the agent, using Vector Access, without leaving Vector.

  1. Sign in

    The engineer signs in and RBAC decides what they can reach.

  2. Server proxies the session

    The Vector Server proxies the session to the right customer agent.

  3. Agent carries the jump

    The agent carries the jump onward inside the customer network.

  4. Straight onto the device

    The engineer lands on the device, with no direct route into the customer network.

Requires bidirectional (two-way) mode. Customers on internet-only connections still get backups and changes over the agent's outbound connection.

Single rConfig V8 Vector Server above two customer access nodes. Each node runs one Vector Agent per customer, named by customer prefix, with policy-based routing into each customer network. A highlighted Vector Access path shows a support engineer jumping through the server and agent to a customer device.
Choose

Choose Your Architecture

Answer four questions and get a starting point. Every design has a full guide on Uplink.

All six architectures

Onboarding

From Signed Contract
to First Backup

  1. Add the customer

    Add the customer to your Vector Server with its own inventory, jobs, policies and audit history.

  2. Deploy the agent

    Install the Vector Agent on a Linux or Windows host inside the customer network, by hand or automated through the REST API.

  3. Choose the connection

    Outbound only over the internet, or bidirectional through the Vector Hub over the customer's existing VPN, MPLS or private WAN link.

  4. Import devices and attach policies

    Reuse the global policies and reports you have already defined for every other customer.

  5. Back up, change, prove

    Scheduled backups start immediately. Changes, compliance checks and per-customer reports run from one console.

  6. First backup, done

    About 1 hour

    In most cases, once your Vector Server is running and the agent can reach the customer's devices. Firewall changes, device access and approvals can add time.

A first MSP customer typically goes from installation to working backups in one to two weeks. Once your customer template is stable, new customers usually take one to three days.

The Vector Suite

The Vector Suite

The server, the agents and the portal work as one. Running a large, global MSP or enterprise? Our Professional Services team can help you build it with robust support and full control.

Security

Self-Hosted,
Inside Your Perimeter

  • No SaaS dependency

    Every layer runs on infrastructure you control. rConfig has no access to your data unless you grant it.

  • Encrypted in transit

    Agent to server over TLS. Server to Central Manager over AMQP with TLS.

  • Customer separation

    Each customer has its own inventory, jobs and audit history, with hierarchical RBAC across your NOC and scoped access for customers.

  • Built for resilience

    Vector supports HA deployment patterns. The Vector Agent holds device credentials in memory only, per job.

Uplink

Go Deeper on Uplink

Vector Architecture, Frequently Asked Questions

Do I need the Vector Central Manager?

Most MSPs and enterprises do not. A Vector Server and its agents cover the vast majority of deployments, including MSP operations with many customers. The Central Manager is for estates with multiple Vector Servers, usually across countries, and is deployed with rConfig Professional Services.

What do customers need to open on their firewall?

Nothing inbound. In outbound-only mode, the default, the Vector Agent makes an outbound, encrypted connection to your Vector Server. If the customer is already on your VPN, MPLS or private WAN, you can add bidirectional mode through the Vector Hub.

What does bidirectional connectivity add?

Bidirectional mode runs through the Vector Hub, a service that runs alongside the Vector Server. It needs a routed path into the customer network, such as VPN, MPLS or private WAN. It adds real-time backups triggered from the Vector Server, live interrogation of devices, and Vector Access, which logs an engineer in to a device through the agent.

Can one Vector Server mix both connection modes?

Yes. Each customer can use whichever mode suits their network, on the same Vector Server.

Where is configuration data stored in a multi-country deployment?

On the Vector Server in each country. The Central Manager holds global inventory, users and orchestration state, and exchanges job and status messages with each server over RabbitMQ. Where no metadata may leave a region, Vector can run as fully separate deployments per jurisdiction.

Can I start small and grow into multiple countries later?

Yes. Start with one Vector Server and agents. When you add countries, deploy regional Vector Servers and the Central Manager. Your agents, policies and workflows carry on as before.

Does Vector Access need two-way mode?

Yes. Vector Access needs bidirectional mode, over VPN, MPLS or a private WAN. Internet-only customers still get backups and changes over the agent's outbound connection.

Can one server reach many customer networks from shared infrastructure?

Yes. Run one Vector Agent per customer on shared access nodes, named by customer prefix, with policy-based routing pinning each agent to its own customer. See the access nodes guide.

Can our customers see their own configurations?

Yes, with Vector Prism, a white-label, read-only, tag-scoped portal on a branded subdomain of your domain. See the Vector Prism page.

Does Vector suit ISPs and enterprises as well as MSPs?

Yes. Vector can run as one agent per point of presence across a provider network, or one agent per security zone in a segmented enterprise network. The ISP by PoP and security zones guides cover each design.

Map Your Customers Onto Vector

Bring your customer list, your connectivity mix and any data residency requirements. We will walk through a working Vector demo in both connection modes and sketch the architecture that fits, from one server to many countries.

Back to rConfig Vector