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

# Overview

The Maverics Console compiles Orchestrator configuration into cryptographically signed bundles and deploys them to storage providers. Orchestrator instances poll their configured storage provider for updated bundles, verify the signature, and apply the new configuration automatically.

## Bundle Format

The config bundle is a gzip-compressed tar archive named `maverics.tar.gz`. It contains everything the Orchestrator needs to run with the published configuration.

| File                           | Description                                                                                            |
| ------------------------------ | ------------------------------------------------------------------------------------------------------ |
| `maverics.json`                | The compiled Orchestrator configuration in JSON format                                                 |
| Service extension source files | Source files for any service extensions attached to the deployment                                     |
| Asset files                    | Files referenced by applications (HTML templates, static assets, etc.)                                 |
| `signature.jwt`                | Cryptographic signature for tamper detection -- see [Bundle Signing](#bundle-signing-and-verification) |

## Bundle Signing and Verification

Every config bundle is cryptographically signed to prevent tampering. The signing process uses ECDSA P-256 keys with SHA-256 hashes.

### Key Generation

When a deployment is created, the Console generates an ECDSA P-256 key pair:

* **Private key** -- Stored in the Console. Used to sign bundles at publish time. The private key is never exported or exposed through any API endpoint.
* **Public key** -- Provided to the Orchestrator via `MAVERICS_BUNDLE_PUBLIC_KEY_FILE`. Used to verify bundle signatures before applying configuration. The public key can be downloaded from the Console as a `.pem` file.

### Signing Process (Console)

When a bundle is published, the Console signs it using the following process:

<Steps>
  <Step title="Hash each file">
    Compute a SHA-256 hash of every file in the bundle (`maverics.json`, service extension source files, asset files).
  </Step>

  <Step title="Build hash list">
    Package the file hashes into a hash list containing the filename, hex-encoded SHA-256 hash, and hash algorithm for each file.
  </Step>

  <Step title="Sign as JWT">
    Sign the hash list as JWT claims using ECDSA P-256 with the deployment's private key.
  </Step>

  <Step title="Add to bundle">
    Include the signed JWT as `signature.jwt` in the tar archive.
  </Step>
</Steps>

### Verification Process (Orchestrator)

When the Orchestrator downloads a new bundle, it verifies the signature before applying the configuration:

<Steps>
  <Step title="Parse JWT">
    Extract the JWT from `signature.jwt` in the bundle.
  </Step>

  <Step title="Verify signature">
    Verify the ECDSA P-256 signature using the deployment's public key (provided via `MAVERICS_BUNDLE_PUBLIC_KEY_FILE`).
  </Step>

  <Step title="Validate file count">
    Confirm that the number of files listed in the JWT matches the number of files in the bundle.
  </Step>

  <Step title="Verify file hashes">
    For each file listed in the JWT, verify that the file exists in the bundle and its SHA-256 hash matches the hash in the JWT.
  </Step>
</Steps>

<Warning>
  If signature verification fails at any step, the Orchestrator rejects the bundle and continues running with its current configuration. This ensures that tampered or corrupted bundles are never applied.
</Warning>

## Deployment Lifecycle

Publishing a config bundle follows a 5-step lifecycle.

<Steps>
  <Step title="Build configuration">
    The Console compiles the full Orchestrator configuration from all managed objects: applications and their policies, headers, and connector bindings, custom APIs, identity fabrics (connectors), providers (OIDC, SAML, MCP, LDAP), TLS certificates, caches, session configuration, service extensions, startup/environment configuration, and custom override configuration.
  </Step>

  <Step title="Create revision">
    The compiled configuration is stored as a numbered revision in the Console. Each revision captures the complete configuration state at the time of publish.
  </Step>

  <Step title="Build bundle">
    The Console assembles the gzip-compressed tar bundle: serializes the configuration as `maverics.json`, includes service extension source files and asset files, and signs the bundle with the deployment's ECDSA private key.
  </Step>

  <Step title="Deploy to provider">
    The signed bundle is uploaded to the deployment's configured storage provider (S3, Azure Blob, GCS, GitHub, GitLab, or download-only).
  </Step>

  <Step title="Orchestrator polls and applies">
    The Orchestrator detects the new bundle on its next poll cycle, downloads it, verifies the signature, and applies the updated configuration.
  </Step>
</Steps>

## Deployment Providers

The Console supports 7 deployment providers. Each provider determines where the signed bundle is stored and how the Orchestrator retrieves it.

| Provider                                | Description                                                                                                                                                   |
| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **No Cloud Storage Service Configured** | No-op deploy. The bundle is available for manual download from the Console UI only. Best for air-gapped environments where bundles are transferred manually.  |
| **Maverics Storage**                    | Strata-managed storage for evaluation and trial deployments. No customer infrastructure required. Evaluation storage is automatically recycled every 90 days. |
| **Amazon S3 Bucket**                    | Customer's S3 bucket with cross-account IAM role access.                                                                                                      |
| **Microsoft Azure Blob Storage**        | Customer's Azure Blob container with SAS token authentication.                                                                                                |
| **Google Cloud Storage Bucket**         | Customer's GCS bucket with service account key authentication.                                                                                                |
| **GitHub**                              | Customer's GitHub repository with personal access token.                                                                                                      |
| **GitLab**                              | Customer's GitLab repository with personal access token.                                                                                                      |

All providers deploy the bundle as `maverics.tar.gz` to the specified `configurationFilePath` within the storage location.

## Storage Configuration

Each deployment provider requires specific configuration fields. Select your provider below for setup instructions, required fields, and IAM/access configuration.

<CardGroup cols={2}>
  <Card title="Maverics Storage" icon="cloud" href="/reference/console/config-publishing/maverics-storage">
    Strata-managed storage, no configuration required
  </Card>

  <Card title="Amazon S3 Bucket" icon="aws" href="/reference/console/config-publishing/s3">
    Bucket name, IAM role, cross-account setup
  </Card>

  <Card title="Azure Blob Storage" icon="microsoft" href="/reference/console/config-publishing/azure-blob">
    Storage account, container, SAS token
  </Card>

  <Card title="Google Cloud Storage" icon="google" href="/reference/console/config-publishing/gcs">
    Bucket name, service account key
  </Card>

  <Card title="GitHub" icon="github" href="/reference/console/config-publishing/github">
    Repository owner, token
  </Card>

  <Card title="GitLab" icon="gitlab" href="/reference/console/config-publishing/gitlab">
    Namespace, repository, branch, token
  </Card>
</CardGroup>

The **No Cloud Storage Service Configured** provider requires no configuration. **Maverics Storage** has its own setup page above.

## Publish Preview and Validation

At the bottom of each deployment's Settings page, a sticky footer bar provides publishing controls:

* **Publish Preview** -- Opens the Deployment Manager dialog to review and publish changes.
* **Version selector** -- Switch between the latest and older revisions.
* **Download Deployment** -- Download the deployment bundle without publishing.

### Deployment Manager

Clicking **Publish Preview** opens the **Deployment Manager** dialog, which contains:

* **Simulation Settings** -- Configure a "Simulate Continuity Strategy" toggle and a "Start After Time" field for testing deployment behavior.
* **Revisions** -- Select an existing revision or create a new one. Add a note describing what changed.
* **Diff view** -- Side-by-side comparison of `maverics.json` showing the current configuration versus the new configuration.

At the bottom of the dialog, click **Publish** to deploy the configuration bundle, or **Cancel** to close without publishing.

Use the Deployment Manager to verify that configuration changes are intentional before deploying to your Orchestrator instances.

## Revision History

Every publish creates a numbered revision that captures the complete configuration state. Revisions provide version control for your Orchestrator configuration.

### Revision Capabilities

* **Diff between revisions** -- Compare any two revisions to see what changed.
* **Revision notes** -- Add notes to each revision describing what changed and why.
* **Rollback** -- Deploy a specific historical revision to revert to a known-good configuration.

### Revision API

| Endpoint                                       | Method | Description                                                                                                                                            |
| ---------------------------------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `/deployments/{id}/revisions`                  | `GET`  | List all revisions for a deployment                                                                                                                    |
| `/deployments/{id}/revisions/{revisionNumber}` | `GET`  | View a specific revision with diff                                                                                                                     |
| `/deployments/{id}/deploy`                     | `POST` | Deploy a revision. Include a `revisionNumber` field to deploy a specific historical revision instead of building a new one from current Console state. |

## Orchestrator Polling Configuration

The Orchestrator polls its configured storage provider for new bundles at a regular interval. Configure polling behavior with the following environment variables.

| Variable                            | Default | Description                                                                              |
| ----------------------------------- | ------- | ---------------------------------------------------------------------------------------- |
| `MAVERICS_RELOAD_CONFIG`            | `false` | Set to `true` to enable configuration hot-reload. Required for automatic bundle polling. |
| `MAVERICS_POLLING_INTERVAL_SECONDS` | `30`    | How often (in seconds) the Orchestrator checks for new bundles.                          |
| `MAVERICS_BUNDLE_PUBLIC_KEY_FILE`   | --      | Path to the public key PEM file for verifying bundle signatures.                         |
| `MAVERICS_AWS_CONFIG`               | --      | JSON configuration for AWS S3 access. Used with evaluation (`aws_eval`) deployments.     |

<Note>
  The Orchestrator retrieves bundles using the same mechanism as the deployment provider's config source type. See the [config source references](/reference/orchestrator/configuration/config-sources) for provider-specific environment variables (e.g., S3 bucket configuration, Azure Blob credentials).
</Note>

### Example: Evaluation Deployment

For evaluation deployments, the Console generates an environment file with all required variables:

```bash theme={null}
export MAVERICS_RELOAD_CONFIG=true
export MAVERICS_POLLING_INTERVAL_SECONDS=30
export MAVERICS_BUNDLE_PUBLIC_KEY_FILE=./public_key.pem
export MAVERICS_AWS_CONFIG='{"region":"us-east-1","bucketName":"strata-eval","accessKeyID":"...","secretAccessKey":"...","configurationFilePath":"..."}'
```

## Override Config

Override config provides a configuration override mechanism for deployments. When enabled for your organization, you can inject custom settings that are merged into the compiled configuration at build time.

### How It Works

* A `_custom` key is added to the deployment's startup configuration.
* Custom settings in `_custom` are merged into the compiled configuration during the bundle build step.
* Top-level keys in the override can replace or extend Console-managed configuration objects.

### Use Cases

* **Orchestrator features not yet in the Console** -- Some Orchestrator configuration options are not yet manageable through the Console UI. Override config lets you use these features without waiting for Console support to be added.

<Warning>
  Override configuration requires enablement for your organization. Contact your Strata account team or [Strata support](https://strataidentity.my.site.com/support/s/) to enable it.
</Warning>

## Common Errors

### Failed to read public key

```
failed to instantiate config provider: unable to read file 'public_key.pem'
```

The Orchestrator cannot find the public key file specified by `MAVERICS_BUNDLE_PUBLIC_KEY_FILE`. Verify that the file path is correct and the file is readable by the Orchestrator process.

### Bundle signature verification failed

```
bundle signature verification failed
```

The public key provided to the Orchestrator does not match the private key used to sign the bundle. This typically happens when the public key file belongs to a different deployment. Download the correct public key from the Console for the deployment that published the bundle.

## Related Pages

<CardGroup cols={2}>
  <Card title="Break-Glass Procedures" icon="triangle-exclamation" href="/reference/console/break-glass">
    Emergency procedures when the Console is inaccessible
  </Card>

  <Card title="Config Sources" icon="folder-gear" href="/reference/orchestrator/configuration/config-sources">
    All Orchestrator configuration source types
  </Card>

  <Card title="Deploy to Production" icon="rocket" href="/guides/operations/deploy">
    Production deployment guide for the Orchestrator
  </Card>

  <Card title="Console Overview" icon="browser" href="/reference/console/overview">
    Console administration overview and capabilities
  </Card>
</CardGroup>