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

# Cluster Sessions

The cluster session store distributes sessions across Orchestrator nodes using peer-to-peer clustering. When combined with [cluster routing](/reference/orchestrator/experimental/clusters), any node can serve any user's request without load balancer stickiness. No Redis or external session store to manage.

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

<Note>
  **Console deployments:** Cluster sessions are not available natively in the Maverics Console. To use cluster sessions with Console-deployed Orchestrators, use the [**config override**](/reference/console/config-publishing#override-config) feature. Config override requires enablement for your organization -- contact your Strata account team or [Strata support](https://strataidentity.my.site.com/support/s/) to enable it.
</Note>

<Note>
  **Prerequisite:** Cluster sessions require a configured cluster. See the [Clusters](/reference/orchestrator/experimental/clusters) reference page for setup instructions including discovery, encryption, and data plane configuration.
</Note>

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

```mermaid theme={null}
%%{init: {'theme': 'neutral', 'themeVariables': {'edgeWidth': 4}}}%%
flowchart LR
    User["User"] --> LB["Load Balancer"]
    LB --> A["Orchestrator A"]
    LB --> B["Orchestrator B"]
    LB --> C["Orchestrator C"]
    A <-->|"session sync"| B
    B <-->|"session sync"| C
    A <-->|"session sync"| C

    classDef orch stroke:#6A3EC8,stroke-width:6px
    class A,B,C orch
```

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:

```yaml theme={null}
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/orchestrator/experimental/clusters) reference for complete cluster setup including membership, data plane, and discovery.

## Configuration Reference

### Cluster Store Fields

| Key                          | Type   | Required | Description                                                  |
| ---------------------------- | ------ | -------- | ------------------------------------------------------------ |
| `session.store.type`         | string | Yes      | Must be `"cluster"` for cluster session storage              |
| `session.store.cluster.name` | string | Yes      | Cluster name -- must match a defined cluster in `clusters[]` |

<Note>
  Session lifetime, cookie, and dynamic expiration settings apply to all session stores and are documented on the [Sessions overview](/reference/orchestrator/sessions#configuration-reference) page.
</Note>

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

## Related Pages

<CardGroup cols={2}>
  <Card title="Sessions" icon="user-clock" href="/reference/orchestrator/sessions">
    Overview of session types and production support status
  </Card>

  <Card title="Local Sessions" icon="microchip" href="/reference/orchestrator/sessions/local">
    Production-ready single-node session storage with LRU eviction and sticky session guidance
  </Card>

  <Card title="Clusters" icon="circle-nodes" href="/reference/orchestrator/experimental/clusters">
    Cluster setup including discovery, encryption, and data plane configuration
  </Card>
</CardGroup>