Deployment Guide

Sovereign Workflows runs entirely on your infrastructure. This guide covers the architecture, how to deploy with Docker Compose, and how to harden your deployment for production.

Architecture Overview

The platform consists of application services that handle your workflows and infrastructure services that provide the foundation they run on.

Application Services

Infrastructure Services

How They Communicate

User Browser → Reverse Proxy (port 4723)
                 ├── UI requests → Workflows UI
                 ├── /api/* → Engine API
                 └── /mcp/* → MCP Server

Engine API ──→ RabbitMQ ──→ Executor Worker(s)
     ↑                            │
     └──── results ───────────────┘

The Engine API decides what to run and when. It publishes step execution requests to RabbitMQ. Executor Workers pick up those requests, execute the actions (calling connectors as needed), and report results back. The Engine processes results and dispatches the next steps.

Docker Compose Deployment

Prerequisites

• Docker Engine 24+ and Docker Compose v2
• At least 4 GB RAM available to Docker (8 GB recommended). The full stack uses approximately 2.5 GB at idle with a single Executor Worker.
• Port 4723 available for the reverse proxy

Starting the Stack

Download the deployment files from the Quick Start page, then:

docker compose --profile workflows up -d

This starts all infrastructure services first (PostgreSQL, RabbitMQ, Redis), waits for them to be healthy, then starts the application services.

Service Profiles

Docker Compose profiles control which products to run:

# Workflows product only
docker compose --profile workflows up -d

# Workflows + Orbit (collaboration platform)
docker compose --profile workflows --profile orbit up -d

# Stop services (preserves data)
docker compose --profile workflows down

# Stop and delete all data
docker compose --profile workflows down -v

Infrastructure services (PostgreSQL, RabbitMQ, Redis) start regardless of profile — they are shared by all products.

Monitoring Startup

Check that all services are healthy:

docker compose ps

All containers should show as "healthy" within a few minutes. View logs for a specific service:

docker compose logs engine-api
docker compose logs auth-service

Environment Configuration

Copy .env.example to .env and configure the required values:

Required Settings

Optional Settings

See Configuration Reference for the complete list.

License File

Mount your license file into the containers:

volumes:
  - /path/to/your/license.lic:/app/license.lic:ro
environment:
  - License__FilePath=/app/license.lic
  - License__Issuer=nemorion

See Licensing for details on tiers and installation.

Database Architecture

The platform uses separate database instances for security isolation:

Database migrations run automatically at startup. A dedicated migrator container handles schema setup before the application services start.

Health Checks

Every service exposes health check endpoints for container orchestration:

Docker Compose uses these for dependency ordering — services wait for their dependencies to be healthy before starting. In Kubernetes, use these as liveness and readiness probes.

Scaling

Executor Workers

The Executor Worker is the primary scaling point. Each worker processes one step at a time. To handle more concurrent steps, run more workers:

docker compose --profile workflows up -d --scale executor-worker=4

Four workers handle four concurrent step executions. Scale based on your workload.

Other Services

The Engine API, Auth Service, and MCP Server are stateless and can each run as a single instance for most deployments. The Engine API handles hundreds of dispatches per second in a single instance.

Orbit (Collaboration Platform)

If you are also deploying Orbit, it shares the same infrastructure:

Start Orbit alongside Workflows:

docker compose --profile workflows --profile orbit up -d

Orbit uses the shared PostgreSQL instance (its own orbit database) and the shared Auth Service.

Production Hardening

1. Change all default passwords — generate random values for POSTGRES_PASSWORD, RABBITMQ_PASSWORD, AUTH_POSTGRES_PASSWORD
2. Generate unique service keys — use openssl rand -base64 32 for each service key
3. Enable TLS on the reverse proxy for HTTPS access
4. Switch authentication mode — change from Bypass to Oidc for corporate single sign-on
5. Keep the Auth database isolated — it has no exposed port by default; do not change this
6. Mount a production license — replace the dev license with your purchased license file
7. Set up backups — configure regular PostgreSQL backups for data volumes
8. Configure monitoring — see Monitoring and Health for metrics and alerting
9. Use a key management service — configure Azure Key Vault or HashiCorp Vault for encryption keys

Next Steps

• Configuration Reference — complete environment variable reference
• Authentication Setup — configure your identity provider
• Monitoring and Health — set up monitoring and alerting