What is Swytch?

Swytch is a Kubernetes-native, Redis-compatible cache that runs beside your application. It is compatible with Redis clients and data structures your application already knows.

With a sidecar, your application connects over localhost or a Unix socket and cache state lives in the sidecar’s memory. If that state is rebuildable, losing it just means refilling the cache.

The operator attaches Swytch to Pods. Outside Kubernetes, run a local process or standalone server.

Each application instance can keep its own Swytch beside it. Each instance subscribes to keys through use, so a shared key can reach the workloads that need it without putting every key on every node.

Only distributed keys pay distributed latency. Local access still has memory and CPU costs. See local and distributed keys.

Enable --ssi to use real transactions. Read a value inside MULTI, make a decision in your application’s language, and commit your writes together with EXEC. Commands return snapshot results immediately, so Lua is not required. SSI transactions are recommended for new logic; existing Lua scripts have best-effort compatibility support.

Open-source local durability uses --data-dir to mirror resident effects for restart recovery. It follows eviction and keeps normal reads in memory. Recovery requires enough memory to load the saved state.

Atmos is the commercial local-disk tier; Swytch Cloud is the network tier. Choose by the retention and failure behavior you need, from a process restart to loss of an entire node. Durability and tiering explains those boundaries.

The progression stays the same: one app, a sidecar, optional tiering, then more nodes, clusters, and regions. All with the standard Redis programming model.

Next: run Swytch on Kubernetes.

For questions, discussions, and interesting topics, join us on Discord.