Zum Hauptinhalt springen
connic

Dieselben Agenten in jedem Environment.
Jedes mit eigenen Secrets, Daten und Regeln.

Produktivumgebung, Staging und Dev haben eigene Variablen, Verbindungen und Daten. Jedes Environment kann einem Git-Branch folgen und regelt selbst, wo Tests laufen und wer deployen darf.

Environments

Manage deployment environments linked to git branches.

New Environment
  • ProductionDefaultPR tests
    main
  • StagingPR tests
    develop

Dev Environments

Test environments created via the CLI. These are used for local development and testing.

  • maria-dev
  • test-swift-owl-3c9atemporary

Die Produktivumgebung bekommt die Live-Schlüssel, Staging die Sandbox-Schlüssel.

Jedes Environment hat eigene Variablen. Der Code deiner Agenten bleibt gleich.

Nach dem Speichern verborgen
Alle Werte werden verschlüsselt gespeichert. Sensible Werte maskiert das Dashboard, und die API gibt sie nach dem Speichern nie wieder heraus.
In Tools und Konfiguration lesbar
Python liest os.environ. Agenten-YAML und Verbindungsdateien nutzen Platzhalter wie ${ORDERS_API_TOKEN}.
Gültig ab dem nächsten Deployment
Ein Deployment bekommt seine Werte beim Build, Änderungen greifen also erst nach dem nächsten.

Environment VariablesProduction

Variables injected into your agent containers at runtime.

KeyValue
ORDERS_API_URLhttps://orders.example.com/v2
ORDERS_API_TOKEN••••••••
STRIPE_SECRET_KEY••••••••
REFUND_LIMIT_EUR250
Build output
Injecting ORDERS_API_URL...
Injecting ORDERS_API_TOKEN (sensitive)...
Injecting STRIPE_SECRET_KEY (sensitive)...
Injecting REFUND_LIMIT_EUR...

Eine Verbindungsdatei. Pro Environment anders verdrahtet.

Im environments-Block steht, wo die Verbindung läuft und was sich je Environment ändert.

Overrides je Environment
Ein Eintrag kann Name, Connection, Bridge, Domain und verknüpfte Agenten ersetzen. config wird Schlüssel für Schlüssel zusammengeführt.
Nur dort, wo du sie aufführst
Ohne environments-Block bekommt jedes Environment die Verbindung.
Vor dem Build geprüft
Jedes Deployment löst zuerst Environments, Connections, Bridges und Variablen auf. Stimmt ein Name nicht, scheitert es noch vor dem Build.
connectors/order-events.yaml
type: kafka
mode: inbound
name: Order events
connection: orders-kafka-staging
bridge: staging-cluster
config:
  topic: ${ORDER_EVENTS_TOPIC}
agents:
  - order-desk
environments:
  Staging: {}
  Production:
    connection: orders-kafka-prod
    bridge: prod-cluster
    config:
      group_id: order-desk-prod
Productioncreate: connectors/order-events.yaml (kafka)

Strengere Regeln für die Produktivumgebung.

Die Produktivumgebung kann ihr Deploy Gate in Staging ausführen, jeden Pull Request testen und manuelle Deployments nur Admins erlauben.

Edit Environment
Production

Deployment and testing

Git Branch
main

Changes to this branch will trigger deployments to this environment.

Test environment
Staging

Where the test framework runs tests/ when deploying to this env.

Deploy Gate Tests

Run tests/ before each deployment ships to this environment.

PR Testing

Run tests here for pull requests targeting main.

Permissions

On-demand deployments
Admin

Selected groups can deploy manually, including through connic deploy. Automatic branch deployments and PR tests are unaffected. Project owners retain access.

Copy from this env
Admin

Choose which groups can copy variables, retrieval data, database collections, and API specs from this environment.

Logs and privacy

Log retention
14d

Use durations such as 1h, 24h, or 5d, with a minimum of 1h.

Sensitive data redaction
*.password, *.secret, *.token, *.api_key, *.access_token, *.refresh_token, *.client_secret, *.private_key

Replace selected JSON field values with [REDACTED] in newly recorded run inputs, outputs, logs, and traces.

In Staging vorbereiten. In die Produktivumgebung kopieren.

Retrieval-Namespaces, Datenbank-Collections, API-Specs und Variablen kopierst du Eintrag für Eintrag in ein anderes Environment. Secrets kopiert der Server, im Browser bleiben sie verborgen.

Copy from other env

Copy into Production.

Source environment
Staging
Select namespaces2 selected
  • return-policy
  • shipping-faq
  • draft-promotions
Destination environment
Production
If an item already exists
SkipKeep existing items in the destination.
ReplaceUse the data from the source environment.
CancelCopy

Häufig gestellte Fragen

Basic enthält ein Environment, Developer drei und Pro fünf. Enterprise hat keine feste Grenze. Dev-Environments aus connic dev zählen nicht mit.

Nein. Ohne Git deployst du mit connic deploy --env direkt in ein Environment. Mit Git folgt jedes Environment einem Branch, und Pushes auf Branches ohne Environment werden ignoriert.

Ändere die Variable unter Projekt-Settings → Variables und deploye neu. Ein Deployment bekommt seine Werte beim Build, die aktive Version nutzt also bis zum nächsten Deployment den alten Wert. Im Audit Log siehst du, wer welche Variable geändert hat, geheime Werte bleiben dort maskiert.

Variablen, Verbindungen, Daten der Database, Retrieval-Inhalte, Agent Sessions und aufgezeichnete Runs. Auch Log-Aufbewahrung und Schwärzung sensibler Daten stellst du je Environment ein. Die Produktivumgebung kann also weniger aufbewahren als Staging.

Die Einstellung On-demand deployments legt fest, welche Berechtigungsgruppen manuell deployen dürfen, auch mit connic deploy. Projektinhaber behalten den Zugriff, und Deployments durch einen Push auf den verbundenen Branch laufen unabhängig davon.

Ja. Ein Token-Kostenlimit für ein oder mehrere Environments hält dort wartende Runs vom Start ab, sobald es erreicht ist. Andere Environments laufen weiter, und ein Alert mit demselben Geltungsbereich schickt nur eine Benachrichtigung.