mirror of
https://github.com/andwati/zitadel.git
synced 2026-10-18 05:52:51 +00:00
zitadel-knowledge-bot[bot]GitHubzitadel-knowledge-bot[bot] <296006658+zitadel-knowledge-bot[bot]@users.noreply.github.com>fcoppedeAutomatically generated PR targeting 1 files. **Thread ID:** 1512031509387673610 **Action:** UPDATE **AI Summary:** > The documentation lacks clear explanation of how the 'Use new login UI' checkbox and 'Custom base URL for the new Login UI' field work together, including step-by-step configuration and troubleshooting guidance. --------- Co-authored-by: zitadel-knowledge-bot[bot] <296006658+zitadel-knowledge-bot[bot]@users.noreply.github.com> Co-authored-by: fcoppede <[email protected]>
81 lines
2.8 KiB
Plaintext
81 lines
2.8 KiB
Plaintext
---
|
|
title: Caching
|
|
description: "Configure ZITADEL caching with Redis or Valkey on Kubernetes using authentication methods like passwords and TLS connections"
|
|
sidebar_label: Caching
|
|
---
|
|
|
|
|
|
|
|
This guide explains how to connect Zitadel caches to Redis or Valkey on Kubernetes.
|
|
|
|
<Callout type="info">
|
|
Caching is an experimental beta feature. See the [Caches](/self-hosting/manage/cache) page for behavior, objects, and tuning guidance.
|
|
</Callout>
|
|
|
|
Zitadel supports Redis or any Redis-compatible store (for example, Valkey) in standalone mode. Sentinel and Redis Cluster are not supported because the cache connector expects a single endpoint and does not implement cluster routing or sentinel failover logic.
|
|
|
|
<Callout type="info">
|
|
Zitadel supports server-auth TLS (`rediss://` scheme) but does not support client certificates/mTLS for cache connections.
|
|
</Callout>
|
|
|
|
Each cache uses its own Redis database index. Set `DBOffset` so Zitadel-owned indexes do not overlap with other applications. Zitadel issues `FLUSHDB` on its cache databases, so sharing an index with other apps is unsafe.
|
|
|
|
## Connect without authentication (development only)
|
|
|
|
Pass the Redis URL as an environment variable:
|
|
|
|
```yaml
|
|
zitadel:
|
|
env:
|
|
- name: ZITADEL_CACHES_CONNECTORS_REDIS_URL
|
|
value: "redis://redis-master.caching.svc.cluster.local:6379"
|
|
- name: ZITADEL_CACHES_CONNECTORS_REDIS_ENABLED
|
|
value: "true"
|
|
```
|
|
|
|
Use this only on isolated clusters where the Redis endpoint does not require authentication.
|
|
|
|
## Connect with password from a Kubernetes Secret
|
|
|
|
Store the Redis URL (with credentials) in a secret and pass it as an environment variable:
|
|
|
|
```bash
|
|
kubectl create secret generic zitadel-cache-credentials \
|
|
--from-literal=url="redis://cache-user:[email protected]:6379"
|
|
```
|
|
|
|
```yaml
|
|
zitadel:
|
|
env:
|
|
- name: ZITADEL_CACHES_CONNECTORS_REDIS_URL
|
|
valueFrom:
|
|
secretKeyRef:
|
|
name: zitadel-cache-credentials
|
|
key: url
|
|
- name: ZITADEL_CACHES_CONNECTORS_REDIS_ENABLED
|
|
value: "true"
|
|
```
|
|
|
|
## Connect with TLS (Redis or Valkey)
|
|
|
|
Use the `rediss://` scheme (note the double `s`) when your endpoint requires encryption. This uses server-auth TLS with the container's trust store.
|
|
|
|
```bash
|
|
kubectl create secret generic zitadel-cache-credentials \
|
|
--from-literal=url="rediss://cache-user:[email protected]:6380"
|
|
```
|
|
|
|
```yaml
|
|
zitadel:
|
|
env:
|
|
- name: ZITADEL_CACHES_CONNECTORS_REDIS_URL
|
|
valueFrom:
|
|
secretKeyRef:
|
|
name: zitadel-cache-credentials
|
|
key: url
|
|
- name: ZITADEL_CACHES_CONNECTORS_REDIS_ENABLED
|
|
value: "true"
|
|
```
|
|
|
|
Custom certificate authorities must be added to the container's trust bundle (for example, by mounting a CA file into the pod); client certificate authentication is not supported.
|