Skip to content
Klutch.sh Docs

Deploying Canopsis

Introduction

Canopsis is an open-source hypervisor for event processing and monitoring. It provides a comprehensive platform for event management, correlation, and remediation, helping organizations manage complex IT infrastructure through intelligent alert aggregation and visualization. Built with scalability in mind, Canopsis processes millions of events from various monitoring sources like Nagios, Zabbix, Prometheus, and custom integrations.

Deploying Canopsis on Klutch.sh provides several key advantages:

  • Automated Infrastructure: Leverage Klutch.sh’s automatic Dockerfile detection for seamless deployments
  • Scalable Architecture: Scale your monitoring infrastructure as your needs grow
  • Persistent Storage: Reliable data persistence for events, metrics, and configuration
  • Secure Environment: Isolated deployment with environment-based secret management
  • CI/CD Ready: Connect your GitHub repository for automatic deployments on code changes

This comprehensive guide covers everything you need to deploy a production-ready Canopsis instance on Klutch.sh, from initial setup to advanced configuration and scaling strategies.

Prerequisites

Before deploying Canopsis on Klutch.sh, ensure you have:

  • A Klutch.sh account (sign up here)
  • A GitHub repository for your Canopsis deployment
  • Basic understanding of Docker and containerization
  • Familiarity with monitoring and event management concepts
  • MongoDB database (required for Canopsis - can be deployed separately on Klutch.sh)
  • RabbitMQ message broker (required for Canopsis - can be deployed separately on Klutch.sh)

Understanding Canopsis Architecture

Canopsis uses a microservices architecture with several key components:

  • MongoDB: Stores events, entities, and application data
  • RabbitMQ: Message broker for event processing pipelines
  • API Server: Provides REST API for event ingestion and management
  • Web UI: Browser-based interface for monitoring and configuration
  • Engines: Background workers for event correlation and processing

When deploying on Klutch.sh, you’ll need to deploy these components and ensure they can communicate properly through environment variables and networking configuration.

1. Prepare Your Canopsis Repository

    1. Create a New Repository

      Create a new GitHub repository for your Canopsis deployment or fork the official Canopsis repository:

      Terminal window
      git clone https://github.com/capensis/canopsis.git
      cd canopsis

    2. Create Project Structure

      Set up your project with a clean directory structure:

      canopsis-klutch/
      ├── Dockerfile
      ├── docker-compose.yml (for local development only)
      ├── .dockerignore
      ├── .gitignore
      ├── README.md
      └── config/
          └── canopsis.conf.example

    3. Configure Git Ignore

      Create a .gitignore file to exclude sensitive and build files:

      # Environment variables
      .env
      *.env
      

      # Logs
      logs/
      *.log
      

      # Data directories
      data/
      mongodb-data/
      rabbitmq-data/
      

      # OS files
      .DS_Store
      Thumbs.db

    4. Document Your Setup

      Create a comprehensive README.md explaining your customizations and deployment steps.

For detailed information on connecting your GitHub repository to Klutch.sh, refer to the Quick Start Guide.

2. Deploy Supporting Services

Canopsis requires MongoDB and RabbitMQ to function. You’ll need to deploy these services first.

    1. Deploy MongoDB

      Create a new app in Klutch.sh for MongoDB:

      • Use the official MongoDB Docker image
      • Configure TCP traffic routing on port 8000
      • Set internal port to 27017 (MongoDB default port)
      • Attach a persistent volume:
        • Mount path: /data/db
        • Size: At least 20GB for production use

      Note the MongoDB connection URL for later configuration.

    2. Deploy RabbitMQ

      Create a new app in Klutch.sh for RabbitMQ:

      • Use the official RabbitMQ Docker image with management plugin: rabbitmq:3-management
      • Configure HTTP traffic for the web UI
      • Configure TCP traffic routing on port 8000 for AMQP
      • Set internal port to 5672 (AMQP default port)
      • Attach a persistent volume:
        • Mount path: /var/lib/rabbitmq
        • Size: At least 10GB

      Note the RabbitMQ connection URL for later configuration.

    3. Verify Service Connectivity

      Ensure both services are running and accessible before proceeding with Canopsis deployment.

3. Create Your Dockerfile

Canopsis requires a custom Dockerfile to configure all components properly. Create a Dockerfile in your repository root:

FROM canopsis/canopsis-core:latest


# Set working directory
WORKDIR /opt/canopsis


# Copy custom configuration files (if any)
# COPY config/canopsis.conf /opt/canopsis/etc/


