Bridge
Connic Bridges ermöglichen sicheren Zugriff auf private Dienste aus Verbindungen, LLM Providern, MCP Servern, eigenen Tools und Middleware. Eingehende Firewall-Regeln sind dafür nicht erforderlich.
Auf dieser Seite
Was ist die Connic Bridge?
Die Connic Bridge ist ein schlanker Agent, der in einem privaten Netzwerk läuft und einen sicheren ausgehenden Tunnel zur Connic Cloud aufbaut. Verbindungen, eigene LLM Provider, MCP Server, Tools und Middleware können darüber auf Dienste zugreifen, die nur im privaten Netzwerk erreichbar sind.
Da die Bridge ausschließlich ausgehende Verbindungen aufbaut, sind keine eingehenden Firewall-Freigaben nötig. Private Dienste müssen nicht öffentlich im Internet erreichbar sein.
Wann ist eine Bridge erforderlich?
Eine Bridge ist erforderlich, wenn der Ziel-Service:
- sich in einer privaten AWS VPC, GCP VPC oder einem Azure VNet befindet,
- On-Premises hinter einer Unternehmens-Firewall läuft,
- nur über privates DNS oder private IPs erreichbar ist oder
- hinter einer IP-Allowlist liegt, in die Connics IPs nicht aufgenommen werden können.
Öffentlich erreichbare Services (z. B. Managed Kafka in Confluent Cloud oder AWS SQS über einen öffentlichen Endpoint) benötigen die Bridge nicht.
Verbindungsablauf
Privates Netzwerk
Private Services
Kafka, PostgreSQL, SQS, ...
Connic Bridge
Läuft in einer VPC
TLS-verschlüsselt
Connic Cloud
Connic Tunnel Endpoint
relay.connic.co
Verbindungen, LLM Provider,
Tools & Middlewares, MCP Server
Alle erreichen private Services über die Bridge
1. Führe die Connic Bridge als Docker-Container im privaten Netzwerk aus.
2. Die Bridge baut eine ausgehende WSS-Verbindung zu relay.connic.co auf (keine eingehenden Ports erforderlich).
3. Connic leitet Verbindungen für die ausgewählte Bridge an die im privaten Netzwerk laufende Bridge weiter.
4. Ist ALLOWED_HOSTS konfiguriert, prüft die Bridge das Ziel gegen diese Liste. Ohne sie ist jedes aus dem Netzwerk der Bridge erreichbare Ziel erlaubt. Anschließend öffnet die Bridge eine lokale TCP-Verbindung und leitet den Traffic weiter.
5. Die WSS-Verbindung verschlüsselt den Traffic zwischen Bridge und Connic Tunnel Endpoint.
Einrichtung
Bridge erstellen
Öffne Projekt-Settings > Bridge und klicke auf Add Bridge. Gib ihr einen Namen (z. B. „Produktiv-VPC“) und kopiere den angezeigten Token. Er wird nur einmal eingeblendet. Beliebig viele Bridges mit jeweils eigenem Token können verschiedene Netzwerke oder Environments erreichen.
Connic Bridge ausführen
Führe die Bridge im privaten Netzwerk aus. Sie muss sowohl die privaten Services als auch das Internet erreichen können.
Docker:
docker run -d --name connic-bridge \
-e BRIDGE_TOKEN=cbr_your_token_here \
-e ALLOWED_HOSTS=kafka:9092,postgres:5432 \
connicorg/bridge:latestpip:
pip install connic-bridge
connic-bridge \
--token cbr_your_token_here \
--allow kafka:9092 \
--allow postgres:5432Docker Compose:
services:
connic-bridge:
image: connicorg/bridge:latest
restart: always
environment:
BRIDGE_TOKEN: cbr_your_token_here
ALLOWED_HOSTS: kafka:9092,postgres:5432,my-db:5432
LOG_LEVEL: INFOSobald die Bridge online ist, können Verbindungen, LLM Provider, benutzerdefinierter Code und MCP Server die Bridge für ihren Traffic nutzen. Konfiguriere jede Anbindung unabhängig.
Wo Bridges eingesetzt werden
Verbindungen
Wähle beim Erstellen oder Bearbeiten einer Verbindung im Dropdown Bridge im Abschnitt Network Access aus, über welche Bridge ihr Traffic geroutet werden soll. Lass die Einstellung auf None, um ohne Bridge direkt zu verbinden.
Die folgenden Verbindungstypen unterstützen den Zugriff über eine Bridge:
- 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)
- HTTP Webhook (Outbound-Callbacks)
LLM Providers
Öffne für private LLM-Endpoints (vLLM, Ollama, einen LiteLLM-Proxy oder einen beliebigen OpenAI-kompatiblen Server) Projekt-Settings > LLM Provider, erweitere den benutzerdefinierten Provider und wähle im Dropdown Route via Bridge eine Bridge aus. Jeder LLM-Request eines Agenten, der diesen Provider verwendet, wird durch die Bridge getunnelt.
Tools & Middlewares
Projekt-Code – benutzerdefinierte Tools, Middleware, Tool Hooks und benutzerdefinierte Guardrails – kann private Services über einen Bridge-Hostnamen erreichen:
<target>.cnc-bridge-<bridge_id>
Dabei ist target der Hostname des Services im privaten Netzwerk (z. B. postgres-primary, kafka oder billing) und bridge_id wird aus Projekt-Settings > Bridge kopiert. Jede Bridge Card enthält das kopierbare Feld „Custom-tool host“.
Connic routet Verbindungen mit diesem Hostname-Muster über die angegebene Bridge. Standard-Python-Clients wie psycopg, aiokafka, httpx, requests und redis-py können das Muster direkt verwenden:
import psycopg
from aiokafka import AIOKafkaProducer
import httpx
BRIDGE_ID = "abc123" # aus Projekt Settings > Bridge kopieren
async def lookup_order(order_id: str) -> dict:
# Postgres in einer privaten VPC
with psycopg.connect(
host=f"postgres-primary.cnc-bridge-{BRIDGE_ID}",
port=5432, dbname="orders", user="reader", password="...",
) as conn:
row = conn.execute(
"SELECT data FROM orders WHERE id = %s", (order_id,)
).fetchone()
# Privates Kafka-Topic
producer = AIOKafkaProducer(
bootstrap_servers=f"kafka.cnc-bridge-{BRIDGE_ID}:9092"
)
await producer.start()
await producer.send("order-lookups", order_id.encode())
await producer.stop()
# Privater HTTP-Service
r = httpx.get(f"http://billing.cnc-bridge-{BRIDGE_ID}/v1/orders/{order_id}")
return {"row": row, "billing": r.json()}Mit dieser Hilfsfunktion lässt sich der Hostname zusammensetzen:
from connic import bridge_host
host = bridge_host("abc123", "postgres-primary")
# ergibt "postgres-primary.cnc-bridge-abc123"Automatische Routen für erkannte Endpoints
Manche Protokolle verbinden sich zunächst mit einem Service und erhalten für die nächste Verbindung einen anderen Hostnamen oder eine andere IP. Redis Sentinel, Kafka-Metadaten und Datenbank-Clients mit Failover arbeiten häufig so. Wenn sich das Bridge-Suffix nicht an dieses zurückgegebene Ziel anhängen lässt, konfiguriere automatische Routen unter Projekt-Settings > Bridge oder über die authentifizierte API GET/PUT /v1/projects/{project_id}/bridges/{bridge_id}/routes. API Keys benötigen für beide Aktionen bridges.update.
{
"routes": [
{
"match_type": "exact",
"target": "redis-sentinel.internal",
"port": 26379
},
{
"match_type": "regex",
"target": "^redis-[a-z0-9-]+\\.internal$",
"port": 6379
}
]
}- Jede Bridge kann bis zu 32 Routen haben; insgesamt sind in einem Projekt 256 automatische Routen möglich. Jede Route gleicht einen Hostnamen oder eine IP und einen erforderlichen TCP-Port ab.
exactgleicht einen Hostnamen oder eine IP ab.regexakzeptiert eine sichere, verankerte^...$-Teilmenge mit höchstens einer quantifizierten Zeichenklasse, etwa[a-z0-9-]+. Gruppen, Lookarounds, Backreferences, Alternation, geschweifte Klammern, nicht escapte Punkte und breite.*-Muster werden abgelehnt.- Explizite
.cnc-bridge-<bridge_id>-Hostnamen haben Vorrang, gefolgt von exakten Routen und anschließend Regex-Routen. Mehrdeutige Treffer über verschiedene Bridges hinweg werden abgelehnt. - Listen- und Detail-Responses für Bridges enthalten
route_count. Rufe Routendefinitionen über den dafür vorgesehenen Routes Endpoint ab.
Redis-Sentinel-Beispiel
Route den Sentinel-Service auf Port 26379 und die möglichen Master-Hostnamen auf Port 6379. Verwende anschließend die gewöhnlichen Hostnamen in redis-py:
from redis.sentinel import Sentinel
sentinel = Sentinel(
[("redis-sentinel.internal", 26379)],
socket_timeout=1,
)
redis = sentinel.master_for("orders-primary", socket_timeout=1)
# Der von Sentinel zurückgegebene Master-Hostname wird automatisch geroutet.
value = redis.get("health")Routing und Autorisierung sind getrennt. Ist ALLOWED_HOSTS konfiguriert, müssen Sentinel und jeder mögliche Master exakt aufgelistet sein, zum Beispiel ALLOWED_HOSTS=redis-sentinel.internal:26379,redis-1.internal:6379,redis-2.internal:6379. Gibt Sentinel IP-Adressen bekannt, verwende anstelle des obigen Hostname-Musters exakte IP-Routen oder einen eng begrenzten IP-Regex.
- Ist für den Bridge-Agenten
ALLOWED_HOSTSkonfiguriert, muss Host:Port des Ziels in dieser Liste stehen. Ohne Wert oder mit einer leeren Liste ist jedes aus dem Netzwerk der Bridge erreichbare Ziel erlaubt. - Automatische Routen erhalten den ursprünglichen Hostnamen für die TLS-Verifizierung. Bei Verwendung eines expliziten Bridge-Hostnamens wird SNI /
server_hostnameals tatsächliches Ziel konfiguriert, sofern der Client Zertifikate prüft. - Automatisches Routing unterstützt synchrone Standard-Sockets und asyncio-TCP-Verbindungen. Benutzerdefinierte native Resolver, auf
aiodnsbasierende Bibliotheken und später aufgebaute Verbindungen aus Hintergrund-Threads benötigen den expliziten Bridge-Hostnamen.
MCP Server
Private MCP Server, die in einer VPC, On-Premises oder hinter einer Unternehmens-Firewall laufen, werden über das Feld bridge im Server-Eintrag der Agent-YAML erreicht. Connic tunnelt die Streamable-HTTP-Verbindung durch die Bridge und handelt mit dem Server MCP 2026-07-28 oder eine unterstützte frühere Revision aus.
mcp_servers:
- name: internal-mcp
url: http://mcp.internal:8080/mcp
bridge: ${INTERNAL_BRIDGE_ID}Ist für den Bridge-Agenten ALLOWED_HOSTS konfiguriert, muss die Liste Host:Port des MCP Servers enthalten. Weitere Details stehen unter Private MCP Server über eine Bridge.
Konfigurationsreferenz
| Variable | Erforderlich | Beschreibung |
|---|---|---|
BRIDGE_TOKEN | Ja | Bridge-Authentifizierungstoken aus dem Connic Dashboard |
ALLOWED_HOSTS | Nein | Optionale, durch Kommas getrennte Host:Port-Allowlist. Ohne Wert oder mit einer leeren Liste ist jedes über das Netzwerk erreichbare Ziel erlaubt. |
RELAY_URL | Nein | Connic Tunnel Endpoint (Standard: wss://relay.connic.co) |
LOG_LEVEL | Nein | DEBUG, INFO, WARNING oder ERROR (Standard: INFO) |
Sicherheit
- Nur ausgehend – die Bridge akzeptiert nie eingehende Verbindungen. Es müssen keine Ports geöffnet werden.
- Optionale erlaubte Hosts – konfiguriere exakte Host:Port-Werte, um die erreichbaren Ziele der Bridge einzuschränken. Ohne Wert oder mit einer leeren Liste ist jedes aus ihrem Netzwerk verfügbare Ziel erlaubt.
- Token-Authentifizierung – jede Bridge hat einen eigenen Token, der an ein einzelnes Connic-Projekt gebunden ist. Tokens können jederzeit rotiert werden; für dasselbe Projekt lassen sich mehrere Bridges in verschiedenen Netzwerken ausführen.
- TLS-Verschlüsselung – die Kommunikation zwischen Bridge und Connic Tunnel Endpoint verwendet WSS (WebSocket über TLS).
Fehlerbehebung
docker ps) und ausgehenden Internetzugriff hat. Stelle sicher, dass der Token korrekt ist und nicht neu generiert wurde.ALLOWED_HOSTS (oder dem Flag --allow) des Bridge-Containers hinzu und starte ihn neu.docker exec connic-bridge nc -zv kafka 9092).Plattform entdecken
Verbindungsmodi
Für jede Verbindung mit privatem Netzwerkzugriff eine Bridge auswählen
Tools
Bridge-Hostname-Muster in eigenen Tools mit jeder Client-Bibliothek verwenden
Middleware
Private Services auf dieselbe Weise aus Before/After-Middleware erreichen
Deployment
Bridge-Agenten neben produktiven Workloads ausführen