Zum Hauptinhalt springen
Connic

Trenne Entwicklung und Produktivbetrieb
direkt in Connic.

Gib jeder Umgebung eigene Variablen, Verbindungen und optionale Budgetlimits. Verbinde Entwicklung, Staging und Produktivbetrieb mit unterschiedlichen Git-Branches, um jeweils die passenden Agenten und Code-Versionen zu deployen.

Environments-Dokumentation lesen

Environment-Variablen

production
SchlüsselWert
  • DATABASE_URLpostgres://••••@db.connic.co/prod
  • STRIPE_SECRET_KEYsk_live_••••••••••••••••••
  • OPENAI_API_KEYsk-••••••••••••••••••••••
  • SENTRY_DSNhttps://••••@o123.sentry.io/4501
  • AWS_S3_BUCKETconnic-prod-uploads
  • WEBHOOK_SIGNING_SECRETwhsec_••••••••••••••••••

Entwickle neue Agenten unabhängig vom Produktivbetrieb

Nutze unterschiedliche Branches, um neue Agenten und Änderungen in einer separaten Umgebung zu testen. Jede Umgebung hat ihren eigenen Code-Stand sowie eigene Variablen, Verbindungen und optionale Budgetlimits.

invoice-processor
staging
DATABASE_URLpostgres://••••@db.staging.connic.co/db
STRIPE_SECRET_KEYsk_test_•••••••••••••••
OPENAI_API_KEYsk-•••••••••••••••
Budget-Limit: 5 $ / Tag
invoice-processor
production
DATABASE_URLpostgres://••••@db.connic.co/prod
STRIPE_SECRET_KEYsk_live_•••••••••••••••
OPENAI_API_KEYsk-•••••••••••••••
Budget-Limit: 500 $ / Tag

Schütze sensible Werte in Dashboard und Logs

Markiere vertrauliche Variablen als sensibel. Connic verbirgt ihre Werte nach dem Erstellen im Dashboard und maskiert sie in Logs. Beim Deployment stellt Connic dem Agenten die Variablen seiner Umgebung bereit.

Verschlüsselt gespeichert

Variablen werden verschlüsselt gespeichert und erst beim Deployment in die Agent Container injiziert.

Nach dem Erstellen maskiert

Eine Variable mit der Kennzeichnung Sensitive wird nach dem Speichern im Dashboard als •••••••• maskiert.

In Logs maskiert

Sensible Werte werden in Logs maskiert. Änderungen an Variablen benötigen ein neues Deployment. Weitere Details stehen in der Variablen-Dokumentation.

agents/research-agent.yaml (snippet)
mcp_servers:
  - name: research-hub
    url: https://mcp.example.com/research
    headers:
      Authorization: "Bearer ${RESEARCH_TOKEN}"
    tools:
      - search_papers
      - fetch_abstract

Nutze ${VAR_NAME} in der YAML-Konfiguration überall dort, wo das Schema einen String akzeptiert, etwa in Headern für MCP-Server oder URLs eigener Modellanbieter. Python-Tools und Middleware lesen die Werte über os.environ. Beim Deployment verwendet Connic die Werte des aktiven Environments.

Veröffentliche Änderungen über deinen Git-Workflow

Verbinde jede Umgebung mit dem passenden Branch. Sobald du Änderungen dorthin pushst, startet Connic das Deployment. So kannst du neue Versionen erst in Staging prüfen und anschließend über den Produktionsbranch bereitstellen.

f3a92c1Hot Reload
durch connic dev
gerade eben
8d4b1e0bereitgestellt
durch Push nach develop
vor 12 Min.
2c7e9a6bereitgestellt
durch Merge nach main
gestern

Verwalte mehr als Umgebungsvariablen

Vergleiche, wie Connic und andere Ansätze die Trennung deiner Umgebungen, den Schutz sensibler Werte und deine Deployments unterstützen.

Verwalte mehr als Umgebungsvariablen
FunktionConnic.env filesHashiCorp VaultDoppler
Geltungsbereich je EnvironmentEnthaltenTeilweiseEnthaltenEnthalten
Verschlüsselt gespeichertEnthaltenNicht enthaltenEnthaltenEnthalten
Sensible Werte in Logs maskiertEnthaltenNicht enthaltenEnthaltenEnthalten
Projekt Audit LogEnthaltenNicht enthaltenEnthaltenTeilweise
Zuordnung von Git-Branch und EnvironmentEnthaltenNicht enthaltenNicht enthaltenNicht enthalten
Mit Verbindungen verknüpftEnthaltenNicht enthaltenNicht enthaltenNicht enthalten
Mit Agentenkonfigurationen verknüpftEnthaltenNicht enthaltenNicht enthaltenNicht enthalten
Budgetlimits je EnvironmentEnthaltenNicht enthaltenNicht enthaltenNicht enthalten
Kein zusätzlicher Dienst zu betreibenEnthaltenEnthaltenNicht enthaltenNicht enthalten

Häufig gestellte Fragen

Basic enthält ein Environment, Developer drei und Pro fünf. Enterprise-Limits werden im Vertrag festgelegt. Der Support hilft, wenn ein Projekt mehr Environments benötigt, als der Plan enthält.

Ja. Environment-Namen werden frei vergeben, zum Beispiel Produktivumgebung, Staging oder QA. Jedes Environment erhält eigene Variablen und Verbindungen und kann eigene Budget Limits haben.

Der Variablenwert wird im Dashboard aktualisiert, bevor ein neues Deployment erfolgt. Änderungen an Variablen greifen erst mit dem nächsten Deployment; das laufende verwendet bis dahin die bisherigen Werte.

Wird eine Variable als Sensitive markiert, erscheint ihr Wert im Dashboard als •••••••• und wird auch in Logs maskiert. Variablen werden verschlüsselt gespeichert und erst beim Deployment in die Agent Container injiziert.

Ja. Projektänderungen wie Variablenänderungen, Deployments und Approval-Entscheidungen werden im Projekt Audit Log erfasst. Es ist unter Projekt Settings → Audit Log verfügbar.

Ja. Verbinde die Produktivumgebung mit produktiven Stripe-, Kafka- und Postgres-Systemen und Staging mit den jeweiligen Sandboxes. Variablen und Verbindungen legst du je Umgebung fest. Über unterschiedliche Git-Branches können auch Agenten und Code-Versionen voneinander abweichen.