# Install additional dependencies if needed
# RUN apt-get update && apt-get install -y \
#     your-package-here \
#     && rm -rf /var/lib/apt/lists/*


# Expose the API and Web UI port
EXPOSE 8082


# Set entrypoint
ENTRYPOINT ["/opt/canopsis/bin/canopsis-entrypoint.sh"]
CMD ["webserver"]

Important Notes:

  • Klutch.sh automatically detects the Dockerfile when present in the root directory of your repository
  • The Dockerfile will be used automatically for building your application
  • Customize the Dockerfile based on your specific Canopsis version and requirements
  • Consider using multi-stage builds for optimized image sizes

4. Configure Environment Variables

Canopsis requires several environment variables to connect to MongoDB and RabbitMQ. Configure these in the Klutch.sh dashboard:

    1. Navigate to App Settings

      In the Klutch.sh dashboard at klutch.sh/app, select your Canopsis app and go to the Environment Variables section.

    2. Add Database Configuration

      Set the following environment variables for MongoDB connectivity:

      Terminal window
      CPS_MONGO_URL=mongodb://username:password@your-mongodb-host.klutch.sh:8000/canopsis
      CPS_MONGO_DB=canopsis

    3. Add Message Broker Configuration

      Configure RabbitMQ connection:

      Terminal window
      CPS_AMQP_URL=amqp://username:password@your-rabbitmq-host.klutch.sh:8000//
      CPS_AMQP_VHOST=/

    4. Add Application Settings

      Configure Canopsis-specific settings:

      Terminal window
      CPS_WEBSERVER_ENABLE_CORS=true
      CPS_API_URL=https://your-canopsis-app.klutch.sh
      CPS_TIMEZONE=UTC
      CPS_LOG_LEVEL=info

    5. Add Security Settings

      Set secure credentials (mark these as secrets in Klutch.sh):

      Terminal window
      CPS_ADMIN_USER=admin
      CPS_ADMIN_PASS=your-secure-password-here
      CPS_SECRET_KEY=your-secret-key-min-32-chars-long

    6. Optional: Add Email Configuration

      If you want email notifications:

      Terminal window
      CPS_SMTP_HOST=smtp.your-email-provider.com
      CPS_SMTP_PORT=587
      CPS_SMTP_USER=your-email@domain.com
      CPS_SMTP_PASS=your-email-password
      CPS_SMTP_FROM=canopsis@domain.com

Security Best Practices:

  • Never commit credentials to your Git repository
  • Use Klutch.sh’s built-in secret management to mark sensitive variables
  • Rotate credentials regularly for production deployments
  • Use strong, randomly generated passwords for admin accounts

5. Configure Persistent Storage

Canopsis requires persistent storage for logs, temporary files, and cached data.

    1. Create Persistent Volume

      In the Klutch.sh dashboard, navigate to your Canopsis app’s volume settings.

    2. Add Volume for Application Data

      Configure a persistent volume with:

      • Mount path: /opt/canopsis/var
      • Size: At least 10GB (scale based on your event volume)

      This volume will store:

      • Application logs
      • Temporary processing files
      • Cached data
      • Session information

    3. Add Volume for Configuration (Optional)

      If you have custom configuration files to persist:

      • Mount path: /opt/canopsis/etc
      • Size: 1GB is sufficient

      This allows you to persist configuration changes made through the UI.

    4. Verify Volume Mounts

      After deployment, verify volumes are correctly mounted by checking the application logs in the Klutch.sh dashboard.

Volume Best Practices:

  • Klutch.sh manages volume names automatically - you only specify mount paths and sizes
  • Start with smaller volumes and increase as needed
  • Monitor disk usage through Klutch.sh’s monitoring dashboard
  • Ensure volumes are attached before deploying dependent services

6. Configure Networking and Ports

    1. Select Traffic Type

      In the Klutch.sh app settings, select HTTP as the traffic type since Canopsis primarily serves web traffic through its API and UI.

    2. Set Internal Port

      Configure the internal port to 8082 (Canopsis default web server port). This is where Klutch.sh will route incoming traffic to your container.

    3. Verify Port Configuration

      Ensure your Dockerfile exposes the same port (EXPOSE 8082).

Note: Klutch.sh automatically handles SSL/TLS termination and provides HTTPS endpoints for your deployed application at https://your-app-name.klutch.sh.

