Swytch
Swytch is a Kubernetes-native, Redis-compatible cache designed to run beside your application.
Your app connects to a local sidecar. Start with fast, disposable state in memory, share keys across workloads when needed, and add storage tiers as your requirements grow. You can also run Swytch as a standalone server.
One app → sidecar → optional tiering → cluster → multiple clusters and regions.
Start with the Kubernetes quickstart. The operator attaches Swytch to your application; your Redis
client connects to localhost:6379.
- What is Swytch? explains the deployment model.
- Redis compatibility covers what your existing client can expect.
- From Redis to Swytch walks through adoption and cutover.
- Run without Kubernetes covers a local process or standalone server.
| Your workload | What Swytch can replace | Start here |
|---|---|---|
| Rebuildable application cache | A separate Redis cache tier | Sidecar caching |
| Selected state shared by application instances | A separate endpoint for shared cache state | Local and distributed keys |
| Caddy certificate storage | An external certificate storage database | Caddy storage |
| Redis access beside Caddy | A separate Redis server process | Redis server in Caddy |
Memory-only state disappears when its last holder disappears. Tiering helps you choose a storage option, including Swytch Cloud and the commercial local-disk option, Atmos.
Only distributed keys pay distributed latency. A key used across regions has different costs from a key used by one workload. Local and distributed keys explains the boundary, including first reads and transaction costs.
Keep using keys, lists, sets, streams, and pub/sub as you scale the topology. The data structure guides show how to use them; architecture and correctness explains the mechanisms.