UniFi Multi-Site Management in 2026: A Crosstalk Solutions Fork

The original UniFi Toolkit by Crosstalk Solutions assumes a single-controller environment.
My fork extends the toolkit to support multiple UniFi controllers in a unified operational dashboard, enabling centralized monitoring and automation across distributed UniFi deployments.

I am expanding this further in a custom SIEM system and will post here when that's ready. I havent decided if it'll be publilc or not yet. The unifi-toolkit will be one leg of the full bodied SIEM for open source services.

BACKGROUND

While UniFi Site Manager and Fabrics solve the organizational layer of multi-site infrastructure, administrators still need operational tooling for:

• automation
• monitoring
• telemetry collection
• infrastructure visibility

A community tool that has gained some traction is the UniFi Toolkit created by Crosstalk Solutions. Their content for PBX system configuration and management is supurb (https://www.youtube.com/c/CrosstalkSolutions).

The toolkit (https://github.com/Crosstalk-Solutions/unifi-toolkit) provides a dashboard and operational utilities for interacting with UniFi environments — but it originally assumed only a single controller.

That assumption breaks down quickly in real-world environments.

Most organizations running UniFi at scale operate with:

• multiple Cloud Gateways
• multiple controllers
• different physical sites
• sometimes segmented management networks

MY MULTICONTROLLER FORK

https://github.com/NetworkSofifi/unifi-toolkit

To address this limitation, I forked it and extended it to support multiple UniFi controllers within a single dashboard. This required several architectural changes.

Controller Registry

A registry of controllers is stored in a configuration table:

controller_config
-----------------
id
controller_key
controller_url
site_id
is_default
is_active

Each controller receives a unique identifier (controller_key) that allows the toolkit to scope requests and datasets correctly.

Controller Context Resolution

Every API request resolves a controller context before execution.

ControllerContext
-----------------
controller_id
controller_key
display_name

All routes and background jobs run inside this context.

Controller-Scoped Tool Data

All operational datasets now include a foreign key referencing the controller.

Example collection loop:

for controller in list_enabled_controllers():
    client = get_shared_client(controller.controller_key)
    collect_data(controller)

This makes sure that:

• telemetry remains site-isolated
• failures remain controller-specific
• data contamination between deployments is prevented

RUNTIME REQUEST FLOW

At runtime, controller selection propagates through the entire stack.

         User selects controller
                  ↓
      Frontend stores controller_key
                  ↓
   API requests include controller_key
                  ↓
   Backend resolves controller context
                  ↓
Tools execute against the correct UniFi API

Each controller runs in isolation, preventing cross-site data contamination.

WHY SCOPING MATERS

Without controller scoping, operational tooling quickly becomes unreliable as environments scale beyond a single deployment. The multi-controller architecture enables:

• centralized monitoring across controllers
• site-isolated datasets
• per-controller WebSocket event streams
• independent failure handling
• backward compatibility with single-controller deployments

TOOLING

Schedulers and collectors now iterate across enabled controllers, allowing infrastructure tools such as:

• Wi-Fi Stalker
• Threat Watch
• Network Pulse
  to operate across the full infrastructure footprint without mixing telemetry.
  This effectively creates a lightweight operational control plane layered on top of UniFi’s management platform.

ARCHITECHTURAL OUTCOME

I've transformaed the UniFi Toolkit from a single-controller dashboard into a multi-controller operational platform. For administrators managing several UniFi deployments, this closes an important operational gap between:

Simply:

Site Manager organizes your infrastructure.
Operational tools help you have improved visibility.

CLOSING THOUGHTS

The architectural changes described here reflect the implementation used in the multi-controller fork of the UniFi Toolkit. For teams managing multiple UniFi environments, this design enables:

• scalable controller management
• centralized operational visibility
• reliable automation across sites

without sacrificing the simplicity that makes UniFi attractive in the first place. I added two MD files to my repo fork. One is basically this article and the other is a detailed technical document on what files I edited and added.