7. Deploy to Klutch.sh

    1. Push Your Code to GitHub

      Commit and push your Dockerfile and configuration to your GitHub repository:

      Terminal window
      git add Dockerfile .dockerignore .gitignore README.md
      git commit -m "Add Canopsis deployment configuration"
      git push origin main

    2. Create New App in Klutch.sh

      Navigate to klutch.sh/app and create a new app:

      • Select your GitHub repository
      • Choose the branch to deploy (e.g., main)
      • Klutch.sh will automatically detect your Dockerfile

    3. Configure Build Settings

      Klutch.sh uses Nixpacks for builds, but will automatically use your Dockerfile when detected. No additional build configuration is needed.

    4. Review Configuration

      Verify all settings:

      • Environment variables are set correctly
      • Persistent volumes are attached
      • Port configuration is correct (internal port: 8082, HTTP traffic)
      • MongoDB and RabbitMQ URLs are accessible

    5. Deploy Application

      Click “Create” or “Deploy” to start the build and deployment process.

    6. Monitor Deployment

      Watch the build logs in real-time to ensure successful deployment. The initial build may take 5-10 minutes.

    7. Access Your Application

      Once deployed, access your Canopsis instance at:

      https://your-app-name.klutch.sh

    8. Complete Initial Setup

      Log in with your admin credentials (configured in environment variables) and complete the initial Canopsis setup wizard.

8. Post-Deployment Configuration

After successful deployment, configure Canopsis for your monitoring needs:

    1. Configure Event Sources

      Set up integrations with your monitoring tools:

      • Nagios: Use the Nagios Event Broker Module
      • Prometheus: Configure Alertmanager webhook
      • Zabbix: Use Zabbix media type scripts
      • Custom sources: Use the Canopsis REST API

    2. Create Views and Dashboards

      Build monitoring dashboards:

      • Navigate to the Views section in Canopsis
      • Create custom views for different teams or services
      • Configure widgets to display relevant metrics
      • Set up alarm lists and event timelines

    3. Set Up Alert Rules

      Configure event correlation and alarm rules:

      • Define alarm filters based on event patterns
      • Set up notification rules
      • Configure escalation policies
      • Test alerting workflows

    4. Configure Users and Permissions

      Manage access control:

      • Create user accounts for your team
      • Assign roles and permissions
      • Set up authentication (LDAP, OAuth if needed)
      • Configure user groups

    5. Enable Monitoring and Metrics

      Set up monitoring for the Canopsis instance itself:

      • Monitor application logs in Klutch.sh dashboard
      • Set up health checks (if available)
      • Configure resource alerts
      • Track event processing metrics

9. Production Best Practices

For production deployments, follow these recommendations:

Security Hardening

    1. Use Strong Authentication

      • Enable two-factor authentication if supported
      • Use complex passwords (minimum 16 characters)
      • Implement IP whitelisting for administrative access
      • Regularly rotate credentials

    2. Secure Database Connections

      • Use TLS/SSL for MongoDB connections
      • Implement network segmentation
      • Apply principle of least privilege for database users
      • Enable MongoDB authentication

    3. Protect RabbitMQ

      • Change default RabbitMQ credentials
      • Disable guest user in production
      • Use SSL/TLS for AMQP connections
      • Configure proper virtual host permissions

    4. Implement Access Controls

      • Use Canopsis role-based access control (RBAC)
      • Audit user access regularly
      • Implement session timeout policies
      • Log all administrative actions

Performance Optimization

    1. Scale Resources Appropriately

      Recommended specifications based on event volume:

      • Small deployments (< 1000 events/min): 2 CPU, 4GB RAM
      • Medium deployments (1000-10000 events/min): 4 CPU, 8GB RAM
      • Large deployments (> 10000 events/min): 8+ CPU, 16+ GB RAM

    2. Optimize Database Performance

      • Ensure MongoDB has adequate resources
      • Create appropriate indexes for event queries
      • Implement data retention policies
      • Use MongoDB sharding for very large deployments

    3. Configure Event Processing

      • Tune RabbitMQ queue sizes
      • Adjust worker pool sizes
      • Implement event batching where appropriate
      • Configure event TTL (time-to-live)

    4. Monitor Resource Usage

      Use Klutch.sh monitoring to track:

      • CPU and memory utilization
      • Disk I/O and space usage
      • Network bandwidth
      • Application response times

