BRIDGE // Distributed. Self-aware. Fault-tolerant ingress for dynamic cloud infrastructure

Why BRIDGE exists

The infrastructure changes. How does the network know?

When you have several servers running different services, routing traffic to them is pure friction. Every deployment meant updating a stack of configurations across the board: SSH into the host, edit reverse proxy configs, validate syntax, reload, and hope nothing breaks in transit. Static gateway mappings become stale the moment dynamic containers move.

Worse, healthy infrastructure can still be unreachable. If an ingress bastion crashes, your application backends are running fine, but the outside world is cut off. Human-in-the-loop latency guarantees network downtime during unplanned failures: manual reconfiguration simply cannot keep up with dynamic cloud workloads.

BRIDGE eliminates that friction by making infrastructure aware of itself. A lightweight daemon on each VM watches services spin up and down, forms an encrypted WireGuard mesh, gossips health state, and autonomously elects an edge leader. If a leader or backend dies, traffic reroutes and the ingress hands off in milliseconds without human intervention. It makes a fleet of VMs work like one, bridging the brain so to speak.

What it does

Everything your fleet needs, in one lightweight binary

Autonomous ingress, encrypted overlay, and continuous health monitoring with zero external runtime dependencies.

Routing

Cross-fleet routing

One entry point, multiple servers. Ingress traffic routes point-to-point over WireGuard directly to healthy backends on any VM.

Compatibility

Plugs into your existing stack

Works alongside Traefik, Nginx, or whatever you already run. Choose L7 Direct HTTP, L4 SNI passthrough, or custom reverse proxies.

Integrations

First-class Coolify support

Managed delegation mode pairs directly with your Coolify setup to bridge nodes and route dynamic multi-server deployments seamlessly.

Discovery

Automatic routing table

Watches services spin up and down in real time. Makes every node aware of every service across your fleet, wherever it lives.

Resilience

Automatic cross-VM replication

Critical workloads can replicate to peer nodes on failure, with automatic or manual failback and configurable cooldowns.

Liveness

Self-aware SWIM gossip

Continuous heartbeat detection discovers cluster health (Alive → Suspected → Dead → Recovered), converging in seconds.

Consensus

Autonomous leader election

Bully algorithm with configurable priorities elects one ingress leader. If it dies, another takes over instantly without human latency.

Operations

Dashboard & CLI

Embedded ops console on 127.0.0.1:9090, real-time WebSocket events, JSON API, and a fast CLI over Unix socket.

Architecture // One mind. Different bodies. Same goal.

A daemon on every node, a leader at the edge

A unified control plane running across distinct physical hosts, coordinating public traffic ingress and private workload dispatch.

Clients public traffic

DNS failover / Cloudflare Tunnel

BRIDGE mesh // WireGuard overlay, 10.8.0.0/24

node-01 10.8.0.1 · priority 100 leader · holds tunnel

node-02 10.8.0.2

node-03 10.8.0.3

Every VM runs the same lightweight BRIDGE daemon. Continuous SWIM gossip keeps node state synchronized, while leader election assigns the public ingress. If the active leader dies, another takes over instantly: continuous state, automatic decisions.

Under the hood // Deep-dive architecture

How BRIDGE works: From edge ingress to kernel WireGuard mesh

Cloudflare-grade routing without cloud lock-in. BRIDGE decouples public edge connectivity from private workload routing across multi-cloud or on-prem VMs using a high-throughput data plane and a zero-dependency epidemic control plane.

< 10ms Edge failover reaction & ingress reassignment

RFC 7748 Curve25519 & ChaCha20-Poly1305 encryption

10.8.0.0/24 Kernel-level WireGuard L3 overlay network

SWIM Epidemic failure detector with indirect probing

Zero Centralized brokers, databases, or cloud dependencies

Data Plane RFC 7748 Kernel wg0

Kernel-level WireGuard overlay & deterministic mesh IP allocation

Rather than proxying inter-node traffic through userland sidecars or centralized bastion gateways, BRIDGE creates a native WireGuard network interface (wg0) in the Linux kernel on each node.

