Environments

Deployment-Environments verbinden Git-Branches mit getrennten Workflows für Entwicklung, Staging und Produktivbetrieb. Jedes Environment erhält eigene Variablen.

Überblick

Environments trennen Code, Konfiguration und Daten für Entwicklung, Staging und Produktivbetrieb. Sie können unterschiedliche Agenten und Codeversionen enthalten, etwa wenn ihnen verschiedene Git-Branches zugeordnet sind. Ein typisches Setup verwendet getrennte Environments für Produktivbetrieb und Staging. Beide haben eigene Variablen, eine eigene Deployment-Pipeline und separat aufgezeichnete Runs. Jedes Projekt beginnt mit einem Standard-Environment.

Verwalte Environments unter Projekt-Settings → Git & Environments. Wie viele Environments verfügbar sind, hängt vom Abonnement ab.

Environment erstellen

Klicke auf Create Environment und gib einen Namen ein. Wenn das Projekt mit einem Git-Repository verbunden ist, ordne das Environment einem Git-Branch zu. Andernfalls verwendet das Environment CLI Deployments.

Git-Branch-Zuordnung

Wenn ein Git-Repository mit einem Projekt verbunden ist, kann jedes Environment einem bestimmten Branch zugeordnet werden. Ein Push auf diesen Branch löst ein Deployment in das entsprechende Environment aus. So sind beispielsweise folgende Workflows möglich:

Aktualisiere die Liste der verfügbaren Branches in den Projekt-Settings.

Umgebungsberechtigungen

Öffne unter Projekt-Settings → Git & Environments die Detailansicht einer Umgebung, um ihre Berechtigungsgruppen festzulegen. Für bestehende und neue Umgebungen gilt bei beiden Einstellungen zunächst All groups, bis eine Beschränkung gespeichert wird. Die Auswahl einzelner Gruppen begrenzt den Zugriff auf diese Gruppen; eine leere Auswahl bedeutet Project owners only.

• On-demand deployments legt fest, welche Gruppen Deployments manuell starten dürfen, auch über connic deploy. Bestehende API-Key- und Endpunktberechtigungen gelten weiterhin. Projekteigentümer behalten Zugriff. Bei einer Beschränkung auf ausgewählte Gruppen müssen auch Administratoren einer davon angehören.
• Copy from this env legt fest, welche Gruppen Daten aus dieser Umgebung in eine andere kopieren dürfen. Als Quelle sind nur normale Umgebungen erlaubt; normale und Entwicklungsumgebungen können Kopien erhalten.

Dieselben Gruppenbeschränkungen gelten für manuelle Test-Uploads, Aktualisierungen von Entwicklungssitzungen, das Aktivieren und erneute Bereitstellen von Deployments sowie das Übergehen fehlgeschlagener Deployment-Tests. Automatische Deployments und PR-Workflows über einen verbundenen Git-Branch laufen unabhängig von den Gruppen für manuelle Deployments weiter.

Zwischen Umgebungen kopieren

Retrieval, Database und API Tools bieten jeweils eine Ansicht zum Kopieren. Wähle eine erlaubte normale Quellumgebung und in der Baumansicht die Namespaces, Collections oder API-Spezifikationen aus, die in die aktuelle Umgebung kopiert werden sollen. Diese kann eine normale oder Entwicklungsumgebung sein; sie muss im selben Projekt liegen und sich von der Quelle unterscheiden. Bestehende Ressourcenberechtigungen gelten weiterhin; zum Ersetzen von Variablen oder API Tools ist auch die Berechtigung zum Aktualisieren erforderlich.

Wähle auf der Seite Variables in einer erlaubten normalen Quellumgebung die gewünschten Zeilen aus und anschließend Copy to other envs, um sie in eine oder mehrere andere normale oder Entwicklungsumgebungen desselben Projekts zu kopieren. Database unterstützt einen JSON-Dokumentfilter pro ausgewählter Collection. Retrieval bietet Filter für den Inhaltstyp, einen Teil der Entry-ID und Metadaten.

