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.
Connect Your Repository
- Go to Project Settings and open the Git Repository section
- Click Connect and select your provider (GitHub, GitLab, or Bitbucket)
- Authorize Connic via OAuth to access your repositories
- Select the repository containing your
agents/,tools/, andmiddleware/directories - Connic installs a webhook on the repository to detect pushes automatically
Configure Environment Branches
- Go to Project Settings and open 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/*(optional)
Push to Deploy
Push changes to your configured branch. Connic automatically detects the push via webhooks and creates a new deployment.
# Push to trigger deployment
git add .
git commit -m "Update agents"
git push origin mainCLI 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
Install the SDK
pip install connic-composer-sdkAuthenticate
Create an API key in Project Settings and authenticate:
connic loginThis creates a .connic file:
{
"api_key": "cnc_xxxxxxxxxxxx",
"project_id": "your-project-uuid"
}For CI/CD, use environment variables instead: CONNIC_API_KEY and CONNIC_PROJECT_ID
Get Your Environment ID
Go to Project Settings → Environments and copy the environment ID you want to deploy to.
Deploy
# 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.
# 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_IDSet 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"
Rollback a Deployment
If a deployment introduces an issue, you can instantly roll back to a previous stable version:
- Open the Deployments tab and find a prior successful deployment
- Click the Activate button on that deployment
- 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:
# Roll back by reverting a bad change
git revert <bad-commit-sha>
git push origin mainWhen 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:
- 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
Ready to deploy!
Use Git integration for supported providers, or the CLI for everything else including CI/CD pipelines.