Network bridges

A network bridge connects two Loopback networks inside the same organization so hosts in different meshes can reach each other without manually duplicating peer lists. Technically, the execution layer extends each host’s peer set with hosts from the other network after bridge creation.

Why bridges exist

Typical scenarios:

• Shared services network plus per-workspace meshes that must still reach a central bastion or artifact registry.
• Migration patterns where old and new workspaces overlap during cutover.
• Compliance segmentation where policy still requires controlled holes between segments rather than one flat mesh.

API behavior (organization scope)

Organization APIs let authorized members:

• List bridges for the organization.
• Create a bridge between two named networks plus a human-readable label.
• Read or delete a bridge by id.

Validation rules:

• Both networks must exist and belong to the same organization as the request.
• Self-bridging is rejected.
• A duplicate bridge between the same pair is rejected.
• Cross-organization bridging is forbidden.

Successful create and delete run asynchronous mesh work so agents pick up new peer relationships.

Operational notes

• Bridges are not a substitute for firewall policy; they expand reachability. Pair bridges with Firewalls when you need default deny.
• After bridge deletion, hosts may need a short interval to converge depending on agent connectivity; the destroy workflow schedules mesh refresh work to drop stale peers.

Related reading

• Networking overview
• WireGuard mesh and agents
• Tenancy and scope
• Technical verification