Outbound-only
The bridge agent dials out, so there is no inbound hole to open.
Reach tools in your network with an outbound-only bridge
Govern tools that live inside a customer network without opening inbound holes. A lightweight bridge agent enrolls from inside the network and dials out, so the control plane can dispatch work to connectors on the other side while secrets stay on the customer edge.
The problem
Your team runs tools inside a private network, behind a firewall, or in an air-gapped environment. To govern those tools from a central platform, someone has to open an inbound hole, copy credentials out of the network, or build a one-off tunnel. Each option creates a security problem or gets blocked by the network team before it starts.
The bridge agent dials out, so there is no inbound hole to open.
Credentials live on the customer edge, not in the control plane.
An operator enrolls a bridge, sees it heartbeat, and can revoke it.
Work is routed to connectors across the bridge through a queue.
An agent enrolls from inside the network with a one-time token.
The bridge maintains an outbound connection and heartbeats.
The control plane routes connector work across the bridge.
How it stays governed
Bridge enrollment is controlled by a one-time token, and each bridge is revocable by an operator at any time. Policy as code governs which connectors are reachable through the bridge, so only authorized tools receive dispatched work and an unenrolled bridge stops receiving it immediately.
Each enrollment, heartbeat, and dispatch event writes to a tamper-evident audit trail. Operators can see when a bridge enrolled, confirm it is active, and inspect what work was routed across it, without relying on network logs that may be outside the platform's control.
Works with your stack
Any connector that targets a tool inside a private network can be routed through the bridge, including internal SCMs, CI systems, infrastructure targets, and security scanners.
Who it’s for
Teams running an internal Git server behind a corporate firewall enroll a bridge inside that network. The control plane reaches the repository through the bridge without any inbound rule change on the customer side.
Security tools that run inside the perimeter can receive connector work through the bridge. IntegraCI routes jobs to them and collects results, so findings reach the same governance pipeline as tools hosted in the cloud.
Regulated teams that prohibit inbound internet connections deploy the bridge agent inside the boundary. The agent dials out, so the control plane can dispatch work to internal tools without violating the network policy.
No. The bridge agent dials out from inside the network and holds an outbound connection open. The control plane sends work through that connection, so no inbound rule needs to change on the customer side.
Credentials stay on the customer edge. The bridge agent holds them locally and uses them to run connector work inside the network. They are never transmitted to the control plane.
An enrolled bridge sends regular heartbeats that appear in the platform. If a bridge goes silent, that state is visible. An operator can revoke a bridge at any time, which stops it from receiving dispatched work.
Yes. Each bridge enrolls separately with its own one-time token and operates independently. You can run bridges in different networks or network segments, each carrying connector work for the tools inside that boundary.
Request a demo, or read the docs to see how it fits the tools you already run.