Deployment
Agents deploy to Connic Cloud through automatic Git-based deployments or the CLI, with deployment tests, build logs, and activation of successful deployments.
On this page
Overview
Connic supports two deployment methods for different workflows:
Git Integration
Connect a Git repository to a project. Pushing to configured branches triggers deployments.
- • Automatic on push
- • Branch-to-environment mapping
- • Supports GitHub, GitLab, and Bitbucket
CLI Deployments
Deploy locally or from a CI/CD pipeline when the Connic project has no connected Git repository.
- • Source can live with any Git provider
- • Use in CI/CD pipelines
- • Target the default or a specific environment
Git Integration
Connect a Git repository for automatic deployments on push. Connic supports GitHub, GitLab, and Bitbucket.
Connect a Repository
Go to Project Settings → Git & Environments
Click Connect and select a provider (GitHub, GitLab, or Bitbucket)
Authorize Connic to access the repositories. GitLab.com uses OAuth; for Self-Managed GitLab 15.5 or later, first add the instance under Account → Git Accounts with a personal access token that has the
apiscope. The GitLab user must be an administrator or have the Maintainer or Owner role on each repository.Select the repository containing the
agents/directory and any supporting project directoriesFor a monorepo, set the Repository root directory to the path containing the Connic SDK project (e.g.
services/agents). Leave empty when the SDK files are at the repo root.Connic installs a webhook on the repository to detect pushes and pull or merge requests
Configure Environment Branches
Open Project Settings → Git & Environments
For each environment, set the Git Branch that triggers deployments
Pushes to branches that are not mapped to any environment are ignored
For example:
- • Production →
main - • Staging →
develop - • Development →
feature/customer-import(optional)
Push to Deploy
Push to the configured branch. Connic detects the push via webhooks and creates a deployment.
terminal# Push to trigger deployment git add . git commit -m "Update agents" git push origin main
PR Testing
For GitHub and GitLab repositories, Connic can run the suite from a pull request or merge request whose source branch is in the connected repository. It reports connic/pr-tests as a commit status. The target branch selects the mapped environment, and a configured test-environment override keeps the run away from production state.
See PR Testing for setup, provider-specific merge checks, rerun behavior, and shared-environment guidance.
CLI Deployments
Use the CLI to deploy from a local machine or CI/CD pipeline when:
- The project has no Git repository connected in Connic
- The deployment starts from a local checkout or CI/CD pipeline
- The source repository uses any Git provider or no provider
Install the SDK
terminalpip install connic-composer-sdkAuthenticate
Run the login command. It opens the dashboard to create an API key, then prompts for the resulting login token:
terminalconnic loginThis creates a
.connicfile:.connic{ "api_key": "cnc_xxxxxxxxxxxx", "project_id": "your-project-uuid" }For CI/CD, use environment variables instead:
CONNIC_API_KEYandCONNIC_PROJECT_IDChoose the Environment
Run
connic deploy --listto see the available targets. Environment names are the primary selector;--envalso accepts an environment ID.Deploy
terminal# Choose an environment by name and confirm connic deploy # List available deployment targets connic deploy --list # Select a target directly, then confirm connic deploy --env stagingWithout flags, the CLI lists environments by name. Select a target, review the deployment summary, and confirm before the CLI uploads files.
The CLI uploads supported files from
agents/,tools/,middleware/,schemas/,guardrails/,hooks/, andtests/, plusrequirements.txt. Nested files are included.
CI/CD Integration
Use the CLI in a CI/CD pipeline when the Connic project has no connected Git repository. The source repository can use any provider. For unattended deployments, pass an explicit --env and --yes.
name: Deploy to Connic
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: pip install connic-composer-sdk
- run: connic deploy --env "$CONNIC_ENV_NAME" --yes
env:
CONNIC_API_KEY: ${{ secrets.CONNIC_API_KEY }}
CONNIC_PROJECT_ID: ${{ secrets.CONNIC_PROJECT_ID }}
CONNIC_ENV_NAME: ${{ secrets.CONNIC_ENV_NAME }}deploy:
stage: deploy
script:
- pip install connic-composer-sdk
- connic deploy --env "$CONNIC_ENV_NAME" --yes
variables:
CONNIC_API_KEY: $CONNIC_API_KEY
CONNIC_PROJECT_ID: $CONNIC_PROJECT_IDSet CONNIC_API_KEY, CONNIC_PROJECT_ID, and CONNIC_ENV_NAME as CI/CD secrets in the provider settings.
What Happens During Deployment
tests/A deployment stopped by the source review is marked Blocked. Connic does not build, test, or activate it. Open the deployment to see instructions for contacting support.
Monitoring Deployments
View deployment status and logs in the Deployments tab:
- See all deployments with status and duration
- Click a deployment to view build logs
- The currently serving deployment is marked "Active"

Test Phase (Deploy Gate)
When a project contains tests/, both Git and CLI deployments build the deployment, run the complete suite, and activate only after every case passes. The deployment detail page shows the live pipeline and per-case results.
See The Deploy Gate for test-environment overrides, result locations, and both ways to skip the gate: --skip-tests for CLI deployments, or Deploy & skip tests for a manual Git deployment from the Deployments page. Automatic Git deployments triggered by a push still run the gate. Use the first-test guide to write the suite itself.
Rollback a Deployment
Activate another successful deployment from the Deployments tab:
Open the Deployments tab and select a successful deployment
Click the Activate button on that deployment
Traffic is routed to the selected deployment without rebuilding it
When a Deployment Fails
When a build fails, the deployment is marked Failed and the active deployment continues serving traffic.
Investigating a failure:
Open the Deployments tab and click the failed deployment
Review the build logs to identify the error
Common failure reasons:
- Missing dependencies in
requirements.txt - Invalid agent YAML syntax (malformed config, missing required fields)
- Python import errors in tools or middleware files