Skip to main content
The Orchestrator is available as a pre-built container image downloaded from the Maverics Console. You download the image as a .tar archive and load it into your local Docker image store with docker load. This approach works well for development, testing, and production environments where container orchestration is managed outside of Kubernetes.

Load the Container Image

The Console provides a pre-built container image as a .tar archive (maverics-orchestrator.tar). Download it from the Download Orchestrator Software modal inside any Deployment in the Console. Load the image into your local Docker image store:
After loading, the image is available as maverics-orchestrator. Confirm the image was loaded successfully:
Optionally, tag the image for organizational naming or version tracking:

Run the Container

Start the Orchestrator container with port mappings for HTTP traffic and TLS, volume mounts for configuration and certificates, and any required environment variables:
  • -p 8080:8080 — HTTP traffic port
  • -p 9443:9443 — HTTPS/TLS traffic port (health endpoint default)
  • -v — Mounts for configuration and TLS certificates
  • -e — Environment variables for runtime configuration

Volume Mounts

The following volume mounts are recommended for production deployments: Mount configuration and certificate directories as read-only where possible to follow the principle of least privilege:

Environment Variables

Environment variables can be passed to the container individually with -e flags or in bulk using an environment file:
See Environment Variables for the complete list of supported variables.

Docker Compose Example

A docker-compose.yml for running the Orchestrator with persistent configuration and TLS:
Start the service:
Verify the Orchestrator is running:

Stable Deployment Identity

The Orchestrator includes a soid field in every log entry for identifying and correlating logs by instance. By default, each container receives a unique soid because containers have ephemeral machine identities — this is the expected behavior for horizontally scaled deployments where each container is a distinct instance. For singleton deployment scenarios where you want the same soid to persist across container restarts (for example, a single Orchestrator container that gets recreated during updates), mount a stable /etc/machine-id file into the container:
Or in Docker Compose:
See Logging — Deployment Correlation for more on how the soid field is used.

Installation Overview

System requirements, download options, CLI flags, and environment variables

Configuration

Configure the Orchestrator after installation

Getting Started

End-to-end quick-start guide