Bridge Best Practices¶

Network Design¶

The Bridge is the single controlled egress point between your internal network and the Zaita SaaS control plane. Design your network topology to reflect this.

Use Bridges as the Sole Egress for Couriers¶

Rather than granting each Courier host direct outbound internet access to the SaaS, route all Courier traffic through a Bridge. Configure your firewall to permit outbound HTTPS only from the Bridge host, and restrict all other hosts to LAN-only communication.

[ Courier hosts ]
       │ HTTPS (internal only)
       ▼
  [ Bridge host ]
       │ HTTPS (outbound, port 443)
       ▼
[ Zaita SaaS control plane ]

This model provides a tighter security perimeter. Certificate operations can be performed across your estate without opening internet access on every host running a Courier.

Restrict Bridge Egress¶

The Bridge only needs outbound HTTPS access (port 443) to the Zaita SaaS endpoint for your region. All other outbound traffic from the Bridge host should be restricted to the target systems it is responsible for reaching (via WinRM or SSH for certificate deployment). Limiting the Bridge's network reach minimises the impact of any compromise.

Do Not Expose Bridges to the Internet¶

Bridges are internal components. The Zaita SaaS initiates no inbound connections to your Bridge — there is no requirement to expose the Bridge host to the internet. The Courier-facing proxy listener on the Bridge should be accessible only within your internal network.

High Availability¶

For production environments, deploy each Bridge with at least two instances to ensure continuity if one becomes unavailable.

Set the instance count when creating the Bridge. Instances can also be added or removed at any time from the Bridge detail page — select Add Instances to scale up, or delete individual instances to scale down. Each instance receives its own independent key pair and registration token and must not share state with other instances.

One instance in the cluster is designated the primary and is the only one that receives job assignments. The remaining instances serve as hot standbys. If the primary stops heartbeating for more than 5 minutes, any other heartbeating instance automatically promotes itself to primary, restoring job execution without manual intervention.

For Docker deployments, run each instance as a separate container with its own persistent data volume.

Segment Bridges by Environment¶

Deploy separate Bridges for distinct network environments — for example, one Bridge per production network segment, one per staging environment, and one per each geographically separate office or data centre. This provides:

Isolation — a compromised Bridge has access only to the network segment it is deployed in.
Clarity — job assignment and certificate deployment are scoped to the Bridge with access to the relevant systems.
Independent revocation — a Bridge can be revoked without affecting other environments.

Protect the Bridge Data Directory¶

The Bridge stores its trust token and asymmetric key pair in its data directory. This directory must be protected:

Restrict read and write access to the Bridge process user only.
Do not back up the data directory — trust tokens and key pairs are ephemeral by design. If a backup is restored, the token may be stale and the Bridge will require re-registration.
For standalone binary deployments, review the file permissions on the data directory after installation.

Keep the Core Binary Updated¶

When the platform raises an alert for a core binary update, apply it promptly. Core updates are infrequent and typically contain security fixes or significant capability improvements. Unlike library updates — which the Bridge manages automatically — core updates require a deliberate deployment action.

Use Descriptive Bridge Names¶

Name each Bridge to clearly reflect its location and scope (for example, Prod — Sydney DC or Staging — EU West). This makes job assignment, monitoring, and incident response significantly easier at scale.

Monitor Bridge Connectivity¶

Set up monitoring on Bridge status alerts from the platform. A disconnected Bridge means jobs assigned to it will not execute, and Couriers relying on it for TLS proxy will be unable to reach the SaaS. Integrate the Zaita SIEM export or monitor the Admin → Bridges view regularly to catch disconnections early.

Do not deploy a single Bridge that spans multiple security zones (for example, one Bridge with network access to both production and development environments). This violates the principle of least privilege and means that a compromise or misconfiguration in one zone could expose the other. Deploy a dedicated Bridge per security zone.