Skip to main content
The cluster session store distributes sessions across Orchestrator nodes using peer-to-peer clustering. When combined with cluster routing, any node can serve any user’s request without load balancer stickiness. No Redis or external session store to manage.
Cluster sessions require the experimental.clusters feature flag and are not supported for production and may be changed or removed without notice. For production multi-node deployments, use sticky sessions on your load balancer with local session storage on each node.
Console deployments: Cluster sessions are not available natively in the Maverics Console. To use cluster sessions with Console-deployed Orchestrators, use the config override feature. Config override requires enablement for your organization — contact your Strata account team or Strata support to enable it.
Prerequisite: Cluster sessions require a configured cluster. See the Clusters reference page for setup instructions including discovery, encryption, and data plane configuration.

​
Overview

The Orchestrator replicates session data across all nodes in the cluster. Every node holds a copy of every session, so requests can land on any node and the user experience is seamless. A cluster must be defined in the configuration before cluster sessions can be used.

​
Use Cases

  • Zero-infrastructure horizontal scaling — add Orchestrator nodes and sessions just work. No Redis cluster to size, tune, or maintain.
  • Self-healing deployments — sessions are already replicated, so if a node goes down users are unaffected. No failover scripts, no data loss.
  • Foundation for global revocation — the clustering substrate is designed to carry security events like session revocations across all nodes, enabling future workflows where a single action enforces access decisions cluster-wide.
  • Simplified operations — fewer moving parts means fewer things to break. No external session store to monitor, patch, or back up.

​
Configuration

Cluster sessions require a store type, a reference to a configured cluster, and optional lifetime and cookie settings: 
session:
  store:
    type: cluster
    cluster:
      name: my-cluster
  lifetime:
    maxTimeout: 24h
    idleTimeout: 15m
  cookie:
    name: maverics_session
The cluster session store requires a clusters definition in your configuration. See the Clusters reference for complete cluster setup including membership, data plane, and discovery.

​
Configuration Reference

​
Cluster Store Fields

KeyTypeRequiredDescription
session.store.typestringYesMust be "cluster" for cluster session storage
session.store.cluster.namestringYesCluster name — must match a defined cluster in clusters[]
Session lifetime, cookie, and dynamic expiration settings apply to all session stores and are documented on the Sessions overview page.

​
Troubleshooting

  • Cluster sessions not working — cluster sessions require the experimental.clusters feature flag and a valid cluster definition. Verify that your cluster is configured and that the session store’s cluster name matches a defined cluster.
  • Sessions not shared across nodes — ensure all nodes are members of the same cluster and that the data plane is configured correctly. Check Orchestrator logs for cluster membership and replication errors.
  • Cookie domain issues — if sessions are lost when navigating between subdomains, set session.cookie.domain to the parent domain (e.g., .example.com).

Sessions

Overview of session types and production support status

Local Sessions

Production-ready single-node session storage with LRU eviction and sticky session guidance

Clusters

Cluster setup including discovery, encryption, and data plane configuration