High Availability

    1. Deploy Multiple Instances

      For critical deployments:

      • Run multiple Canopsis instances behind a load balancer
      • Deploy MongoDB with replica sets
      • Use RabbitMQ clustering
      • Implement automatic failover

    2. Implement Backup Strategy

      • Schedule regular MongoDB backups
      • Backup RabbitMQ configurations
      • Export Canopsis views and configurations
      • Test restore procedures regularly
      • Store backups in separate geographic location

    3. Set Up Monitoring and Alerting

      • Monitor Canopsis availability
      • Set up alerts for service degradation
      • Track event processing lag
      • Monitor dependent services (MongoDB, RabbitMQ)

10. Scaling Your Deployment

As your monitoring needs grow, scale your Canopsis deployment:

Vertical Scaling

    1. Increase App Resources

      In the Klutch.sh dashboard:

      • Navigate to your app settings
      • Increase CPU and memory allocation
      • Restart the application to apply changes

    2. Expand Storage

      • Increase persistent volume sizes as needed
      • Monitor disk usage trends
      • Plan for growth in event data

    3. Optimize Database

      • Upgrade MongoDB instance size
      • Add more RAM for better caching
      • Use faster storage (SSD) for high-throughput scenarios

Horizontal Scaling

    1. Deploy Multiple Workers

      For processing-heavy workloads:

      • Deploy additional Canopsis engine instances
      • Configure workers to connect to the same MongoDB and RabbitMQ
      • Distribute event processing across workers

    2. Load Balance Web Traffic

      • Deploy multiple Canopsis webserver instances
      • Use Klutch.sh load balancing features
      • Implement session affinity if needed

    3. Scale Database Layer

      • Implement MongoDB sharding for massive datasets
      • Use read replicas for query-heavy workloads
      • Consider MongoDB Atlas for managed scaling

11. Monitoring and Maintenance

Maintain your Canopsis deployment with regular monitoring and maintenance:

    1. Monitor Application Health

      Regularly check:

      • Application logs in Klutch.sh dashboard
      • Event processing rates
      • API response times
      • Error rates and patterns

    2. Review Resource Usage

      Track trends for:

      • CPU and memory consumption
      • Disk usage and growth rates
      • Network traffic patterns
      • Database query performance

    3. Perform Regular Maintenance

      Schedule periodic tasks:

      • Clean up old events based on retention policy
      • Optimize database indexes
      • Review and update event correlation rules
      • Update dependencies and security patches

    4. Update Canopsis

      When updates are available:

      • Review release notes for breaking changes
      • Test updates in a staging environment first
      • Backup data before updating production
      • Update your Dockerfile with new version tag
      • Push changes to GitHub to trigger deployment

    5. Audit and Optimize

      Regularly review:

      • User access and permissions
      • Alarm rules and notification settings
      • Dashboard and view configurations
      • Integration configurations and data flows

Troubleshooting Common Issues

Application Won’t Start

Symptoms: Container builds successfully but application fails to start

    1. Check application logs in the Klutch.sh dashboard for error messages

    2. Verify MongoDB connectivity:

      • Ensure MongoDB is running and accessible
      • Check connection string format
      • Verify credentials are correct
      • Test connection from a local machine or another container

    3. Verify RabbitMQ connectivity:

      • Ensure RabbitMQ is running
      • Check AMQP URL format
      • Verify virtual host configuration
      • Test connection using RabbitMQ management UI

    4. Review environment variables:

      • Ensure all required variables are set
      • Check for typos in variable names
      • Verify secret values are not masked incorrectly

    5. Check persistent volumes:

      • Ensure volumes are properly attached
      • Verify mount paths are correct
      • Check volume permissions

Database Connection Errors

Symptoms: “Unable to connect to MongoDB” or “Connection timeout” errors

    1. Verify MongoDB is running:

      Terminal window
      # Check MongoDB app status in Klutch.sh dashboard

    2. Test MongoDB connectivity:

      • Use MongoDB Compass or mongosh to test connection
      • Verify you can connect using the same credentials
      • Check TCP port 8000 is configured correctly

    3. Check connection string format:

      Terminal window
      # Correct format:
      mongodb://username:password@hostname.klutch.sh:8000/database

    4. Verify network connectivity:

      • Ensure MongoDB app is deployed and running
      • Check that both apps are in the same project (if network isolation is enabled)
      • Verify firewall rules allow traffic

    5. Review MongoDB logs:

      • Check for authentication errors
      • Look for connection limit issues
      • Verify database exists

Event Processing Delays

