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.

Use real transactions to read, make decisions in application code, and commit writes together. With --ssi, commands inside MULTI return their results immediately. Lua is optional; SSI transactions are recommended for new transactional logic.

Try the local quickstart: get running with Homebrew, Nix, curl, PowerShell, or Docker, then read and write data with a Redis client.

Deploying on Kubernetes? Follow 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.

Memory-only state disappears when its last holder disappears. Open-source local durability can restore resident state from disk after a process restart. Durability and tiering compares that mirror with Swytch Cloud and the commercial local-disk tier, Atmos, including eviction and failure boundaries.

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.

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