Deterministic Subnetting: Nodes bind to predictable virtual IP addresses on the private 10.8.0.0/24 CIDR range (e.g. 10.8.0.1, 10.8.0.2).
Self-Sovereign Cryptography: High-performance Curve25519 keypairs are generated locally on boot or read from config. No external PKI or certificate authority needed.
Point-to-Point UDP Encapsulation: Packets traverse port 51820 directly between node public IPs, authenticated and encrypted via ChaCha20-Poly1305.
Dynamic AllowedIPs Programming: When a peer joins, BRIDGE configures AllowedIPs = [<peer_ip>/32] inside the kernel routing table, preventing route spoofing.

bridge mesh status

# Telemetry from running daemon:
Interface:    wg0
Mesh IP:      10.8.0.1/24
Listen Port:  51820 (UDP)
Public Key:   8fKx92...mQ2yL8=
Peers (2 active):
  node-02:
    Endpoint:    198.51.100.22:51820
    AllowedIPs:  10.8.0.2/32
    Handshake:   18s ago (transfer: 4.2 MB rx / 8.9 MB tx)
  node-03:
    Endpoint:    198.51.100.23:51820
    AllowedIPs:  10.8.0.3/32
    Handshake:   9s ago (transfer: 1.1 MB rx / 1.4 MB tx)

Control Plane SWIM Protocol O(log N)

SWIM epidemic gossip with indirect probing & flap dampening

Fleet liveness is evaluated continuously without central polling or broadcast storms. Nodes use an adapted SWIM failure detector with indirect probing and suspicion timers.

Direct & Indirect Probing: Every period, a node sends a direct UDP ping to a random member. If unanswered within timeout, it dispatches PING-REQ to $k$ random intermediaries to probe the target from alternative network paths.
Four-State Lifecycle: Nodes move through a deterministic state machine: Alive → Suspected → Dead → Recovered.
Epidemic Dissemination: Membership and route state are piggybacked on regular heartbeats, converging across the entire fleet in $O(\log N)$ time.
Flap Dampening: Suspicion timers ensure transient packet loss, route blips, or container GC pauses do not trigger false evictions.

bridge nodes & inspect

# Fleet membership state:
NODE ID   ROLE      STATE     MESH IP    PRIORITY  LAST HEARTBEAT
node-01   Leader    Alive     10.8.0.1   100       local
node-02   Follower  Alive     10.8.0.2   90        142ms ago
node-03   Follower  Alive     10.8.0.3   80        210ms ago

# Gossip failure detector transition:
[SWIM] Target node-03 direct ping timeout (800ms)
[SWIM] Requesting indirect probe via node-02 (k=2)
[SWIM] Indirect probe confirmed healthy: ACK received in 42ms

Control Plane Bully Algorithm Ingress Handoff

Priority-weighted Bully consensus with sub-second ingress handover

Public traffic enters the fleet through exactly one active ingress leader. Leadership is determined by an autonomous bully algorithm weighted by node priority scores.

Deterministic Leadership: Configured priorities (e.g. node-01: 100, node-02: 90) establish ingress seniority. The highest-priority live node claims the leader role.
Term-Based Quorum: Monotonically increasing election terms prevent split-brain scenarios and guarantee that partitioned nodes cannot hijack ingress.
Ingress Tier Handoff: When leadership shifts, the new leader immediately asserts the configured entrypoint: Cloudflare Tunnel activation, Floating IP reallocation via cloud API, or DNS failover updates.
Hitless Step-Down: Operators can trigger leadership handoff gracefully prior to host maintenance via bridge election trigger.

bridge election status

# Consensus state machine:
Current Term:      4
Leader ID:         node-01
Local Node:        node-01 (is_leader = true)
Priority:          100
Active Handoff:    Cloudflare Tunnel (tier 1)
Quorum Consensus:  3/3 nodes in agreement

Peer Priority Matrix:
  node-01: 100 (Active Leader)
  node-02: 90  (Standby Ingress)
  node-03: 80  (Worker Only)

