Skip to main content
The cluster session store (session.store.type: cluster) provides distributed session storage across multiple Orchestrator nodes using peer-to-peer clustering. Sessions are replicated across the cluster, enabling any node to serve any user’s request without sticky sessions.
Cluster sessions (type: cluster) 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 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.
Prerequisite: Cluster sessions require a configured cluster. See the Clusters reference page for setup instructions including discovery, encryption, and data plane configuration.

Overview

When using the cluster session store, the Orchestrator shares session data across all nodes in the cluster using gossip-based membership and data-plane replication. Unlike local sessions, cluster sessions allow any node to handle any user’s request because session data is replicated cluster-wide. A cluster must be defined in the configuration before cluster sessions can be used.

Use Cases

  • Multi-node development and testing — test distributed session behavior without setting up external infrastructure like Redis
  • Self-contained deployments — deployments that need shared sessions without depending on an external session store

Configuration

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.

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[]
Cookie and lifetime settings from the Local Sessions page also apply to cluster sessions. See the Local Sessions page for the full cookie settings, session lifetime, and deprecated fields reference tables.

Additional Fields

The following fields from the local sessions configuration reference also apply to cluster sessions:
KeyTypeRequiredDescription
session.lifetime.maxTimeoutdurationNoMaximum session lifetime (duration string, e.g., 24h, 3600s)
session.lifetime.idleTimeoutdurationNoIdle timeout — session expires after this period of inactivity (duration string)
session.cookie.namestringNoSession cookie name (default: maverics_session)
session.cookie.domainstringNoCookie domain scope
session.cookie.disableSecureboolNoAllow the session cookie over unencrypted HTTP (default: false)
session.cookie.disableHTTPOnlyboolNoAllow client-side script access to the session cookie (default: false)

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