Hazelcast

Available in Zilla Plus

The hazelcast store connects to a Hazelcast cluster and holds AI Gateway state, the MCP listing cache and OAuth guard session state, so every Zilla instance in a deployment shares the same data instead of keeping its own local copy. Cluster members can be discovered via a static address list, AWS EC2 tags, or Kubernetes service names.

Configuration

stores:
  cache:
    type: hazelcast
    options:
      cluster: dev
      addresses:
        - hazelcast.example.com:5701
      default-ttl: PT10S

cluster names the Hazelcast cluster to join, addresses lists known members for static discovery, and default-ttl sets how long entries live before expiring.

When to Use It

Choose Hazelcast once AI Gateway runs as more than one instance and the listing cache or OAuth guard session state needs to be consistent across all of them, particularly in deployments already running a Hazelcast cluster or where AWS EC2 or Kubernetes-based member discovery is preferred over a fixed address list.

For a single-node deployment or local testing, the Memory store avoids the extra dependency. Redis is an alternative distributed store when Redis is already part of the deployment.

See the hazelcast store reference for the full configuration reference, including AWS and Kubernetes discovery options.