Skip to main content
Swytch Documentation
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage

Swytch Cloud

Recover state after losing all in-memory holders, or fetch keys that have been evicted from every live node. Swytch Cloud adds a network storage tier and peer discovery while your application keeps talking to its local Swytch.

Setup

Generate the cloud secrets:

swytch gen-passphrase --cloud
# Cloud secret (enter during onboarding): dGhpcyBpcyBub3QgYSByZWFsIHNlY3JldA
# Connection secret (start with --cloud): bm90IGEgcmVhbCBzZWNyZXQgZWl0aGVy

Enter the cloud secret during onboarding at Swytch Cloud. Keep the connection secret private; it never leaves your infrastructure. Start every node with it:

swytch redis --bind=0.0.0.0 --cloud="bm90..."

The connection secret is a self-contained cluster identity: the cluster mTLS passphrase derives from it and peers are discovered through the Cloud roster, so --cloud replaces both --cluster-passphrase and --join. Use swytch gen-passphrase --cloud --json for machine-readable output in provisioning scripts.

Security Model

Effects are sealed client-side with XChaCha20-Poly1305 under a key derived from the connection secret. Every node derives the same key independently, so there is no key exchange, and Cloud stores only ciphertext. The cloud secret is a one-way derivation from the connection secret: Cloud can authenticate the cluster with it but can never recover the connection secret or decrypt your data.

Durability Semantics

Uploads are asynchronous and never block a write. Each effect stays in an outbox, pinned against eviction, until Cloud acknowledges it as stored, with automatic retries on failure. The un-acked tail is the durability lag: it can be lost if the process exits before the acknowledgement arrives and no surviving peer holds it. During a Cloud outage the cluster keeps serving reads and writes; the outbox drains when connectivity returns.

Kubernetes

Use the connection secret in the profile’s Cloud discovery block. See Kubernetes tiering for the Secret and resource configuration.

Plan recovery around acknowledgements

A Redis command reply confirms the command, not completion of the asynchronous upload. Before depending on full-cluster recovery, verify that the state you need has reached the storage tier. A surviving peer may hold recent state, but peer count alone does not prove that it does.