Your Kafka cluster sits in a private VPC. Your Postgres database is locked behind a corporate firewall. Your internal APIs are only reachable via private DNS. None of these services are accessible from the public internet, and for good reason.
But now you want AI agents to react to events from these systems. Process Kafka messages. Listen for database changes. Call internal services. How do you bridge the gap between a cloud-hosted agent platform and infrastructure that was designed to be unreachable?
The Problem With Traditional Approaches
Teams typically reach for one of a few options when connecting cloud services to private infrastructure. Each has significant downsides:
VPN / VPC Peering
Complex to set up, expensive to maintain, and creates a broad network-level connection. A single misconfiguration can expose your entire private network. Every vendor that needs access adds another peering relationship to manage.
IP Allowlisting
Requires exposing services on public IPs. IP ranges change. Cloud platforms use shared egress IPs. You end up maintaining fragile allowlists that break without warning and widen your attack surface.
Expose Services Publicly
The fastest option, and the most dangerous. Putting your Kafka cluster or database on the public internet, even with authentication, dramatically increases your attack surface. Security teams will (rightfully) block this.
What you actually need is a way for the cloud to reach your private services without your private services having to be reachable from the internet. That is exactly what Connic Bridge does.
How Connic Bridge Works
The Connic Bridge is a lightweight agent that runs inside your private network. It makes a single outbound WebSocket connection to the Connic relay. That is it. No inbound ports. No VPN. No public exposure.
When a Connic connector needs to reach a service in your network, the relay routes the request through the already-established tunnel to the bridge, which makes a local TCP connection to the target service on your behalf.
Bridge Agent
A Docker container you deploy inside your VPC. Makes outbound-only connections. Controls which services are reachable via an allowed hosts list.
Bridge Relay
Managed by Connic. Accepts bridge connections, allocates tunnel endpoints, and routes connector traffic to the correct bridge.
TLS Tunnel
All traffic between the bridge and relay is encrypted via WSS (WebSocket over TLS). Traffic flows bidirectionally through the tunnel.
Setup in Three Steps
Getting Bridge running takes about five minutes. There is no complex networking to configure, no certificates to manage, and no firewall rules to change.
Step 1: Generate a Bridge Token
Navigate to Project Settings > Bridge in the Connic dashboard and click Set Up Bridge. Copy the token that appears. It starts with cbr_ and is only shown once.
Step 2: Deploy the Bridge Agent
Run the bridge inside your private network. It needs outbound internet access (to connect to the relay) and local network access (to reach your services).
docker run -d --name connic-bridge \ -e BRIDGE_TOKEN=cbr_your_token_here \ -e ALLOWED_HOSTS=kafka:9092,postgres:5432 \ connicorg/bridge:latest
The ALLOWED_HOSTS variable is a comma-separated list of host:port pairs that the bridge is permitted to connect to. Any request targeting a host not in this list gets rejected. This gives you explicit control over what your bridge can reach.
Prefer Docker Compose? That works too:
services:
connic-bridge:
image: connicorg/bridge:latest
restart: always
environment:
BRIDGE_TOKEN: cbr_your_token_here
ALLOWED_HOSTS: kafka:9092,postgres:5432,my-db:5432Step 3: Enable Bridge on Your Connectors
When creating or editing a connector, enable the Connect via Bridge toggle in the Network Access section. Connic automatically routes that connector's traffic through the bridge tunnel instead of connecting directly.
Bridge access is supported on:
Security by Design
The bridge was designed with a zero-trust mindset. Every layer limits what is possible:
Outbound Only
The bridge initiates all connections. Your firewall rules stay unchanged. Nothing in your network needs to accept inbound traffic from the internet.
Explicit Allowlist
The bridge can only connect to hosts you have explicitly listed. Even if the tunnel were compromised, it cannot reach services outside your allowlist.
Project-Scoped Tokens
Each bridge token is tied to a single Connic project. Tokens can be rotated at any time from the dashboard. Revoking a token immediately disconnects the bridge.
End-to-End TLS
All communication between the bridge and the relay is encrypted via WebSocket over TLS. Traffic is never exposed in plaintext, even in transit.
Real-World Use Cases
Here are some of the patterns we see teams building with Bridge:
Event-Driven AI on Private Kafka
A fintech company runs Kafka inside a private VPC on AWS. They use Bridge to connect a Kafka inbound connector to their transaction topic. Every new transaction triggers an AI agent that performs fraud analysis in real-time, then publishes results back to an output topic via an outbound Kafka connector, also routed through Bridge.
Database Change Detection
An operations team uses PostgreSQL LISTEN/NOTIFY on an on-premises database to detect new support tickets. The Bridge routes the Postgres connector to the internal database. When a new ticket lands, an AI agent classifies it, drafts a response, and routes it to the appropriate team, all without the database ever being exposed publicly.
Internal Email Processing
A logistics company runs an on-premises mail server behind their corporate firewall. Bridge connects the Email connector to the internal IMAP server. An AI agent monitors a shared inbox, extracts shipment details from emails and attachments, and updates their internal tracking system via an outbound HTTP webhook, also routed through Bridge.
Bridge vs. Alternatives
| Connic Bridge | VPN / Peering | IP Allowlist | |
|---|---|---|---|
| Setup time | 5 minutes | Hours to days | Minutes (fragile) |
| Inbound ports required | None | Multiple | Per service |
| Blast radius | Explicit host:port list | Entire VPC / subnet | Per IP range |
| Firewall changes | None | Yes | Yes |
| Ongoing maintenance | Near zero | High | Moderate (IP churn) |
Monitoring Your Bridge
Once deployed, you can check your bridge status at any time in Project Settings > Bridge. The dashboard shows whether the bridge is currently connected, when it last connected, and provides controls to regenerate or revoke the token.
Tip: Token Rotation
Rotate your bridge token periodically as a security best practice. Click Regenerate Token in the dashboard, then update the BRIDGE_TOKEN environment variable in your bridge deployment. The old token is revoked immediately.
Getting Started
If your infrastructure is private, Bridge is the simplest way to connect it to your AI agents. Here is how to get started:
- 1.Open your project in the Connic dashboard and go to Settings > Bridge
- 2.Generate a token and deploy the bridge container in your network
- 3.Enable Connect via Bridge on any connector that targets a private service
- 4.Your agents can now consume events from and deliver results to private infrastructure
For the full configuration reference and troubleshooting guide, check the Bridge documentation. If you are new to Connic, start with the quickstart guide to deploy your first agent, then come back here to connect it to your private infrastructure.