Mit der Voreinstellung Skip werden bereits vorhandene Einträge im Ziel übersprungen. Replace überschreibt übereinstimmende Einträge. Sensible Variablenwerte und API-Zugangsdaten werden auf dem Server kopiert und bleiben im Browser verborgen. Bei API Tools bleiben konfigurierte Namen, Beschreibungen und die Auswahl aktivierter Tools erhalten.

CLI Deployments

Projekte ohne verbundenes Git-Repository verwenden CLI Deployments. Der Befehl bietet Umgebungen anhand ihres Namens zur Auswahl an und fragt nach einer Bestätigung. Die Ziele lassen sich auch ohne Deployment auflisten:

connic deploy
connic deploy --list
connic deploy --env staging

Für CI/CD sind ein explizites Ziel und die Bestätigung erforderlich: connic deploy --env staging --yes. Environment-IDs werden weiterhin unterstützt. Vollständige CI/CD-Beispiele stehen in der Deployment-Dokumentation.

Standard-Environment

Ein Environment ist immer als default markiert. Das Standard-Environment wird beim Öffnen des Projekt-Dashboards ausgewählt. Bei CLI Deployments ohne --env wird das Ziel interaktiv ausgewählt. Im Menü des Environments lässt sich ein anderes zum Standard machen.

Environment-Variablen

Variablen gelten jeweils nur für ein Environment. Damit lassen sich für Staging und Produktivumgebung unterschiedliche API Keys, Datenbank-URLs oder Feature Flags verwenden. Verwalte Variablen unter Projekt-Settings → Variables.

# Raw-Editor-Format (KEY=VALUE; sensible Keys mit ! markieren)
DATABASE_URL=postgresql://user:pass@host:5432/db
!OPENAI_API_KEY=sk-xxxxxxxxxxxx
LOG_LEVEL=info

# Zeilen, die mit # beginnen, sind Kommentare

import os
import httpx

async def call_external_api(query: str) -> dict:
    """Externe API mit Environment-spezifischen Zugangsdaten aufrufen."""
    api_key = os.environ["EXTERNAL_API_KEY"]
    api_url = os.environ.get("EXTERNAL_API_URL", "https://api.example.com")

    async with httpx.AsyncClient() as client:
        response = await client.post(
            api_url,
            headers={"Authorization": f"Bearer {api_key}"},
            json={"query": query},
        )
        response.raise_for_status()
        return response.json()

import os
from connic import StopProcessing

async def before(content: dict, context: dict) -> dict:
    """Anfragen mit einem privaten Authentifizierungsdienst validieren."""
    auth_url = os.environ.get("AUTH_SERVICE_URL")
    auth_secret = os.environ.get("AUTH_SERVICE_SECRET")

    if not auth_url or not auth_secret:
        raise StopProcessing("Authentifizierungsdienst nicht konfiguriert")

    payload = context.get("payload", {})
    # ... Validierungslogik mit payload, auth_url und auth_secret
    return content

Aufbewahrungsdauer für Logs

Die Einstellung Log retention legt fest, nach welcher Zeit ein Environment Runs automatisch löscht. Öffne unter Settings → Git & Environments die Bearbeitungsansicht eines Environments, um die Dauer festzulegen.

Standardmäßig gilt die Aufbewahrungsdauer des Projekttarifs. Trage einen kürzeren Zeitraum wie 1h, 24h oder 5d ein, wenn das Environment diese Inhalte früher löschen soll. Das Minimum beträgt 1h, das Maximum entspricht der Aufbewahrungsdauer des aktuellen Tarifs. Leere das Feld und speichere, damit wieder die Aufbewahrungsdauer des Tarifs gilt.

Sensible Daten maskieren

connic kann ausgewählte JSON-Feldwerte in aufgezeichneten Inputs, Outputs, Run-Kontexten, Session-States, Tool-Aufrufen, Logs und Traces durch [REDACTED] ersetzen. Damit bleiben etwa Tokens, Passwörter oder Kundendaten in diesen Aufzeichnungen verborgen. Öffne unter Settings → Git & Environments die Bearbeitungsansicht eines Environments und dort das Feld Sensitive data redaction.