Symptoms: Events take too long to process or queues are backing up

    1. Check RabbitMQ queue status:

      • Access RabbitMQ management UI
      • Check queue depths and processing rates
      • Look for blocked connections

    2. Monitor resource usage:

      • Check CPU and memory usage in Klutch.sh
      • Verify the app isn’t resource-constrained
      • Look for memory leaks in long-running processes

    3. Optimize event processing:

      • Review and optimize correlation rules
      • Increase worker thread counts if supported
      • Implement event filtering to reduce volume
      • Consider scaling horizontally

    4. Check database performance:

      • Review slow query logs in MongoDB
      • Add indexes for frequently queried fields
      • Optimize database queries in correlation rules

    5. Review event volume:

      • Check if event rates exceed capacity
      • Implement rate limiting at event sources
      • Filter out unnecessary events

UI Not Loading or Slow

Symptoms: Web interface doesn’t load, times out, or responds slowly

    1. Verify application is running:

      • Check app status in Klutch.sh dashboard
      • Review application logs for errors
      • Ensure webserver component is running

    2. Check browser console:

      • Open browser developer tools (F12)
      • Look for JavaScript errors
      • Check network tab for failed requests
      • Verify API endpoints are responding

    3. Verify CORS configuration:

      • Ensure CPS_WEBSERVER_ENABLE_CORS is set to true
      • Check CPS_API_URL matches your deployment URL
      • Review CORS-related logs

    4. Test API directly:

      Terminal window
      curl https://your-canopsis-app.klutch.sh/api/v4/health

    5. Clear browser cache and retry

Persistent Data Loss

Symptoms: Data disappears after redeployment or restart

    1. Critical: Verify persistent volumes are attached:

      • Check volume configuration in Klutch.sh dashboard
      • Ensure mount paths are correct
      • Verify volumes weren’t accidentally deleted

    2. Check volume mount paths:

      • /opt/canopsis/var for application data
      • /opt/canopsis/etc for configuration
      • Verify paths in Dockerfile and Klutch.sh settings match

    3. Review deployment logs:

      • Check for volume mounting errors
      • Look for permission issues
      • Verify container has write access to volumes

    4. Restore from backup if necessary:

      • Use MongoDB backup to restore data
      • Re-import Canopsis configurations
      • Rebuild views and dashboards if needed

Local Development with Docker Compose

For local development and testing, you can use Docker Compose before deploying to Klutch.sh:

version: '3.8'


services:
  mongodb:
    image: mongo:6.0
    volumes:
      - mongodb-data:/data/db
    environment:
      MONGO_INITDB_ROOT_USERNAME: canopsis
      MONGO_INITDB_ROOT_PASSWORD: canopsis
    ports:
      - "27017:27017"


  rabbitmq:
    image: rabbitmq:3-management
    volumes:
      - rabbitmq-data:/var/lib/rabbitmq
    environment:
      RABBITMQ_DEFAULT_USER: canopsis
      RABBITMQ_DEFAULT_PASS: canopsis
    ports:
      - "5672:5672"
      - "15672:15672"


  canopsis:
    build: .
    depends_on:
      - mongodb
      - rabbitmq
    environment:
      CPS_MONGO_URL: mongodb://canopsis:canopsis@mongodb:27017/canopsis
      CPS_AMQP_URL: amqp://canopsis:canopsis@rabbitmq:5672//
      CPS_ADMIN_USER: admin
      CPS_ADMIN_PASS: admin
      CPS_SECRET_KEY: your-local-development-secret-key-here
    ports:
      - "8082:8082"
    volumes:
      - canopsis-data:/opt/canopsis/var


volumes:
  mongodb-data:
  rabbitmq-data:
  canopsis-data:

Note: Docker Compose is only for local development. Klutch.sh does not support Docker Compose for deployments - you must deploy each service as a separate app.

Migration from Other Platforms

If you’re migrating an existing Canopsis deployment to Klutch.sh:

    1. Backup Current Deployment

      Before migration, backup all critical data:

      Terminal window
      # MongoDB backup
      mongodump --uri="mongodb://current-host:27017/canopsis" --out=./backup
      

      # Export Canopsis configurations
      # Use Canopsis export tools or API to export views, rules, etc.

    2. Deploy Infrastructure on Klutch.sh

      Follow the deployment steps in this guide to set up:

      • MongoDB instance
      • RabbitMQ instance
      • Canopsis application

    3. Restore Database

      Import your MongoDB backup:

      Terminal window
      mongorestore --uri="mongodb://user:pass@your-mongodb.klutch.sh:8000/canopsis" ./backup

    4. Import Configurations

      • Import views and dashboards through Canopsis UI
      • Reconfigure event sources to point to new instance
      • Update alarm rules and notification settings
      • Test all integrations

    5. Update DNS and Monitoring Sources

      • Point your custom domain to new Klutch.sh deployment
      • Update all monitoring tools to send events to new Canopsis instance
      • Configure webhooks and API integrations

    6. Verify and Test

      • Test all critical workflows
      • Verify event processing
      • Check alarm notifications
      • Validate user access and permissions

    7. Decommission Old Deployment

      After successful migration and testing:

      • Monitor new deployment for stability
      • Keep old deployment as backup for 1-2 weeks
      • Gradually decommission old infrastructure

