Skip to main content

Deployment

Server Versioning

Cogni+ allows you to maintain multiple concurrent deployments of the same MCP server, providing powerful workflows for development, testing, and production environments.

Understanding Server Versioning

Each MCP server in Cogni+ can have multiple deployments with different configurations:
  • Environment Separation: Maintain separate deployments for production, staging, and development
  • Version Control: Associate deployments with specific Git commits for traceability
  • Blue/Green Deployments: Run multiple versions simultaneously to enable zero-downtime updates
  • A/B Testing: Deploy variations with different configurations to compare performance
  • Progressive Rollouts: Test new features with a limited audience before full release

Creating Multiple Deployments

To create a new deployment version of your server:

Using the Web Interface

  1. Navigate to your server in the Developer Dashboard
  2. Click the “New Deployment” button
  3. Configure the deployment settings:
    • Name: A descriptive name (e.g., “production”, “staging”, “v2.0”)
    • Environment: The deployment environment (development, staging, production)
    • Git Reference: The commit, branch, or tag to deploy
    • Resources: CPU, memory, and scaling parameters
  4. Click “Create Deployment”

Using the CLI

# Create a new deployment for your server
cogni publish create-deployment \
  --server my-server \
  --name staging \
  --environment staging \
  --git-ref develop \
  --cpu 1 \
  --memory 512Mi

Managing Active Deployments

Only one deployment can be the active default for a server at any time. The active deployment is the one used when clients connect without specifying a version.

Set a Deployment as Active

# Using the CLI
cogni publish set-active --server my-server --deployment production

# Web Interface: Use the "Set as Active" button on your deployment

Connecting to Specific Deployments

Clients can connect to specific deployments by including the deployment name in the connection URL:
// Connect to the default (active) deployment
const transport = createTransport("https://server.cogni.ai/@user/my-server");

// Connect to a specific deployment
const transport = createTransport("https://server.cogni.ai/@user/my-server:staging");

Environment Variables

Each deployment can have its own set of environment variables:

Using the Web Interface

  1. Navigate to your server’s deployment
  2. Click the “Environment Variables” tab
  3. Add or edit variables as needed
  4. Save changes and restart the deployment if required

Using the CLI

# Set environment variables for a deployment
cogni publish set-env \
  --server my-server \
  --deployment staging \
  --env-file .env.staging

# View current environment variables
cogni publish get-env --server my-server --deployment production

Deployment Workflows

Here are some common workflows enabled by server versioning:

Continuous Integration/Deployment

  1. Development: Automatic deployments from your develop branch
  2. Staging: Manual promotion of specific commits to staging
  3. Production: Controlled promotion of verified staging deployments

Feature Testing

  1. Create a separate deployment for a new feature
  2. Test the feature with a limited group of users
  3. Compare performance metrics between versions
  4. Roll out to all users by making it the active deployment

Emergency Rollbacks

If a deployment has issues:
  1. Quickly set a previous stable deployment as active
  2. Users are immediately routed to the stable version
  3. Debug the problematic deployment while maintaining service

Deployment History and Logs

Track the history of your server deployments:
# View deployment history
cogni publish list-deployments --server my-server

# View logs for a specific deployment
cogni publish logs --server my-server --deployment production

Best Practices

  • Semantic Naming: Use clear names that indicate the purpose of each deployment
  • Resource Optimization: Allocate appropriate resources based on expected load
  • Monitoring: Set up alerts for each deployment to catch issues early
  • Documentation: Document configuration differences between environments
  • Automated Testing: Run tests against non-production deployments before promotion