Neue Environments starten mit *.password, *.secret, *.token, *.api_key, *.access_token, *.refresh_token, *.client_secret, *.private_key. Die Liste lässt sich anpassen. Bestehende Environments behalten ihre gespeicherte Einstellung.

Trage kommagetrennte JSON-Pfade ein, zum Beispiel user.token, *.password. Jeder Pfad bestimmt ein Feld anhand seines Namens und seiner Position im JSON. Groß- und Kleinschreibung werden unterschieden: token und Token sind verschiedene Felder. Ein leeres Eingabefeld deaktiviert die Maskierung für neue Daten.

Pfade für den Input eines Runs beginnen beim Connector-Payload. Der gespeicherte Run-Kontext enthält eine Kopie dieses Payloads unter payload. Ein Pfad mit führendem *., etwa *.user_token, deckt daher den Input, context["payload"] und ein eigenes context["user_token"] ab.

Die Maskierung erfolgt beim Aufzeichnen neuer Daten. Änderungen an der Einstellung wirken sich nicht auf den bestehenden Verlauf aus. Agenten, Tools und aufrufende Anwendungen erhalten weiterhin die ursprünglichen Input- und Output-Werte.

Ein vorangestelltes *. steht für beliebig viele übergeordnete Ebenen. An anderen Positionen steht * für einen einzelnen Objektschlüssel oder Array-Index. Bei Arrays muss der Pfad den Index oder einen Platzhalter enthalten: items.token erfasst items[0].token nicht. Enthält ein erfasstes Feld ein Objekt oder Array, ersetzt connic dessen gesamten Wert durch [REDACTED].

{
  "token": "root-token",
  "user": {"token": "user-token", "name": "Ada"},
  "items": [{"token": "item-token", "id": 1}],
  "message": "token=user-token"
}

{
  "token": "root-token",
  "user": {"token": "[REDACTED]", "name": "Ada"},
  "items": [{"token": "[REDACTED]", "id": 1}],
  "message": "token=user-token"
}

Dev Environments

Dev Environments bilden die Grundlage für die Entwicklung mit Hot Reload von connic dev. Ohne Argumente fragt der Befehl nach einem kurzen Test, dessen Umgebung beim Beenden gelöscht wird, oder einer wiederverwendbaren benannten Umgebung. Die bevorzugte benannte Umgebung wird in .connic gespeichert und beim nächsten Aufruf zuerst angeboten. Im Environment-Selector werden sie getrennt von Standard-Environments angezeigt.

• In einem eigenen Bereich des Environment-Selectors gruppiert
• Code wird live vom lokalen Rechner synchronisiert; die Deployments-Seite zeigt die laufende Session mit einem Dev session-Badge
• Eigene Environment-Variablen und Verbindungen

Der vollständige Workflow steht in der Dev-Server-Dokumentation.

Separate Testumgebung

Für jedes Standard-Environment gibt es unter Settings → Git & Environments ein optionales Dropdown Test environment. Das Deploy Gate führt die Test Suite vor der Aktivierung des Deployments in diesem Environment aus und verwendet dabei dessen Variablen, Verbindungen und Zugangsdaten.

Ein Environment prod-test mit API Keys für Testsysteme und ohne Produktivverbindungen trennt die produktiven Systeme von der Testsuite für prod.

Wenn das Dropdown leer ist, laufen die Tests im Deploy-Environment selbst.

Zwischen Environments wechseln

Der Environment-Selector im Projekt-Header wechselt zwischen Environments. Das ausgewählte Environment bestimmt die im Dashboard sichtbaren Daten: Agenten, Runs, Verbindungen und Variablen gelten jeweils nur für das aktive Environment.

Im Code deklarierte Verbindungen lassen sich auf ausgewählte Environments beschränken und je Environment mit abweichenden Einstellungen versehen. Siehe Verbindungen im Code.