CT-OpsCT-Ops
Home
Getting Started
Architecture
Features
Deployment
GitHub
GitHub
Home
Getting Started
Architecture
Features
Deployment
GitHub
GitHub
  • Introduction
  • Getting Started

    • Installation
    • Configuration
    • Offline Agent Install Bundle
  • Architecture

    • Architecture Overview
    • Agent Architecture
    • Ingest Service
    • Deployment Profiles
  • Features

    • Hosts & Inventory
    • Host Groups
    • Networks
    • Monitoring
    • Certificate Management
    • SSL Certificate Checker
    • Alerts
    • Notifications
    • Reports
    • Terminal
    • Service Accounts & Identity
    • Directory User Lookup
    • Tasks & Runbooks
    • Scheduled Tasks
    • Tags
    • Notes
  • Deployment

    • Docker Compose Deployment
    • Air-Gap Deployment
    • Load Testing
  • Development

    • End-to-end testing
  • Licensing
  • Security

Deployment Profiles

CT-Ops ships with three deployment profiles, each targeting a different scale. All profiles use the same codebase — only the infrastructure backing them changes.


Profile Comparison

ProfileQueueIngest instancesDatabaseSuitable for
singleIn-process (channels + WAL)1PostgreSQL (single node)< 50 hosts, homelab, trial
standardRedpanda (single node)1PostgreSQL (single node)Most organisations
haRedpanda clusterMultiple (behind HAProxy)PostgreSQL primary + replicaHigh availability required

Single Profile

The simplest deployment. Everything runs on one machine in Docker Compose. The queue is implemented with Go channels backed by a write-ahead log — no Redpanda, no separate consumer processes.

docker-compose.single.yml
services:
  db:       # PostgreSQL + TimescaleDB
  web:      # Next.js, includes embedded consumers
  ingest:   # gRPC ingest service

Use when:

  • Evaluating CT-Ops
  • Small infrastructure (< 50 agents)
  • A single point of failure is acceptable

Standard Profile

Adds Redpanda as a single-node message queue. The metrics, alerts, and events consumers run as separate processes. More resilient — the queue buffers data if consumers are temporarily offline.

docker-compose.standard.yml
├── db          (PostgreSQL + TimescaleDB)
├── redpanda    (single node)
├── web         (Next.js)
├── ingest      (gRPC)
├── consumer-metrics
├── consumer-alerts
└── consumer-events

Use when:

  • Running 50–500 agents
  • You want Redpanda's durability guarantees
  • Single machine is still acceptable

HA Profile

Full high-availability configuration. Multiple ingest and web instances behind HAProxy. PostgreSQL primary/replica pair. Redpanda cluster (3 nodes).

docker-compose.ha.yml
├── db-primary        (PostgreSQL + TimescaleDB)
├── db-replica
├── redpanda-1
├── redpanda-2
├── redpanda-3
├── web-1             (Next.js)
├── web-2
├── ingest-1          (gRPC)
├── ingest-2
├── haproxy
├── consumer-metrics
├── consumer-alerts
└── consumer-events

Use when:

  • Running 500+ agents
  • Downtime is not acceptable
  • You need horizontal scaling

Queue Topic Reference

Regardless of which queue implementation is in use, the topics are:

TopicWritten byConsumed by
metrics.rawIngestMetrics consumer
events.rawIngestEvents consumer
alerts.pendingAlerts consumer—
agent.statusIngestEvents consumer

Switching Profiles

Profiles are not currently hot-swappable. To move from single to standard:

  1. Take a PostgreSQL backup: pg_dump ct-ops > backup.sql
  2. docker compose -f docker-compose.single.yml down
  3. docker compose -f docker-compose.standard.yml up -d
  4. Restore the backup if needed

Air-Gap Deployment

All three profiles support fully offline deployment. See Air-Gap Deployment for the bundle and transfer instructions.

Edit this page on GitHub
Last Updated: 4/18/26, 10:33 PM
Contributors: Simon Carr, Claude Sonnet 4.6, Claude Opus 4.7
Prev
Ingest Service