Skip to main content
Connic

Connect your agents
to private services.

Connic Bridge establishes an outbound connection from your private network to Connic. Your agents can reach internal databases, S3 storage, and HTTP APIs without exposing those services publicly or opening inbound ports.

Read the bridge docs

Bridges

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

Connect your network to Connic from the inside

The Bridge Agent runs in your private network and establishes an encrypted connection to Connic. You don’t need to expose internal services publicly or open inbound ports.

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

Make private services accessible to your agents

Connect your network to Connic in three steps. A bridge in project settings and the Bridge Agent running as a Docker container enable access through connections, custom model providers, tools, and middleware.

  1. Dashboard: Project Settings › Bridge, then Add Bridge. The bridge receives a name, and its token is shown once for copying.

  2. Bridge agent running inside the 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
  3. Private service address for a custom tool: <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()

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

Security controls at a glance

How Connic Bridge handles connection setup, authentication, allowed destinations, and encryption.

Outbound only

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

Per-bridge tokens

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

Optional allowlist

ALLOWED_HOSTS restricts 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).

Frequently Asked Questions

The bridge agent runs as a Docker container (image connicorg/bridge:latest) inside the private network or installs via pip (connic-bridge). BRIDGE_TOKEN takes the token shown when the bridge is created in Project Settings. The optional ALLOWED_HOSTS setting restricts the bridge to exact host:port targets; leaving it unset allows every network-reachable target. A docker-compose example is in the docs.

Four places, each set up independently. (1) Connectors: a bridge is selected in the Network Access section. (2) Custom LLM providers: a bridge is selected in Project Settings > LLM Provider. (3) Custom tools, middlewares, hooks, and guardrails: private services are addressed as <target>.cnc-bridge-<bridge_id>, or automatic destination routes handle protocols that discover endpoints. (4) MCP servers: bridge is set on the server entry in the 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. Multiple bridges, each with a separate token, can reach different networks or environments. Connectors, custom LLM providers, and tools each select 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.

Automatic destination routing uses exact hostname/IP or safe anchored-regex rules on a bridge, each tied to one TCP port. A regex may contain one quantified character class. These rules let clients such as Redis Sentinel route dynamically discovered endpoints without changing the returned hostname. Explicit <target>.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; <target>.cnc-bridge-<bridge_id> handles those cases. Automatic routes preserve the original TLS hostname. With an explicit magic hostname, SNI / server_hostname must point to the real target when the client verifies certificates.