Advanced Configuration

Custom Event Processors

To add custom event processing logic:

    1. Create Custom Engine

      Develop a custom Canopsis engine:

      custom_engine.py
      from canopsis.engines import Engine
      

      class CustomEngine(Engine):
          def work(self, event):
              # Your custom processing logic
              pass

    2. Update Dockerfile

      FROM canopsis/canopsis-core:latest
      

      COPY custom_engine.py /opt/canopsis/lib/python/custom/
      COPY engine_config.conf /opt/canopsis/etc/engines/
      

      EXPOSE 8082

    3. Deploy Updated Configuration

      Push changes to GitHub and redeploy through Klutch.sh.

Integrating with External Services

Configure Canopsis to integrate with external monitoring and notification services:

  • Prometheus/Alertmanager: Configure webhook to send alerts to Canopsis API
  • Slack: Set up Slack notifications through Canopsis alarm actions
  • PagerDuty: Integrate PagerDuty for on-call management
  • Email: Configure SMTP for email notifications
  • Custom webhooks: Use Canopsis API to send events from custom applications

Cost Optimization

Optimize your Klutch.sh deployment costs:

    1. Right-size Resources

      • Start with minimal resources and scale based on actual usage
      • Monitor resource utilization over time
      • Scale down during off-peak hours if possible

    2. Implement Data Retention

      • Configure event retention policies
      • Archive old events to object storage
      • Clean up processed events regularly
      • Keep only necessary historical data

    3. Optimize Database Queries

      • Add appropriate indexes to MongoDB
      • Use aggregation pipelines efficiently
      • Implement caching where appropriate
      • Optimize alarm correlation rules

    4. Monitor and Adjust

      • Regularly review resource usage in Klutch.sh dashboard
      • Identify and eliminate waste
      • Optimize persistent volume sizes
      • Review and optimize networking costs

Example Production Repository

Here’s a complete repository structure for production deployments:

canopsis-production/
├── Dockerfile
├── .dockerignore
├── .gitignore
├── README.md
├── docker-compose.yml (for local dev only)
├── config/
│   ├── canopsis.conf.example
│   └── alarm_rules.json
├── scripts/
│   ├── backup.sh
│   └── restore.sh
└── docs/
    ├── DEPLOYMENT.md
    └── MAINTENANCE.md

Sample Production Dockerfile:

FROM canopsis/canopsis-core:4.7.0


LABEL maintainer="your-team@company.com"
LABEL description="Production Canopsis deployment for Klutch.sh"


WORKDIR /opt/canopsis


# Copy custom configurations
COPY config/canopsis.conf /opt/canopsis/etc/


# Set production defaults
ENV CPS_LOG_LEVEL=warning \
    CPS_TIMEZONE=UTC


# Health check
HEALTHCHECK --interval=30s --timeout=10s --start-period=60s --retries=3 \
  CMD curl -f http://localhost:8082/api/v4/health || exit 1


EXPOSE 8082


CMD ["webserver"]

Additional Resources

Conclusion

Deploying Canopsis on Klutch.sh provides a robust, scalable platform for enterprise event management and monitoring. With automatic Dockerfile detection, persistent storage, secure environment management, and seamless GitHub integration, you can focus on building effective monitoring strategies rather than managing infrastructure.

Whether you’re monitoring a small application stack or processing millions of events from complex IT infrastructure, Canopsis on Klutch.sh offers the reliability, performance, and scalability you need. The platform’s microservices architecture combined with Klutch.sh’s automated deployment pipeline creates a powerful solution for modern monitoring requirements.

Start deploying your Canopsis instance today and transform how you manage events, correlate alarms, and respond to incidents across your infrastructure. With the comprehensive guide above, you have everything needed to deploy, configure, and scale a production-ready Canopsis monitoring platform.

For additional support or questions, refer to the Canopsis community or Klutch.sh support.