Skip to main content
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.
FileDescription
maverics.jsonThe compiled Orchestrator configuration in JSON format
Service extension source filesSource files for any service extensions attached to the deployment
Asset filesFiles referenced by user flows (HTML templates, static assets, etc.)
signature.jwtCryptographic signature for tamper detection — see Bundle Signing

​
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:
1

Hash each file

Compute a SHA-256 hash of every file in the bundle (maverics.json, service extension source files, asset files).
2

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

Sign as JWT

Sign the hash list as JWT claims using ECDSA P-256 with the deployment’s private key.
4

Add to bundle

Include the signed JWT as signature.jwt in the tar archive.

​
Verification Process (Orchestrator)

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

Parse JWT

Extract the JWT from signature.jwt in the bundle.
2

Verify signature

Verify the ECDSA P-256 signature using the deployment’s public key (provided via MAVERICS_BUNDLE_PUBLIC_KEY_FILE).
3

Validate file count

Confirm that the number of files listed in the JWT matches the number of files in the bundle.
4

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

​
Deployment Lifecycle

Publishing a config bundle follows a 5-step lifecycle.
1

Build configuration

The Console compiles the full Orchestrator configuration from all managed objects: applications and their attached user flows, identity fabrics (connectors), providers (OIDC, SAML, MCP, LDAP), TLS certificates, caches, session configuration, service extensions, startup/environment configuration, and custom override configuration.
2

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

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

Deploy to provider

The signed bundle is uploaded to the deployment’s configured storage provider (S3, Azure Blob, GCS, GitHub, GitLab, or download-only).
5

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.

​
Deployment Providers

The Console supports 7 deployment providers. Each provider determines where the signed bundle is stored and how the Orchestrator retrieves it.
ProviderDescription
No Cloud Storage Service ConfiguredNo-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 StorageStrata-managed storage for evaluation and trial deployments. No customer infrastructure required. Evaluation storage is automatically recycled every 90 days.
Amazon S3 BucketCustomer’s S3 bucket with cross-account IAM role access.
Microsoft Azure Blob StorageCustomer’s Azure Blob container with SAS token authentication.
Google Cloud Storage BucketCustomer’s GCS bucket with service account key authentication.
GitHubCustomer’s GitHub repository with personal access token.
GitLabCustomer’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.

Maverics Storage

Strata-managed storage, no configuration required

Amazon S3 Bucket

Bucket name, IAM role, cross-account setup

Azure Blob Storage

Storage account, container, SAS token

Google Cloud Storage

Bucket name, service account key

GitHub

Repository owner, token

GitLab

Namespace, repository, branch, token
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

EndpointMethodDescription
/deployments/{id}/revisionsGETList all revisions for a deployment
/deployments/{id}/revisions/{revisionNumber}GETView a specific revision with diff
/deployments/{id}/deployPOSTDeploy 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.
VariableDefaultDescription
MAVERICS_RELOAD_CONFIGfalseSet to true to enable configuration hot-reload. Required for automatic bundle polling.
MAVERICS_POLLING_INTERVAL_SECONDS30How 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.
The Orchestrator retrieves bundles using the same mechanism as the deployment provider’s config source type. See the config source references for provider-specific environment variables (e.g., S3 bucket configuration, Azure Blob credentials).

​
Example: Evaluation Deployment

For evaluation deployments, the Console generates an environment file with all required variables: 
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.
Override configuration requires enablement for your organization. Contact your Strata account team or Strata support to enable it.

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

Break-Glass Procedures

Emergency procedures when the Console is inaccessible

Config Sources

All Orchestrator configuration source types

Deploy to Production

Production deployment guide for the Orchestrator

Console Overview

Console administration overview and capabilities