> ## 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.
</Note>

## 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

<Steps>
  <Step title="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

    <Tabs>
      <Tab title="Console UI">
        <Info>
          **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.
        </Info>

        <Frame caption="Production configuration settings in Maverics Console">
          <img src="https://mintcdn.com/strataidentity/yo114yy_clZj7p9v/images/placeholder.svg?fit=max&auto=format&n=yo114yy_clZj7p9v&q=85&s=ea8d2ec72a69d5a8c7955d78abba6a30" alt="Production configuration panel in Maverics Console showing environment variables and secret provider settings" width="800" height="400" data-path="images/placeholder.svg" />
        </Frame>
      </Tab>

      <Tab title="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.
      </Tab>
    </Tabs>

    <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.
    </Tip>
  </Step>

  <Step title="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.

    <Tabs>
      <Tab title="Console UI">
        <Info>
          **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.
        </Info>

        <Frame caption="Secret provider selection in Maverics Console">
          <img src="https://mintcdn.com/strataidentity/yo114yy_clZj7p9v/images/placeholder.svg?fit=max&auto=format&n=yo114yy_clZj7p9v&q=85&s=ea8d2ec72a69d5a8c7955d78abba6a30" alt="Secret provider configuration in Maverics Console" width="800" height="400" data-path="images/placeholder.svg" />
        </Frame>
      </Tab>

      <Tab title="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.
        </Note>

        ```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.
      </Tab>
    </Tabs>
  </Step>

  <Step title="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.

    <Tabs>
      <Tab title="Console UI">
        <Info>
          **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.
        </Info>

        <Frame caption="Deployment target selection in Maverics Console">
          <img src="https://mintcdn.com/strataidentity/yo114yy_clZj7p9v/images/placeholder.svg?fit=max&auto=format&n=yo114yy_clZj7p9v&q=85&s=ea8d2ec72a69d5a8c7955d78abba6a30" alt="Deployment wizard in Maverics Console showing Docker and Kubernetes deployment options" width="800" height="400" data-path="images/placeholder.svg" />
        </Frame>
      </Tab>

      <Tab title="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
        ```
      </Tab>
    </Tabs>

    <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).
    </Tip>
  </Step>

  <Step title="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"
    }
    ```

    <Tabs>
      <Tab title="Console UI">
        <Info>
          **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.
        </Info>

        <Frame caption="Health check configuration in Maverics Console">
          <img src="https://mintcdn.com/strataidentity/yo114yy_clZj7p9v/images/placeholder.svg?fit=max&auto=format&n=yo114yy_clZj7p9v&q=85&s=ea8d2ec72a69d5a8c7955d78abba6a30" alt="Health check settings in Maverics Console showing endpoint configuration and probe intervals" width="800" height="400" data-path="images/placeholder.svg" />
        </Frame>
      </Tab>

      <Tab title="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
        ```
      </Tab>
    </Tabs>
  </Step>

  <Step title="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

    <Check>
      **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.
    </Check>
  </Step>
</Steps>

## Troubleshooting

<AccordionGroup>
  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>

## Related Pages

<CardGroup cols={2}>
  <Card title="Operations Overview" icon="compass" href="/guides/operations/overview">
    Back to the Operations guides hub
  </Card>

  <Card title="Orchestrator Configuration Reference" icon="gear" href="/reference/orchestrator/configuration">
    Full reference for configuration file structure, environment variables, and runtime settings
  </Card>

  <Card title="Scale for Production" icon="arrows-up-down" href="/guides/operations/scale">
    Scale your deployment horizontally with sticky sessions and Redis caching
  </Card>
</CardGroup>