Skip to main content
Connic

Reach private services.
No inbound ports.

An outbound-only tunnel from your VPC to Connic. Agents call internal Postgres, S3, and HTTP APIs. No firewall holes, no public IPs, no compromise.

Start with BasicRead the deep dive
Read the bridge docs

Bridges

Production VPC
last seen 2s ago
Bridge ID
bridge_8f3a2c91d4e6
Run on your network
docker run -d --name connic-bridge \
  -e BRIDGE_TOKEN=••••••••••••••••
  -e ALLOWED_HOSTS=postgres:5432,kafka:9092 \
  connicorg/bridge:latest
The architecture

Every connection starts outbound

The bridge agent runs inside your private network and opens an outbound WebSocket connection (WSS) to the Connic relay. Your private services need no inbound ports, firewall changes, or public IPs.

Connic Cloud
Where your agents run
outbound WSS
WSS · token auth
Bridge Agent
In your VPC
reaches your private services
postgres:5432
kafka:9092
internal HTTP
No inbound ports
No public IPs
No firewall holes
Three steps to a private bridge

From zero to first call

Create a bridge in Project Settings, run a Docker container in your network, and reach private services from any connector, custom LLM provider, tool, or middleware.

1In the dashboard, open Project Settings › Bridge, click Add Bridge, name it, and copy the token (shown once).
2Run the bridge agent inside your private network
terminal
docker run -d --name connic-bridge \
  -e BRIDGE_TOKEN=cbr_your_token_here \
  -e ALLOWED_HOSTS=kafka:9092,postgres:5432 \
  connicorg/bridge:latest
3Reach a private service from a custom tool by addressing it as <target>.cnc-bridge-<bridge_id>
tools/lookup_order.py
import psycopg

BRIDGE_ID = "abc123"  # copy from Project Settings > Bridge

def lookup_order(order_id: str):
    with psycopg.connect(
        host=f"postgres-primary.cnc-bridge-{BRIDGE_ID}",
        port=5432, dbname="orders", user="reader", password="...",
    ) as conn:
        return conn.execute(
            "SELECT data FROM orders WHERE id = %s", (order_id,)
        ).fetchone()

If a protocol discovers new endpoints at runtime, such as Redis Sentinel returning its current master, add exact or safe regex destination routes under Project Settings › Bridge. If ALLOWED_HOSTS is configured, it must include every possible host:port; unset or empty leaves destinations unrestricted.

The security model

What your security team will ask about

Bridges are designed to pass a security review on the first pass. The properties below are the ones reviewers ask about first.

Outbound only

The bridge initiates the connection. Connic never connects in. No inbound ports need to be opened on your network.

Per-bridge tokens

Each bridge has its own token tied to a single Connic project. Rotate tokens any time from the dashboard, and run multiple bridges in different networks for the same project.

Optional allowlist

Set ALLOWED_HOSTS to restrict the bridge to exact host:port values. Unset or empty leaves targets unrestricted. Automatic routes never bypass a configured allowlist.

TLS in transit

All traffic between the bridge and the Connic relay is encrypted via WSS (WebSocket over TLS).

Keep exploring

Testing

Assertions and judges, in CI.

Environments

Per-env config and secrets.

Connectors

Wire agents to your real systems.

Storage

Retrieval, sessions, and database.

Tools

Predefined, custom Python, or MCP.

Observability

Trace every step, every token.

Frequently Asked Questions

Run it as a Docker container (image connicorg/bridge:latest) inside your private network, or install via pip (connic-bridge). Set BRIDGE_TOKEN to the token shown when you create the bridge in Project Settings. ALLOWED_HOSTS is optional: use it to restrict the bridge to exact host:port targets, or leave it unset to allow every network-reachable target. A docker-compose example is in the docs.

Four places, each set up independently. (1) Connectors: pick a bridge in the Network Access section. (2) Custom LLM providers: pick a bridge in Project Settings > LLM Provider. (3) Custom tools, middlewares, hooks, and guardrails: address private services as <target>.cnc-bridge-<bridge_id>, or configure automatic destination routes for protocols that discover endpoints. (4) MCP servers: set bridge on the server entry in your agent YAML.

Apache Kafka (inbound and outbound), AWS SQS (inbound and outbound), PostgreSQL (inbound via LISTEN/NOTIFY), Email/IMAP/SMTP (inbound and outbound), AWS S3 (file downloads), and HTTP Webhook (outbound callbacks).

Yes. You can create multiple bridges, each with its own token, to reach different networks or environments. Connectors, custom LLM providers, and tools each pick which bridge to route through. Automatic routes are limited to 32 per bridge and 256 across the project.

The bridge only makes outbound connections, so no inbound firewall rules are needed. All traffic between the bridge and the Connic relay is encrypted via WSS (WebSocket over TLS). Each bridge authenticates with its own token. When ALLOWED_HOSTS is configured, targets outside that exact host:port list are rejected; unset or empty leaves destinations unrestricted.

Add exact hostname/IP or safe anchored-regex rules to a bridge, each tied to one TCP port. A regex may contain one quantified character class. They let clients such as Redis Sentinel route dynamically discovered endpoints without changing the returned hostname. Explicit .cnc-bridge-<bridge_id> hostnames take priority; exact rules beat regex rules; and ambiguous matches across bridges fail closed. A route selects a bridge but never bypasses a configured ALLOWED_HOSTS restriction.

The runtime covers standard synchronous sockets and asyncio TCP connections. Custom native resolvers, libraries built on aiodns, and connections opened later from background threads aren't auto-routed; use <target>.cnc-bridge-<bridge_id> there. Automatic routes preserve the original TLS hostname. With an explicit magic hostname, configure SNI / server_hostname as the real target when the client verifies certificates.