Connic
Platform

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 a Git repository to your project. Pushing to configured branches automatically triggers deployments.

  • • Automatic on push
  • • Branch-to-environment mapping
  • • Supports GitHub, GitLab, and Bitbucket

CLI Deployments

Deploy using the CLI - locally or in CI/CD pipelines. Perfect for unsupported Git providers or custom workflows.

  • • Works with any Git provider
  • • Use in CI/CD pipelines
  • • Manual control

Git Integration

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

1

Connect Your Repository

  1. Go to Project Settings and open the Git Repository section
  2. Click Connect and select your provider (GitHub, GitLab, or Bitbucket)
  3. Authorize Connic via OAuth to access your repositories
  4. Select the repository containing your agents/, tools/, and middleware/ directories
  5. Connic installs a webhook on the repository to detect pushes automatically
2

Configure Environment Branches

  1. Go to Project Settings and open Environments
  2. For each environment, set the Git Branch that triggers deployments
  3. Pushes to branches that are not mapped to any environment are ignored

For example:

  • Productionmain
  • Stagingdevelop
  • Developmentfeature/* (optional)
3

Push to Deploy

Push changes to your configured branch. Connic automatically detects the push via webhooks and creates a new deployment.

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

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
1

Install the SDK

terminal
pip install connic-composer-sdk
2

Authenticate

Create an API key in Project Settings and authenticate:

terminal
connic login

This creates a .connic file:

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

For CI/CD, use environment variables instead: CONNIC_API_KEY and CONNIC_PROJECT_ID

3

Get Your Environment ID

Go to Project Settings → Environments and copy the environment ID you want to deploy to.

4

Deploy

terminal
# Deploy to default environment
connic deploy

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

The CLI packages your agents/, tools/, middleware/, schemas/, and requirements.txt and uploads them. That includes nested files inside agents/ and tools/ when you choose to organize a larger project that way.

CI/CD Integration

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

.github/workflows/deploy.yml
# 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 }}
.gitlab-ci.yml
# 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

Code is packaged and uploaded to Connic
Container is built with your dependencies
Agents are deployed and become available
Traffic is routed to the new 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"

Rollback a Deployment

If a deployment introduces an issue, you can instantly 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

Activating a previous deployment is instant because it re-uses the existing container. No rebuild is needed. If you also want your Git history to match the active deployment, you can optionally revert the commit:

terminal
# 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.

Investigating a failure:

  1. Open the Deployments tab and click the failed deployment
  2. 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

Ready to deploy!

Use Git integration for supported providers, or the CLI for everything else including CI/CD pipelines.