Connic

Same agent.
Different environment.

Staging, production, dev. Each with its own variables, connector wiring, and optional budget limits. The agent spec stays the same; the world it runs in changes.

Read the environments docs

Environment variables

production
KeyValue
  • 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_••••••••••••••••••
One spec, two truths

The same agent, in every environment

The agent file is identical across environments. Variables, connector wiring, and budget limits differ. They're scoped per environment, never hard-coded.

invoice-processor
staging
DATABASE_URLpostgres://••••@db.staging.connic.co/db
STRIPE_SECRET_KEYsk_test_•••••••••••••••
OPENAI_API_KEYsk-•••••••••••••••
$5 / day budget limit
invoice-processor
production
DATABASE_URLpostgres://••••@db.connic.co/prod
STRIPE_SECRET_KEYsk_live_•••••••••••••••
OPENAI_API_KEYsk-•••••••••••••••
$500 / day budget limit
Variables and sensitive values

Mark as sensitive, masked in the dashboard and logs

Per-environment variables are injected into your agent containers at deploy time. Mark a variable as sensitive and the value is hidden in the dashboard after creation, and masked in logs.

Stored encrypted

Variables are stored encrypted and only injected into your agent containers at deploy time.

Masked after creation

Mark a variable as Sensitive and the value is masked in the dashboard (shown as ••••••••) once saved.

Masked in logs

Sensitive values are masked in logs. Changes to variables require a redeployment to take effect. See the variables docs.

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

In agent YAML, reference variables with ${VAR_NAME} wherever the schema accepts a string: MCP server headers, custom LLM provider URLs, and similar config fields. In Python tools and middleware, read them via os.environ. Values resolve at deploy time to whatever the active environment has bound.

From keystroke to production

Git branch mapping does the routing

Iterate locally with connic dev; pushing to develop deploys to staging; merging to main deploys to production. Each environment is mapped to a branch, and Connic deploys on push.

f3a92c1hot-reload
by connic dev
just now
8d4b1e0deployed
by push to develop
12 min ago
2c7e9a6deployed
by merge to main
yesterday

Why not just .env files?

What separates Connic environments from the patterns most teams outgrow

Why not just .env files?
FeatureConnic.env filesHashiCorp VaultDoppler
Per-environment scopingIncludedPartialIncludedIncluded
Stored encryptedIncludedNot includedIncludedIncluded
Sensitive values masked in logsIncludedNot includedIncludedIncluded
Project audit logIncludedNot includedIncludedPartial
Git branch → environment mappingIncludedNot includedNot includedNot included
Wired to connectorsIncludedNot includedNot includedNot included
Wired to agent specsIncludedNot includedNot includedNot included
Per-environment budget limitsIncludedNot includedNot includedNot included
No extra service to operateIncludedIncludedNot includedNot included

Frequently Asked Questions

All tiers include at least a production and staging environment. The number available depends on your subscription tier. Contact support if you need more beyond your tier limit.

Yes. Environment names are user-defined (Production, Staging, QA, or anything else). Each gets its own variables, its own connector wiring, and can carry its own budget limits.

Update the variable value in the dashboard, then redeploy. Variable changes only take effect on the next deployment; the running one keeps using the previous values until then.

Mark a variable as Sensitive and the value is masked in the dashboard (shown as ••••••••) and masked in logs. Variables are stored encrypted and only injected into your agent containers at deploy time.

Yes. Project changes (variable edits, deployments, approval decisions) are recorded in the project audit log, accessible from Project Settings → Audit Log.

Yes, that's a primary use case. Production connectors point at production Stripe, Kafka, Postgres; staging connectors point at sandboxes. The agent spec is identical; only the wiring and variables change.