Environments

Manage deployment environments, configure Git branch mapping, and scope variables to isolate staging, production, and development workflows.

Overview

Environments let you run the same agent code with different configurations. A typical setup uses separate environments for production and staging, each with its own variables, deployment pipeline, and recorded runs. Every project starts with a default environment.

Manage environments in Project Settings → Git & Environments. The number of environments available depends on your subscription tier.

Creating an Environment

Click Create Environment and provide a name. If your project has a Git repository connected, you can link a Git branch to the environment. Otherwise, the environment will use CLI deployments.

Git Branch Mapping

When a Git repository is connected to your project, each environment can be linked to a specific branch. Pushing to that branch triggers a deployment to the corresponding environment. This enables workflows like:

Refresh the available branch list from your settings.

CLI Deployments

Projects without a connected Git repository use CLI deployments. Copy the target environment ID from the settings page and pass it to the deploy command:

connic deploy --env <environment-id>

This is also the approach for CI/CD pipelines where you want to deploy to specific environments based on your own logic. See the Deployment docs for full CI/CD examples.

Default Environment

One environment is always marked as the default. The default environment is selected when you open the project dashboard and is the target for CLI deployments when no --env flag is specified. You can change the default from the environment's menu.

Environment Variables

Variables are scoped per environment. This lets you use different API keys, database URLs, or feature flags for staging versus production. Manage variables in Project Settings → Variables.

# Raw editor format (KEY=VALUE; prefix sensitive keys with !)
DATABASE_URL=postgresql://user:pass@host:5432/db
!OPENAI_API_KEY=sk-xxxxxxxxxxxx
LOG_LEVEL=info

# Lines starting with # are comments

import os
import httpx

async def call_external_api(query: str) -> dict:
    """Call an external API using environment-scoped credentials."""
    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:
    """Validate requests using a private authentication service."""
    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("Auth service not configured")

    payload = context.get("payload", {})
    # ... validation logic using payload, auth_url, and auth_secret
    return content

Dev Environments

Dev environments back the connic dev hot-reload loop. They can be ephemeral (auto-deleted when the session ends) or named (persistent across sessions). They appear separately from standard environments in the environment selector.

• Grouped in a separate section of the environment selector
• Code is synced live from your machine; the deployments page shows the running session with a Dev session badge
• Their own set of environment variables and connectors

See the Dev Server docs for the full workflow.

Test Environment Override

Each standard environment has an optional Test environment dropdown in Settings → Git & Environments. The deploy gate runs the test suite in this environment's context, using its variables, connectors, and credentials, before activating the deployment.

A prod-test environment with stub API keys and without production connectors keeps those integrations separate from the test suite for prod.

When the dropdown is empty, tests run in the deploy environment itself.

Switching Environments

The environment selector in the project header lets you switch between environments. The selected environment controls which data you see across the dashboard: agents, runs, connectors, and variables are all scoped to the active environment.