> ## Documentation Index
> Fetch the complete documentation index at: https://docs.strata.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Deploy to Production

By the end of this guide, you will have a production-ready Maverics Orchestrator deployment with environment-specific configuration, health monitoring, and automated restarts.

This guide focuses on production deployment -- not installation. If you have not yet installed the Orchestrator, start with the [installation reference](/reference/orchestrator/installation) for system requirements and platform options. This guide picks up where installation leaves off, covering the production-specific concerns that matter when real users depend on your deployment.

> [!NOTE]
>
> **Console terminology:** In the Maverics Console, Orchestrator instances and
> configuration delivery are managed through **Deployments**. When working directly
> with YAML, configuration is managed as files delivered via the `-config` flag or
> `MAVERICS_CONFIG` environment variable.

## Prerequisites

* **The Orchestrator installed** -- See the [installation reference](/reference/orchestrator/installation) for system requirements and installation methods.
* **A working configuration file** -- You should have a YAML configuration that works in development. See the [configuration reference](/reference/orchestrator/configuration) for config file structure.
* **A target environment** -- Docker, Kubernetes, a Linux/macOS host, or a Windows server where the Orchestrator will run.

## Deploy to Production

**1. Prepare production configuration**

Production configuration differs from development in a few important ways. In development, you might hardcode secrets and use default ports. In production, you want secrets managed externally, environment-specific values injected at runtime, and explicit resource boundaries.

The Orchestrator supports environment variable substitution in YAML configuration -- so you can keep a single config file and vary behavior per environment. For secrets like IdP client credentials and TLS certificates, use an external [secret provider](/reference/orchestrator/configuration/secret-providers) instead of putting values directly in your config file.

Key production configuration concerns:

* **Secrets** -- Use a [secret provider](/reference/orchestrator/configuration/secret-providers) (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) instead of plaintext values
* **External config sources** -- Pull configuration from a [config source](/reference/orchestrator/configuration/config-sources) for centralized management across multiple Orchestrator instances
* **TLS** -- Enable TLS termination at the Orchestrator or ensure your load balancer handles it. See the [Transport Layer Security (TLS) Reference](/reference/orchestrator/tls-security)
* **Logging** -- Set log level to `info` or `warn` for production (not `debug`). See the [Monitor guide](/guides/operations/monitor) for full observability setup

**Console UI**

> [!NOTE]
>
> **Console UI documentation is coming soon.** This section will walk you
> through configuring this component using the Maverics Console's visual
> interface, including step-by-step screenshots and field descriptions.

