High-level architecture

Reddwatch is organized into planes — separate, independently operated layers with one job each. The design rule that governs everything: an integrator's console session lives inside exactly one instance; only the Redd Ash control plane sees across instances.

flowchart TB
    subgraph Admin["Control plane — admin.reddwatch.com (Redd Ash only)"]
        REG[Instances registry]
        FLEET[Fleet views]
        OTA[Update / OTA controls]
        BILLO[Billing overview]
    end

    subgraph Instances["Instance plane — one per integrator"]
        A1["app101 · console.reddwatch.com<br/>portal + API + workers"]
        A2["app102 · integrator B"]
        A3["appNNN · …"]
    end

    subgraph Shared["Shared backbone (Redd Ash operated)"]
        IDP["Identity · Keycloak SSO"]
        MON["Monitoring plane · Zabbix"]
        DATA["Central data plane · PostgreSQL"]
        UPD["Artifact plane · update.reddwatch.com"]
    end

    subgraph Sites["Site plane"]
        N1["Site node · city A"]
        N2["Site node · plant B"]
        N3["Site node · campus C"]
    end

    Admin -->|oversees / provisions| Instances
    Instances --> IDP & MON & DATA
    Sites -->|encrypted overlay,<br/>outbound only| MON
    Sites -->|heartbeat + frames| Instances
    Sites -->|signed releases| UPD

The planes

Instance plane — each integrator gets an isolated Reddwatch instance: its own web portal, API, alert workers, and database. Logging into the console means logging into one instance — users land in the instance their account is assigned to. Everything a tenant sees and touches lives here: clients, devices, alerts, topology, reports, camera frames.

Control plane (admin.reddwatch.com) — the Redd Ash overseer console. Instances registry and lifecycle, fleet-wide node/update orchestration, billing overview, cross-instance directory. Nothing tenant-facing runs here; it reads across instances but never becomes a data-path proxy.

Monitoring plane — a managed Zabbix deployment does the raw collection: availability, SNMP telemetry, RF metrics, hardware traps. Each instance talks to it with a scoped, least-privilege API identity. Alerts are refined in the instance app (topology root-cause, storm suppression, escalation) — raw monitoring noise never reaches a customer directly.

Identity plane — Keycloak single sign-on for staff and (rolling out) tenant users. One login, per-instance entitlements, roles resolved per instance.

Site plane — the node appliance at each customer site: local discovery, monitoring proxy, camera frame capture. Sites connect outbound only over an encrypted overlay network — deploying Reddwatch never requires inbound firewall rules or a site VPN concentrator.

Artifact plane (update.reddwatch.com) — signed release bundles and the version catalog the fleet converges to. Releases are immutable; the signing key never lives on the public host.

The alert pipeline

flowchart LR
    DEV[Site devices] -->|ICMP / SNMP / traps / agents| PRX[Node proxy]
    PRX -->|outbound, encrypted| ZBX[Monitoring plane]
    ZBX -->|problems| APP[Instance app]
    APP --> RCA{Topology<br/>root-cause}
    RCA -->|root alert only| NOTIFY[Email / SMS<br/>+ escalation + on-call]
    RCA -.->|dependents suppressed| LOG[Alert history]
    APP --> STORM[Storm circuit breaker]
    STORM -->|caps floods, sends digest| NOTIFY

The monitoring plane measures; the instance decides. Severity gating keeps engineering-grade telemetry (RF quality trends, hardware pre-failure warnings) on the ops side while clients see clean, actionable outage alerts.

Multi-tenancy model

Layer	Isolation
Portal & API	one instance per integrator; sessions pinned to one instance
Database	one database per instance
Monitoring	per-instance scoped API identity; namespaced host groups
Network	per-instance overlay tags; site nodes isolated between tenants
Billing	per-integrator consolidation; clients see plan + status only

For the full internal detail — hosts, ports, data flows, failure domains — see the low-level architecture (Redd Ash sign-in).