Deployment

Deploy your agents to Connic cloud using Git-based automatic deployments or CLI deployments.

Overview

Two ways to deploy your agents

Connic supports two deployment methods depending on your workflow:

Git Integration

Connect your Git repository for automatic deployments on push. Connic supports GitHub, GitLab, and Bitbucket.

# Push to trigger deployment
git add .
git commit -m "Update agents"
git push origin main

PR Testing

Run your test suite against pull-request code before it merges. When a PR opens or its head updates, Connic checks out the head commit, runs the same test pipeline as connic test against the env whose branch matches the PR's base, and reports the result back as a commit status on the PR.

Currently supported on GitHub. Requires a tests/ directory in the repo with at least one YAML test file.

CLI Deployments

Use the CLI to deploy from your local machine or CI/CD pipeline. This is the recommended approach for:

• Git providers not yet integrated (GitLab, Bitbucket, self-hosted)
• CI/CD pipelines where you want full control
• Projects not using Git at all

pip install connic-composer-sdk

connic login

{
  "api_key": "cnc_xxxxxxxxxxxx",
  "project_id": "your-project-uuid"
}

# Deploy to default environment
connic deploy

# Deploy to a specific environment
connic deploy --env <environment-id>

CI/CD Integration

Use the CLI in your CI/CD pipeline to deploy on push, even with Git providers that aren't directly integrated yet.

# Example: GitHub Actions (.github/workflows/deploy.yml)
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_ID
        env:
          CONNIC_API_KEY: ${{ secrets.CONNIC_API_KEY }}
          CONNIC_PROJECT_ID: ${{ secrets.CONNIC_PROJECT_ID }}
          CONNIC_ENV_ID: ${{ secrets.CONNIC_ENV_ID }}

# Example: GitLab CI/CD (.gitlab-ci.yml)
deploy:
  stage: deploy
  script:
    - pip install connic-composer-sdk
    - connic deploy --env $CONNIC_ENV_ID
  variables:
    CONNIC_API_KEY: $CONNIC_API_KEY
    CONNIC_PROJECT_ID: $CONNIC_PROJECT_ID

Set CONNIC_API_KEY, CONNIC_PROJECT_ID, and CONNIC_ENV_ID as CI/CD secrets in your provider's settings.

What Happens During Deployment

Monitoring Deployments

View deployment status, logs, and history 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)

If your project has a tests/ directory, every deploy (CLI or git) runs as a three-step pipeline:

1. Build image: package the project into a runner image.
2. Run tests: spin up a one-shot container from that image, execute every case, capture results.
3. Deploy: only if all cases passed. Otherwise the deployment is marked Failed and nothing ships.

The deployment detail page shows the live pipeline with per-step and per-case status. You can also override which environment runs the tests via Settings → Git & Environments → Test environment, so the gate runs against stub credentials instead of production. Pass --skip-tests on connic deploy to bypass the gate as a hotfix escape hatch (git auto-deploys cannot skip).

See the Testing docs for the YAML format and assertion syntax.

Rollback a Deployment

If a deployment introduces an issue, you can roll back to a previous stable version:

1. Open the Deployments tab and find a prior successful deployment
2. Click the Activate button on that deployment
3. Traffic is re-routed to the selected deployment immediately, without rebuilding

# Roll back by reverting a bad change
git revert <bad-commit-sha>
git push origin main

When a Deployment Fails

When a build fails, the deployment is marked Failed and the currently active deployment continues serving traffic unchanged. Your agents are never interrupted by a broken build.