![Production configuration panel in Maverics Console showing environment variables and secret provider settings](https://mintcdn.com/strataidentity/yo114yy_clZj7p9v/images/placeholder.svg?fit=max\&auto=format\&n=yo114yy_clZj7p9v\&q=85\&s=ea8d2ec72a69d5a8c7955d78abba6a30)

**Configuration**

A minimal production `maverics.yaml` uses environment variable substitution for environment-specific values and secret references for sensitive data:

```yaml maverics.yaml theme={null}
version: "1"

http:
  address: "{{ env.MAVERICS_HTTP_ADDRESS }}"
  tls: "default"

tls:
  "default":
    certFile: "{{ env.TLS_CERT_PATH }}"
    keyFile: "{{ env.TLS_KEY_PATH }}"
    minVersion: "1.2"

logger:
  level: "info"
  jsonOutput: true

health:
  location: "/status"
  heartbeat:
    interval: "60s"

connectors:
  - name: my-idp
    type: oidc
    oauthClientID: "{{ env.OIDC_CLIENT_ID }}"
    oauthClientSecret: <vault.oidc-client-secret>
    oidcWellKnownURL: "{{ env.OIDC_WELL_KNOWN_URL }}"

apps:
  - name: my-app
    type: proxy
    upstream: "{{ env.APP_UPSTREAM_URL }}"
    routePatterns:
      - "{{ env.APP_ROUTE_PATTERN }}"
    policies:
      - location: "/"
        authentication:
          idps: ["my-idp"]
```

Use `{{ env.VAR }}` for values that change between environments (addresses, URLs, non-sensitive IDs). Use `<namespace.key>` for secrets that should be retrieved from a secret provider at runtime.

See [Configuration Reference](/reference/orchestrator/configuration) for complete config file structure.

> [!TIP]
>
> Keep your production configuration in version control -- but use environment variable references for anything sensitive. This way your config file is auditable without exposing secrets.

**2. Configure secret provider**

Secret providers are configured via the `MAVERICS_SECRET_PROVIDER` environment variable or the `-secretProvider` CLI flag -- not in YAML. Only one secret provider may be active at a time.

**Console UI**

> [!NOTE]
>
> **Console UI documentation is coming soon.** This section will walk you
> through configuring this component using the Maverics Console's visual
> interface, including step-by-step screenshots and field descriptions.

![Secret provider configuration in Maverics Console](https://mintcdn.com/strataidentity/yo114yy_clZj7p9v/images/placeholder.svg?fit=max\&auto=format\&n=yo114yy_clZj7p9v\&q=85\&s=ea8d2ec72a69d5a8c7955d78abba6a30)

**Configuration**

> [!NOTE]
>
> Secret providers are configured via environment variable or CLI flag, not in YAML configuration. The examples below show shell commands for setting up each provider type.

```bash theme={null}
# HashiCorp Vault
export MAVERICS_SECRET_PROVIDER="hashivault://vault.example.com:8200/secret/data/maverics?token=<VAULT_TOKEN>"

# AWS Secrets Manager
export MAVERICS_SECRET_PROVIDER="awssecretsmanager://us-east-1"

# Azure Key Vault
export MAVERICS_SECRET_PROVIDER="azurekeyvault://my-vault.vault.azure.net"

# Secret File (development only)
export MAVERICS_SECRET_PROVIDER="secretfile:////etc/maverics/secrets.json"
```

Once configured, reference secrets in YAML using angle bracket syntax:

```yaml theme={null}
oauthClientSecret: <maverics.client-secret>
```

See [Secret Providers Reference](/reference/orchestrator/configuration/secret-providers) for all 7 provider types and their URL schemes.

**3. Deploy to your target environment**

The Orchestrator is small and lightweight -- it deploys almost anywhere. Choose the deployment model that matches your infrastructure.

**Docker deployment** is the simplest path to production. Mount your configuration file and any TLS certificates, expose the Orchestrator's listening port, and set environment variables for secrets.

**Kubernetes deployment** is ideal for teams already running workloads on Kubernetes. The Orchestrator runs as a Deployment with a Service, and you configure it through ConfigMaps (for YAML configuration) and Secrets (for credentials). Kubernetes also gives you built-in health check integration, rolling updates, and automatic restarts. Strata provides an [official Helm chart](https://github.com/strata-io/helm-charts) for streamlined Kubernetes installation.

**Windows deployment** is supported via the MSI installer, which registers the Orchestrator as a Windows service with automatic startup. The installer provides a guided setup for configuration source, TLS certificates, and environment variables.

**Console UI**

> [!NOTE]
>
> **Console UI documentation is coming soon.** This section will walk you
> through configuring this component using the Maverics Console's visual
> interface, including step-by-step screenshots and field descriptions.

![Deployment wizard in Maverics Console showing Docker and Kubernetes deployment options](https://mintcdn.com/strataidentity/yo114yy_clZj7p9v/images/placeholder.svg?fit=max\&auto=format\&n=yo114yy_clZj7p9v\&q=85\&s=ea8d2ec72a69d5a8c7955d78abba6a30)

**Configuration**

**CLI invocation** -- The Orchestrator accepts the following flags:

```bash theme={null}
maverics \
  -config /etc/maverics/maverics.yaml \
  -secretProvider "hashivault://vault.example.com:8200/secret/data/maverics?token=<TOKEN>"
```

Available CLI flags:

| Flag | Description |
| - | - |
| `-config` | Path to YAML configuration file (required) |
| `-secretProvider` | Secret provider URL (alternative to `MAVERICS_SECRET_PROVIDER` env var) |
| `-version` | Print version and exit |
| `-verbose` | Enable debug-level logging |

**Docker deployment:**

```bash theme={null}
docker run -d \
  --name maverics \
  -p 9443:9443 \
  -v /etc/maverics/maverics.yaml:/etc/maverics/maverics.yaml:ro \
  -v /etc/maverics/certs:/etc/maverics/certs:ro \
  -e MAVERICS_SECRET_PROVIDER="hashivault://vault.example.com:8200/secret/data/maverics?token=<TOKEN>" \
  -e MAVERICS_HTTP_ADDRESS="0.0.0.0:9443" \
  maverics-orchestrator \
  -config /etc/maverics/maverics.yaml
```

**systemd deployment:**

```ini theme={null}
# /etc/systemd/system/maverics.service
[Unit]
Description=Maverics Orchestrator
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/maverics -config /etc/maverics/maverics.yaml
EnvironmentFile=/etc/maverics/env
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
```

```bash theme={null}
# /etc/maverics/env
MAVERICS_SECRET_PROVIDER=hashivault://vault.example.com:8200/secret/data/maverics?token=<TOKEN>
MAVERICS_HTTP_ADDRESS=0.0.0.0:9443
TLS_CERT_PATH=/etc/maverics/certs/server.pem
TLS_KEY_PATH=/etc/maverics/certs/server-key.pem
```

> [!TIP]
>
> Whichever deployment model you choose, the Orchestrator behaves the same way. The only differences are how you deliver the configuration file and how you manage the process lifecycle (restarts, scaling, health checks).

**4. Configure health checks and readiness probes**

The Orchestrator exposes a health endpoint that reports its operational status -- whether it has started successfully and is ready to handle traffic. In production, you should configure your infrastructure to poll this endpoint and take action when the Orchestrator is unhealthy.

The status endpoint returns a JSON response indicating the Orchestrator's operational state. Your load balancer, container orchestrator, or process manager can use this endpoint to:

* **Route traffic only to healthy instances** -- Remove unhealthy instances from the load balancer pool
* **Restart failed instances** -- Kubernetes liveness probes and Docker restart policies use health checks to detect and recover from failures automatically
* **Block traffic during startup** -- Readiness probes prevent traffic from reaching an instance before it has finished initializing

```bash theme={null}
# Check the status endpoint
curl -s https://localhost:9443/status | jq .
```

```json theme={null}
{
  "status": "up"
}
```

**Console UI**

> [!NOTE]
>
> **Console UI documentation is coming soon.** This section will walk you
> through configuring this component using the Maverics Console's visual
> interface, including step-by-step screenshots and field descriptions.

![Health check settings in Maverics Console showing endpoint configuration and probe intervals](https://mintcdn.com/strataidentity/yo114yy_clZj7p9v/images/placeholder.svg?fit=max\&auto=format\&n=yo114yy_clZj7p9v\&q=85\&s=ea8d2ec72a69d5a8c7955d78abba6a30)

**Configuration**

Configure the health endpoint path and heartbeat monitoring:

```yaml maverics.yaml theme={null}
health:
  location: "/status"
  heartbeat:
    disabled: false
    logLevel: "info"
    interval: "60s"
```

**Kubernetes probes** using the health endpoint:

```yaml theme={null}
# Kubernetes deployment snippet
livenessProbe:
  httpGet:
    path: /status
    port: 9443
    scheme: HTTPS
  initialDelaySeconds: 10
  periodSeconds: 15
readinessProbe:
  httpGet:
    path: /status
    port: 9443
    scheme: HTTPS
  initialDelaySeconds: 5
  periodSeconds: 10
```

**Docker health check:**

```bash theme={null}
docker run -d \
  --health-cmd="curl -kf https://localhost:9443/status || exit 1" \
  --health-interval=15s \
  --health-timeout=5s \
  --health-retries=3 \
  # ... rest of docker run command
```

**5. Verify the deployment**

With the Orchestrator deployed and health checks configured, verify that everything is working end-to-end. Start by confirming the health endpoint returns a healthy status, then test the full authentication flow.

```bash theme={null}
# Verify status
curl -s https://your-orchestrator-host:9443/status | jq .

# Check that the Orchestrator is serving traffic
curl -I https://your-orchestrator-host:9443/
```

Walk through the full user flow to confirm end-to-end functionality:

1. **Visit a protected URL** -- You should be redirected to your identity provider
2. **Authenticate** -- Log in with valid credentials
3. **Verify redirect** -- After authentication, you should land on your protected application
4. **Check logs** -- Confirm the Orchestrator logged the authentication event

> [!TIP]
>
> **Success!** Your Orchestrator is deployed in production with environment-specific
> configuration, health monitoring, and automated restarts. The health endpoint
> reports a healthy status, and the full authentication flow works end-to-end.

## Troubleshooting

> **Orchestrator fails to start**
>
> Check the Orchestrator's startup logs for the specific error. The most common
> causes are:
>
> * **Invalid YAML** -- Indentation errors, missing colons, or unclosed quotes.
>   Run your config through a YAML validator.
> * **Missing required fields** -- The Orchestrator validates its configuration on
>   startup and logs which fields are missing.
> * **Port conflict** -- Another process is already using the configured listening
>   port. Check with `lsof -i :8080` or change the port in your configuration.
> * **Permission denied** -- The Orchestrator process does not have permission to
>   read the config file, TLS certificates, or bind to the configured port.

> **Configuration not loading from external source**
>
> If you are using an external [config source](/reference/orchestrator/configuration/config-sources),
> verify that:
>
> * The config source credentials are correct and the Orchestrator can reach the
>   external service over the network
> * The config source path or key matches what the Orchestrator expects
> * Environment variables referenced in the configuration are set in the
>   Orchestrator's runtime environment (not just your local shell)
>
> Enable `debug` logging temporarily to see the exact config source requests and
> responses.

> **Health check returns unhealthy or times out**
>
> An unhealthy status usually means one or more connectors failed to initialize.
> Check the Orchestrator's logs for startup errors.
>
> If the health endpoint times out entirely, the Orchestrator may not be listening
> on the expected port. Verify the port configuration and check that no firewall
> rules are blocking access to the health endpoint.

## Related Pages

> **[Operations Overview](/guides/operations/overview)**
>
> Back to the Operations guides hub

> **[Orchestrator Configuration Reference](/reference/orchestrator/configuration)**
>
> Full reference for configuration file structure, environment variables, and runtime settings

> **[Scale for Production](/guides/operations/scale)**
>
> Scale your deployment horizontally with sticky sessions and Redis caching