Skip to content

Platform Communication & Mesh Networking ​

plexd communicates with the Plexsphere control plane through four outbound-only HTTPS channels: registration, SSE event streaming, heartbeat, and reconciliation. No inbound ports or public IPs are required on the node side.

Between nodes, plexd forms an encrypted WireGuard mesh for direct peer-to-peer traffic. The control plane coordinates key exchange and peer discovery but never sits in the data path — all mesh traffic flows directly between nodes.

How plexd Communicates with Plexsphere ​

All communication is initiated by the node. The control plane never connects inbound to a node.

Channel Summary ​

ChannelDirectionProtocolFrequencyPurpose
RegistrationNode → CPHTTPS POSTOnceBootstrap identity, receive keys and peers
SSE StreamNode ← CPHTTPS SSEPersistentReal-time peer, policy, action, and key events
HeartbeatNode → CPHTTPS POSTEvery 30sLiveness, status reporting, reconcile/rotate hints
ReconciliationNode → CPHTTPS GETEvery 60sState consistency fallback; pulls the desired-state snapshot and the queued action dispatches
ObservabilityNode → CPHTTPS POSTPeriodicMetrics, logs, and audit event uploads

The SSE stream is the primary real-time channel. Reconciliation acts as a consistency fallback — if an SSE event is missed, the next reconciliation cycle detects and corrects the drift. Action dispatches are the one payload that never rides the event stream at all: they are delivered in the executions block of the reconciliation pull, and the matching action_request event merely pulls the next cycle forward. See Heartbeat Service and Reconciliation for protocol details.

Node Lifecycle ​

A node progresses through four phases from first boot to shutdown.

See Agent Lifecycle for the full startup sequence and shutdown details.

The Encrypted Mesh Network ​

Nodes form a full-mesh WireGuard network in the 10.100.0.0/16 address space. Each node gets a unique /32 mesh IP at registration. The control plane distributes public keys and pre-shared keys but never handles mesh traffic.

Key properties of the mesh:

  • Outbound-only — nodes initiate all connections. No inbound ports required.
  • NAT traversal — nodes behind NAT use STUN to discover their public endpoint and exchange it via the control plane. See NAT Traversal.
  • Relay fallback — when direct P2P is not possible, traffic is relayed through a bridge node. See NAT Relay.
  • Per-peer PSKs — each peer pair has a unique pre-shared key for post-quantum forward secrecy.
  • Network policy — the control plane pushes visibility rules that control which peers can communicate. See Network Policy.

What the Mesh Enables ​

Core Capabilities (all nodes) ​

CapabilityDescriptionReference
P2P CommunicationDirect encrypted WireGuard tunnels between all peersWireGuard Tunnels
NAT TraversalSTUN-based public endpoint discovery and exchangeNAT Traversal
Network PolicyPeer visibility rules enforced via the host firewall (nftables, pf or WFP)Network Policy
Secure TunnelsSSH-based access to services through the meshSecure Access Tunneling
Remote ActionsExecute built-in and hook-based actions dispatched in the state pullRemote Actions & Hooks
ObservabilityMetrics, logs, and audit event forwardingMetrics, Logs, Audit

Bridge-Only Capabilities ​

CapabilityDescriptionReference
NAT RelayUDP relay for peers that cannot establish direct P2PNAT Relay
Public IngressACME certificate management and SNI-based routingPublic Ingress, ACME & SNI
User AccessIntegration with Tailscale, Netbird, or standalone WireGuardUser Access
Site-to-Site VPNConnect partner or customer networks to the meshSite-to-Site VPN

See Also ​