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 run history. Every project starts with a default environment.
Manage environments in Project Settings → 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 optionally link a Git branch to the environment. Otherwise, the environment will use CLI deployments.
| Field | Description |
|---|---|
| Name | A human-readable name for the environment (e.g. Production, Staging, QA) |
| Git Branch | The branch that triggers deployments to this environment. Only available when a Git provider is connected. Pushes to this branch will automatically deploy to this environment. |
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 an automatic deployment to the corresponding environment. This enables workflows like:
Production
mainMerging to main deploys to production automatically
Staging
developPushing to develop deploys to staging for review
You can refresh the available branches from your settings if new branches have been created in the repository.
CLI Deployments
Environments without a Git branch linked use CLI deployments. Copy the 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 automatically 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.
Adding Variables
Add variables one at a time through the form, or use the Raw Editor for bulk operations. When creating a variable, you can select which environments to add it to simultaneously.
| Option | Description |
|---|---|
| Key | Variable name. Must be uppercase, alphanumeric, or underscores (e.g. DATABASE_URL) |
| Value | The variable value. Can be shown or hidden during entry. |
| Sensitive | When enabled, the value is masked in the dashboard after creation. Use for API keys, passwords, and secrets. |
| Environments | Select one or more environments to create the variable in. |
Raw Editor
The raw editor lets you manage variables in KEY=VALUE format. This is useful for importing variables from .env files or making bulk changes.
# Raw editor format (KEY=VALUE)
DATABASE_URL=postgresql://user:pass@host:5432/db
OPENAI_API_KEY=sk-xxxxxxxxxxxx
LOG_LEVEL=info
# Lines starting with # are commentsUsing Variables in Agents
Variables are available in your agent YAML using the ${VAR_NAME} syntax and in your Python tools as environment variables via os.environ. See the Variables docs for full usage details.
Redeployment Required
Changes to environment variables require a redeployment to take effect. The running deployment will continue to use the previous values until a new deployment is triggered.
Dev / Test Environments
Test environments are created for local development with connic test. They can optionally be ephemeral (automatically deleted when the test session ends) or persistent for ongoing development. Test environments are separate from your standard environments.
- Test environments appear in a separate section of the environment selector in the project header
- They do not have a deployments tab (agents are synced live from your machine)
- They have their own set of environment variables
- They are designed for rapid iteration without affecting staging or production
See the Local Testing docs for details on starting test sessions and using dev environments.
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.
Environment Limits
The number of environments you can create depends on your subscription tier. All tiers include at least a production and staging environment. Contact support if you need additional environments beyond your tier limit.