Zum Hauptinhalt springen
Connic

Verbinde deine Agenten
mit privaten Diensten.

Connic Bridge baut aus deinem privaten Netzwerk eine ausgehende Verbindung zu Connic auf. So erreichen deine Agenten interne Datenbanken, S3-Speicher und HTTP-APIs, ohne dass du diese öffentlich erreichbar machen oder eingehende Ports öffnen musst.

Bridge-Dokumentation lesen

Bridges

Production VPC
zuletzt vor 2 Sek. gesehen
Bridge ID
bridge_8f3a2c91d4e6
Im privaten Netzwerk ausführen
docker run -d --name connic-bridge \
  -e BRIDGE_TOKEN=••••••••••••••••
  -e ALLOWED_HOSTS=postgres:5432,kafka:9092 \
  connicorg/bridge:latest

Verbinde dein Netzwerk von innen heraus mit Connic

Der Bridge Agent läuft in deinem privaten Netzwerk und baut eine verschlüsselte Verbindung zu Connic auf. Dafür musst du deine internen Dienste weder öffentlich erreichbar machen noch eingehende Ports öffnen.

Connic Cloud
Hier laufen die Agenten
outbound WSS
WSS · token auth
Bridge Agent
In der privaten VPC
erreicht private Dienste
postgres:5432
kafka:9092
internal HTTP
Keine eingehenden Ports
Keine öffentlichen IPs
Keine Firewall-Löcher

Mach private Dienste für deine Agenten erreichbar

In drei Schritten verbindest du dein Netzwerk mit Connic. Eine Bridge in den Projekteinstellungen und der Bridge Agent als Docker-Container ermöglichen den Zugriff über Verbindungen, eigene Modellanbieter, Tools und Middleware.

1Öffne im Dashboard Projekt Settings › Bridge und wähle Add Bridge. Vergib einen Namen für die Bridge und kopiere den Token. Er wird nur einmal angezeigt.
2Führe den Bridge Agent im privaten Netzwerk aus
terminal
docker run -d --name connic-bridge \
  -e BRIDGE_TOKEN=cbr_your_token_here \
  -e ALLOWED_HOSTS=kafka:9092,postgres:5432 \
  connicorg/bridge:latest
3Rufe einen privaten Dienst aus deinem Tool über diese Adresse auf: <target>.cnc-bridge-<bridge_id>
tools/lookup_order.py
import psycopg

BRIDGE_ID = "abc123"  # aus Projekt Settings > Bridge kopieren

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()

Für Protokolle, die zur Laufzeit neue Endpoints erkennen, etwa Redis Sentinel mit seinem aktuellen Primary, stehen unter Projekt Settings › Bridge exakte oder sichere Regex Destination Routes zur Verfügung. Ist ALLOWED_HOSTS konfiguriert, muss es jeden möglichen host:port-Wert enthalten; ungesetzt oder leer bleiben Ziele unbeschränkt.

Sicherheitsmechanismen im Überblick

So regelt Connic Bridge den Verbindungsaufbau, die Authentifizierung, erlaubte Ziele und die Verschlüsselung.

Nur ausgehend

Die Bridge initiiert die Verbindung. Connic verbindet sich niemals von außen hinein. Im privaten Netzwerk müssen keine eingehenden Ports geöffnet werden.

Eigener Token je Bridge

Jede Bridge besitzt einen eigenen Token, der an ein einzelnes Connic-Projekt gebunden ist. Tokens lassen sich jederzeit im Dashboard rotieren. Ein Projekt kann mehrere Bridges in unterschiedlichen Netzwerken nutzen.

Optionale Allowlist

ALLOWED_HOSTS beschränkt die Bridge auf exakte host:port-Werte. Ungesetzt oder leer bleiben Ziele unbeschränkt. Automatische Routes umgehen niemals eine konfigurierte Allowlist.

TLS während der Übertragung

Der gesamte Datenverkehr zwischen Bridge und Connic Relay wird per WSS (WebSocket over TLS) verschlüsselt.

Häufig gestellte Fragen

Der Bridge Agent läuft als Docker-Container (Image connicorg/bridge:latest) im privaten Netzwerk oder wird über pip (connic-bridge) installiert. BRIDGE_TOKEN enthält den Token, der beim Erstellen der Bridge in den Projekteinstellungen angezeigt wird. ALLOWED_HOSTS kann den Zugriff auf bestimmte host:port-Ziele beschränken. Ohne diese Einstellung ist jedes im Netzwerk erreichbare Ziel erlaubt. Die Dokumentation enthält ein docker-compose-Beispiel.

An vier Stellen, die jeweils separat eingerichtet werden. (1) Verbindungen: Eine Bridge wird im Bereich Network Access ausgewählt. (2) Eigene LLM Provider: Eine Bridge wird unter Projekt Settings > LLM Provider ausgewählt. (3) Eigene Tools, Middlewares, Hooks und Guardrails: Private Dienste werden als <target>.cnc-bridge-<bridge_id> adressiert; automatische Destination Routes unterstützen Protokolle, die Endpoints dynamisch ermitteln. (4) MCP Server: bridge wird am Server-Eintrag im Agent YAML gesetzt.

Apache Kafka (inbound und outbound), AWS SQS (inbound und outbound), PostgreSQL (inbound über LISTEN/NOTIFY), E-Mail/IMAP/SMTP (inbound und outbound), AWS S3 (Dateidownloads) und HTTP Webhook (outbound Callbacks).

Ja. Mehrere Bridges mit jeweils eigenem Token können unterschiedliche Netzwerke oder Environments erreichen. Verbindungen, eigene Modellanbieter und Tools wählen jeweils die passende Bridge aus. Automatische Routen sind auf 32 je Bridge und 256 im gesamten Projekt begrenzt.

Die Bridge baut ausschließlich ausgehende Verbindungen auf. Eingehende Firewall-Regeln sind daher nicht erforderlich. Der Datenverkehr zwischen Bridge und Connic Relay wird per WSS (WebSocket over TLS) verschlüsselt. Jede Bridge authentifiziert sich mit einem eigenen Token. Ist ALLOWED_HOSTS konfiguriert, werden Ziele außerhalb der exakten host:port-Liste abgelehnt. Ohne Einträge sind die Ziele nicht beschränkt.

Eine Bridge erhält Regeln mit exaktem Hostnamen beziehungsweise exakter IP oder sicher verankerte Regex-Regeln, jeweils gebunden an einen TCP-Port. Eine Regex darf eine quantifizierte Zeichenklasse enthalten. Clients wie Redis Sentinel können damit dynamisch erkannte Endpoints routen, ohne den zurückgegebenen Hostnamen zu verändern. Explizite Hostnamen im Format <target>.cnc-bridge-<bridge_id> haben Vorrang; exakte Regeln haben Vorrang vor Regex-Regeln und mehrdeutige Treffer über mehrere Bridges werden sicher abgelehnt. Eine Route wählt eine Bridge aus, umgeht aber niemals eine konfigurierte ALLOWED_HOSTS-Beschränkung.

Die Runtime unterstützt synchrone Standard-Sockets und asyncio-TCP-Verbindungen. Eigene native Resolver, Bibliotheken auf Basis von aiodns und später aus Hintergrundthreads geöffnete Verbindungen werden nicht automatisch geroutet; für diese Fälle steht <target>.cnc-bridge-<bridge_id> zur Verfügung. Automatische Routen erhalten den ursprünglichen TLS-Hostnamen. Bei einem expliziten Magic Hostname muss SNI / server_hostname auf das tatsächliche Ziel gesetzt werden, wenn der Client Zertifikate prüft.