Documentation

Installation & Configuration

Deploying OpsOrch to Kubernetes and configuring it for production.

Prerequisites

•Kubernetes Cluster: v1.20+ (EKS, GKE, AKS, or local).
•Helm 3: Recommended for managing deployments (chart coming soon).
•PostgreSQL (Optional): Use it if you want external persistence for supporting services in your deployment.

1. Deploying OpsOrch Core

The Core service is stateless. It requires configuration for the adapters you wish to enable.

Kubernetes Manifest

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: opsorch-core
  namespace: opsorch
spec:
  replicas: 2
  selector:
    matchLabels:
      app: opsorch-core
  template:
    metadata:
      labels:
        app: opsorch-core
    spec:
      containers:
        - name: core
          image: ghcr.io/opsorch/opsorch-core:latest
          ports:
            - containerPort: 8080
          env:
            # Enable Incident Capability
            - name: OPSORCH_INCIDENT_PROVIDER
              value: "pagerduty"
            - name: OPSORCH_INCIDENT_CONFIG
              valueFrom:
                secretKeyRef:
                  name: opsorch-secrets
                  key: pagerduty-config
            
            # Enable Metrics Capability
            - name: OPSORCH_METRIC_PROVIDER
              value: "datadog"
            - name: OPSORCH_METRIC_CONFIG
              valueFrom:
                secretKeyRef:
                  name: opsorch-secrets
                  key: datadog-config
                  
            # Log Level
            - name: LOG_LEVEL
              value: "info"
---
apiVersion: v1
kind: Service
metadata:
  name: opsorch-core
  namespace: opsorch
spec:
  selector:
    app: opsorch-core
  ports:
    - port: 80
      targetPort: 8080

2. Deploying OpsOrch Console

The Console is a Next.js application that talks to the Core service.

Kubernetes Manifest

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: opsorch-console
  namespace: opsorch
spec:
  replicas: 2
  selector:
    matchLabels:
      app: opsorch-console
  template:
    metadata:
      labels:
        app: opsorch-console
    spec:
      containers:
        - name: console
          image: ghcr.io/opsorch/opsorch-console:latest
          ports:
            - containerPort: 3000
          env:
            # URL to reach OpsOrch Core (ClusterIP service)
            - name: NEXT_PUBLIC_OPSORCH_CORE_URL
              value: "http://opsorch-core.opsorch.svc.cluster.local"
            - name: NEXT_PUBLIC_COPILOT_URL
              value: "http://opsorch-copilot.opsorch.svc.cluster.local"
---
apiVersion: v1
kind: Service
metadata:
  name: opsorch-console
  namespace: opsorch
spec:
  selector:
    app: opsorch-console
  ports:
    - port: 80
      targetPort: 3000

3. Secret Management

Sensitive configuration (API keys, tokens) should be injected via Kubernetes Secrets. OpsOrch expects the _CONFIG environment variables to contain the full JSON payload for the adapter configuration.

Example Secret

yaml

apiVersion: v1
kind: Secret
metadata:
  name: opsorch-secrets
  namespace: opsorch
stringData:
  pagerduty-config: |
    {
      "apiToken": "u+x8...",
      "fromEmail": "admin@example.com"
    }
  datadog-config: |
    {
      "apiKey": "abc123...",
      "appKey": "def456..."
    }

4. Building with Your Adapter Stack

OpsOrch Core is a minimal base image. Every organization adds the adapters they need (Jira, Prometheus, PagerDuty, Elasticsearch, etc.) as plugin binaries. You can build a custom image with your specific adapter stack bundled in.

Example: Building an image with Jira tickets, Prometheus metrics, and PagerDuty incidents:

dockerfile

FROM ghcr.io/opsorch/opsorch-core:v0.2.0
WORKDIR /opt/opsorch

# Add adapter plugins from releases
ADD https://github.com/OpsOrch/opsorch-jira-adapter/releases/download/v0.1.0/ticketplugin-linux-amd64 ./plugins/ticketplugin
ADD https://github.com/OpsOrch/opsorch-prometheus-adapter/releases/download/v0.1.0/metricplugin-linux-amd64 ./plugins/metricplugin
ADD https://github.com/OpsOrch/opsorch-pagerduty-adapter/releases/download/v0.1.5/incidentplugin-linux-amd64 ./plugins/incidentplugin

RUN chmod +x ./plugins/*

ENV OPSORCH_TICKET_PLUGIN=/opt/opsorch/plugins/ticketplugin \
    OPSORCH_METRIC_PLUGIN=/opt/opsorch/plugins/metricplugin \
    OPSORCH_INCIDENT_PLUGIN=/opt/opsorch/plugins/incidentplugin

Then configure each adapter at deployment time via environment variables or Kubernetes Secrets.

→ For complete examples, configuration reference for all adapters, troubleshooting, and production best practices, see: Building with Your Adapter Stack

Environment Variables Reference

Variable	Service	Description
OPSORCH_BEARER_TOKEN	Core	Bearer token required for all API requests
PORT	Core	Port to listen on (default: 8080)
LOG_LEVEL	Core	debug, info, warn, error (default: info)
OPSORCH_*_PROVIDER	Core	Name of the adapter to use (e.g., jira, pagerduty)
OPSORCH_*_CONFIG	Core	JSON configuration for the adapter
NEXT_PUBLIC_OPSORCH_CORE_URL	Console	Publicly accessible URL or internal Cluster URL for Core