Data Plane L7 Direct HTTP MurmurHash3 Ring

High-throughput L7 direct proxy with consistent hashing & circuit breaking

Built on asynchronous Rust (Tokio & Hyper), the BRIDGE proxy terminates incoming connections and routes traffic with microsecond overhead.

Radix Tree Routing: Incoming HTTP Host headers and TLS SNI extensions are matched against in-memory prefix trees in $O(1)$ operations.
Consistent Hash Ring: Backend instances are mapped on a MurmurHash3 consistent hash ring. Client requests maintain session affinity across rolling container updates.
Zero Middlebox Hops: If the destination container lives on a remote node, the proxy dispatches packets over the WireGuard mesh straight to the remote node's internal loopback port.
Automatic Circuit Breaking: Consecutive backend connection timeouts trigger an immediate circuit trip, redirecting subsequent traffic to healthy peers without client-facing errors.

bridge inspect api.example.com

# Upstream resolution query:
Hostname:      api.example.com
Route Source:  Docker Discovery (container: web-backend)
Mode:          L7 Direct HTTP
Primary Ring:  node-02 (10.8.0.2:8000) [Health: OK, 0.4ms]
Backup Ring:   node-03 (10.8.0.3:8000) [Health: OK, 0.6ms]
TLS Strategy:  Terminate & Forward (Auto-LetsEncrypt / CF-Cert)
Active Conns:  412 streams / 0 errors

Orchestration Docker Socket Coolify Native

Docker discovery & autonomous cross-VM workload replication

BRIDGE turns standalone Docker daemons into an orchestrated fleet without requiring Kubernetes complexity or etcd clusters.

Dynamic Socket Watching: Watches /var/run/docker.sock for container start/die events. Containers with bridge.enable=true labels are automatically broadcast into the fleet routing table.
Native Coolify Delegation: Integrates directly with Coolify multi-server environments. Services deployed anywhere in your fleet become reachable through the unified ingress.
Automated Failover Duplication: Critical workloads can declare standby replicas on peer VMs. If node-02 dies, node-03 starts the container standby automatically and updates the routing table.
Non-Preemptive Failback: When the recovered host returns online, workloads remain on the running replica until intentionally rescheduled, preventing split-brain flap loops.

docker-compose.yml & bridge replicas

# Example service labels:
services:
  app:
    image: myorg/api:v2.1
    labels:
      - "bridge.enable=true"
      - "bridge.domain=api.example.com"
      - "bridge.replicate=true"
      - "bridge.standby=node-03"

# CLI replica telemetry:
SERVICE   ORIGIN   PLACEMENT  STATUS   FAILBACK POLICY
app       node-02  node-03    Standby  Manual (Cooldown: 60s)

Packet pipeline

The life of a request across the BRIDGE fleet

From public ingress termination to WireGuard kernel encapsulation to container response.

STAGE 01

Public Ingress

Client request hits the leader node via Cloudflare Tunnel, DNS failover, or floating Anycast IP.

STAGE 02

Radix Route Match

Leader proxy inspects Host/SNI, looks up destination in memory, and selects target via consistent hash ring.

STAGE 03

Kernel Encapsulation

Packet is routed into wg0 and encapsulated into ChaCha20-Poly1305 UDP frames across 10.8.0.x.

STAGE 04

Zero-Copy Forward

Destination VM kernel decapsulates WireGuard frame and passes packet directly to local container socket.

STAGE 05

Streamed Response

Container response traverses the established bidirectional TCP stream back to the waiting client.

Deployment

Three steps to a self-aware fleet

1. Install the daemon on each VM

One lightweight command installs the single binary, sets up a system user, and configures the systemd unit.

2. Nodes form the mesh & elect a leader

WireGuard links establish, gossip discovers peers in seconds, and the highest-priority live node takes the ingress.

3. Route seamlessly across the fleet

One entry point for multiple servers. As services spin up and down, BRIDGE updates the routing table automatically.

Distributed. Self-aware. Fault-tolerant ingress for dynamic cloud infrastructure.