Managed Redis

Highly-available Redis, without the babysitting

A database cluster is one or more member VMs, each running its own Redis with a full local copy of the data. Redis Sentinel handles automatic promotion, and a managed load balancer gives you one stable :6379 write endpoint that always points at the current master — plus a load-balanced :6380 read endpoint across the replicas.

Get started Clusters overview

Quickstart When to use Create Connect Security Failover Updates Configuration Backups What it protects Pricing Reference

create a cluster, then connect

# In the dashboard: Console -> Clusters -> New cluster
#   Mode:    Database
#   Engine:  Redis
#   Version: 7
#   Nodes:   3        (1 = single, non-HA · 3+ = HA · 2 is not allowed)
#   Plan:    BXS.s1   (each member runs this plan)

# Every connection is TLS-encrypted (rediss://). Reveal the password
# and download the cluster's CA cert on the cluster page, then connect
# to the write endpoint (:6379 -> the current master):
redis-cli -u 'rediss://default:<password>@<host>:6379' --cacert ca.crt

# Read-only? Use :6380 — load-balanced across the replicas:
redis-cli -u 'rediss://default:<password>@<host>:6380' --cacert ca.crt GET mykey

Quickstart

Create the cluster in the dashboard (Console → Clusters → New cluster), pick Database mode and Redis, choose your node count, and connect from a VM on the same private network. The endpoints, password and metrics all live on the cluster page.

from create to connected

# In the dashboard: Console -> Clusters -> New cluster
#   Mode:    Database
#   Engine:  Redis
#   Version: 7
#   Nodes:   3        (1 = single, non-HA · 3+ = HA · 2 is not allowed)
#   Plan:    BXS.s1   (each member runs this plan)

# Every connection is TLS-encrypted (rediss://). Reveal the password
# and download the cluster's CA cert on the cluster page, then connect
# to the write endpoint (:6379 -> the current master):
redis-cli -u 'rediss://default:<password>@<host>:6379' --cacert ca.crt

# Read-only? Use :6380 — load-balanced across the replicas:
redis-cli -u 'rediss://default:<password>@<host>:6380' --cacert ca.crt GET mykey

When to use it

High availability is worth paying for when a Redis outage would hurt. When it would not, a single node is simpler and cheaper — reach for the cluster when you need failover.

Use a cluster (3+ nodes) when downtime hurts

Production Redis that must survive a member VM crashing or a redis-server dying — session stores, queues, rate limiters, caches your app can't cheaply rebuild. If a Redis outage would page you, you want automatic failover and an endpoint that follows it.

A single node is often enough for a cache

For a throwaway cache, dev or staging, one node is simpler and cheaper. There's no automatic failover, but you pay for one VM instead of three plus a load balancer — and a restart just warms the cache back up.

Start single, grow into HA

A one-node cluster is a normal managed Redis with the same endpoint and password — just no replica to fail over to. Scale it to three members later when the workload earns HA.

Create a cluster

Three choices decide the shape of the cluster: the engine, the version, and how many members. The one rule to remember is the node count.

Pick the mode and engine

Create a new cluster and choose Database mode, then Redis as the engine. Clusters run Redis 7 today. This is a database cluster, not a container cluster — Suble runs and supervises Redis and Sentinel for you.

mode -> engine -> version

Mode:    Database
Engine:  Redis
Version: 7

Choose the node count

One node is a single, non-HA Redis. Three or more nodes give you high availability: one master and N-1 replicas, each with a co-located Sentinel. Two nodes is deliberately not allowed — a two-member Sentinel group has no safe majority to promote from.

the 1-or-3+ rule

Nodes: 3     # 1 = single (no failover)
             # 3 = HA (1 master + 2 replicas)
             # 2 = not allowed (no Sentinel majority)

Size the members and create

Every member runs the same plan and gets its own full copy of the data — there's no shared or network storage. Suble provisions the members on a private network, a load balancer for the endpoints, wires up replication and Sentinel, and hands you the connection details.

provision the cluster

Plan: BXS.s1     # each member runs this plan
# -> members + load balancer + private network

Why not two nodes? Sentinel promotes a new master by majority. With two members, a single failure leaves one vote — never a majority — so the Sentinels cannot safely agree on a new master. That is why Suble allows 1 (single, no failover) or 3 or more (real HA), but never 2.

Connect

Every Redis connection is encrypted end-to-end with TLS (rediss://). New clusters are private by default — reachable from your app VMs on the same network — and because the wire is always encrypted, you can also expose a cluster publicly when you need to. You get a :6379 write endpoint (the current master) and a load-balanced :6380 read endpoint across the replicas, both behind one shared password.

redis-cli / REDIS_URL

# Every Redis connection is TLS-encrypted end-to-end (rediss://).
# New clusters are private by default — reach them from an app VM on
# the same network; because the wire is always encrypted you can also
# make a cluster public. One shared password (revealed on the page).

# Pin the cluster's CA (download it from the cluster page) so your
# client verifies the server:
redis-cli -u 'rediss://default:<password>@<host>:6379' --cacert ca.crt

# Reads → :6380 (load-balanced across the replicas):
redis-cli -u 'rediss://default:<password>@<host>:6380' --cacert ca.crt GET mykey

# From code, a TLS connection URL your client understands:
REDIS_URL="rediss://default:<password>@<host>:6379"
REDIS_READ_URL="rediss://default:<password>@<host>:6380"
# point your client at the CA file, or use its skip-verify option

Reveal the password

A password is generated for you and revealed on demand — owner-only. Every member and Sentinel shares it (requirepass and masterauth), so it keeps working through a failover.

Pin the CA

Each cluster gets its own certificate. Download the CA certificate from the cluster page and point your client at it (--cacert) to verify the server — or use your client's skip-verify option if you don't pin.

Split reads and writes

Send writes (and reads that must be current) to :6379, and offload heavy read-only traffic to :6380, which load-balances across the replicas. Replicas are eventually consistent — expect a small lag behind the master.

Security

Two layers you control: the wire is always encrypted, and you decide who can do what with per-user ACLs.

TLS everywhere — no plaintext

There is no plaintext port. Client connections, replication between members, and the Sentinels all speak TLS, using one certificate shared across the cluster (Redis verifies the master's cert during replication, so every member shares it). A plaintext client is refused at the handshake.

TLS-only — plaintext is refused

# TLS is always on — there is no plaintext port. A plaintext client
# is refused at the door:
redis-cli -h <host> -p 6379 -a <password> PING
#   -> Error: Connection reset by peer   (it's TLS-only)

# node (ioredis) — verify against the downloaded CA:
new Redis("rediss://default:<password>@<host>:6379", {
  tls: { ca: [fs.readFileSync("ca.crt")] },   // or tls: {} to skip verify
})

# python (redis-py):
redis.from_url("rediss://default:<password>@<host>:6379",
               ssl_ca_certs="ca.crt")

ACL users, read-write or read-only

Beyond the shared default user, create named users scoped read-write or read-only. Suble applies each user to every member — Redis ACLs are node-local — so a user keeps working after a failover and on the read endpoint. Each password is shown once.

a read-only user

# Cluster page -> Users tab -> New user
#   Username:  worker
#   Access:    Read-write   (full data access) | Read-only (GET/SCAN only)
# -> the password is shown ONCE (write-once) — copy it now.

# Connect as that user (over TLS, like everyone else):
redis-cli -u 'rediss://worker:<password>@<host>:6379' --cacert ca.crt

# A read-only user can read but not mutate:
#   GET mykey    -> "value"
#   SET mykey x  -> (error) NOPERM this user has no permissions to run 'set'

How failover works

Every member runs redis-server plus a Sentinel, and each keeps a full local copy of the data kept in sync by replication. One member is the master; the others are replicas. The load balancer only ever routes writes to whoever is currently the master.

Member VMs, shared-nothing

Each member is a real instance running its own redis-server with a FULL local copy of the data. Nothing is shared over the network — no shared volume, no SAN. The master streams every write to the replicas.

Sentinel for failover

Every member also runs a co-located Redis Sentinel. The Sentinels watch the master and each other; if the master VM or process dies, a majority agree and promote the healthiest replica in seconds — no external coordinator to operate.

One stable write endpoint

A managed load balancer exposes a single :6379 endpoint. HAProxy runs an active check (AUTH -> PING -> INFO replication) against each member, and only the current master reports role:master — so every write is routed to the master, and the endpoint auto-follows a failover.

A load-balanced read endpoint

A second :6380 endpoint routes only to members reporting role:slave with an up master link — spreading read-only traffic across the replicas so you can push heavy reads off the master without hard-coding replica addresses.

clients → LB :6379 → the current master

Your app (on the same private network)
   │  writes → redis://:***@<lb-ip>:6379    reads → :6380
   ▼
┌──────────── Managed Load Balancer (private) ──────────────┐
│  :6379  HAProxy check: only role:master answers → master   │
│  :6380  HAProxy check: role:slave + link up  → the replicas │
└──────┬───────────────────┬────────────────────┬───────────┘
       │ private network    │                    │
       ▼                    ▼                    ▼
  member-1 (MASTER)     member-2 (replica)   member-3 (replica)
  redis + sentinel      redis + sentinel     redis + sentinel
  full local copy       full local copy      full local copy
       └────────── replication ──────────────────►

The routing trick is a single health check: HAProxy runs AUTH → PING → INFO replication against each member, and only the current master reports role:master. So the :6379 endpoint always resolves to the master, and it follows a failover automatically.

what happens when the master dies

# Before: member-1 is master, the LB routes :6379 -> member-1
# member-1 crashes ↓

# 1. The Sentinels notice the master is gone
# 2. A majority agree and promote member-2 to MASTER (seconds)
# 3. member-2 now reports role:master; member-1 does not
# 4. HAProxy's health check moves :6379 traffic to member-2

# Your client: one dropped connection, then reconnect to the
# SAME endpoint — no host change, no config edit. New writes
# land on member-2. The dashboard + Activity tab record the
# promotion and a notification fires.

What your client sees: one dropped connection, then a normal reconnect to the same endpoint— no host change and no config edit. Use a client that reconnects (most do) and a failover is a brief blip, not an outage. The promotion lands in the Activity tab and fires a notification, and the dashboard shows each member's role.

Rolling updates

When OS or Redis updates are available, the cluster page shows a nudge. Applying them is a rolling, zero-downtime operation: Suble patches one member at a time so the cluster keeps serving throughout.

Replicas first, master last

Suble patches the replicas one at a time, waiting for each to re-link to the master before continuing. Only then does it fence writes and trigger a clean SENTINEL FAILOVER to an already-patched replica — so the master role moves cleanly and the ex-master is patched last, as a replica.

Self-healing

Between updates, Suble watches the cluster: if a member VM stops, it's powered back on and rejoins as a replica, and any node that wrongly believes it's the master is demoted to follow the elected one — so you converge back to exactly one master without lifting a finger.

a rolling update, step by step

# Cluster page -> Overview -> "Updates available" -> Update
# (or the Updates action). Suble rolls the update one member at a time:

# 1. Patch the replicas first, one per tick, waiting for each to
#    re-link to the master before moving on.
# 2. Fence writes, then SENTINEL FAILOVER to a freshly-patched
#    replica — the endpoint follows the new master.
# 3. Patch the ex-master last, now a replica.

# Your client: one dropped connection at the switchover, then a
# normal reconnect to the SAME endpoint. No data loss, no host change.

Configuration

Beyond the node count and plan, you can tune the Redis parameters that actually change behavior — eviction policy, connection limits, durability — from the cluster's Settings tab or the CLI.

An allow-list of real CONFIG keys

maxmemory-policy, maxmemory, maxclients, appendfsync, the RDB saveschedule, keyspace notifications and slowlog thresholds — the knobs that actually change behavior. Managed settings (auth, TLS, replication, HA write-safety) aren't on the list, so a cluster can't be misconfigured into an unsafe state.

Applied live, no downtime

Every key on the list is a runtime Redis setting. Changes go out as CONFIG SET to every member and are persisted with CONFIG REWRITE — no restart, no reconnect, no failover.

Sticks through scale, resize and self-heal

Your settings are stored on the cluster, not just the running members — so a node added by scaling up, a member replaced during a resize, or a self-healed replacement all come up already carrying your configuration.

tune it from the dashboard or the CLI

# Cluster page -> Settings tab -> Configuration
#   Eviction policy:  allkeys-lru   (default: noeviction)
#   Max clients:      20000         (default: 10000)
#   AOF fsync:        everysec      (default)

# Or from the CLI:
suble cluster config get my-redis
suble cluster config set my-redis maxmemory-policy=allkeys-lru maxclients=20000

# Reset a key to its default by setting it to an empty value:
suble cluster config set my-redis maxmemory-policy=

Backups & restore

Replication keeps you online; backups let you go back in time. Suble takes point-in-time RDB snapshots of your data to your own S3 bucket — scheduled and on demand — so you can recover from a bad FLUSHALL or a value overwritten an hour ago. HA and backups are different jobs: a replica faithfully copies the mistake, a snapshot lets you recover from before it.

Your own S3 bucket

Point backups at any S3-compatible bucket — AWS, Cloudflare R2, Backblaze B2 or similar. Give Suble an endpoint, bucket and access key (region defaults to auto, path to /); the secret key is write-once, stored encrypted and never shown again. Suble verifies the credentials live before saving. Snapshots live under a …/redis/<cluster-id>/ prefix, so a bucket you already use for Postgres backups won't collide.

BGSAVE snapshots

On schedule or on demand, the current master writes a fresh RDB with BGSAVE — a background fork, so your workload keeps serving — and Suble uploads the dump.rdb to your bucket. Set how many snapshots to keep; older ones are pruned from S3 automatically.

Restore into a new cluster

A restore never overwrites the running cluster. Pick a snapshot, give it a name, and Suble provisions a fresh cluster whose first member loads that RDB before Redis starts — so it comes up already holding your data. Inspect it, pull out what you lost, or cut over on your terms.

enable backups against your S3 bucket

# Console -> Clusters -> your Redis cluster -> Backups tab
#   S3 endpoint:  https://<accountid>.r2.cloudflarestorage.com
#   Region:       auto
#   Bucket:       my-suble-backups
#   Path:         /               (snapshots go under .../redis/<cluster-id>/)
#   Access key:   ...
#   Secret key:   ****   (write-once — stored encrypted, never shown again)
#   Schedule:     Daily snapshot
#   Retention:    7 snapshots

# Suble verifies the bucket (a real write+delete test), then the
# master runs BGSAVE and uploads dump.rdb to your bucket.

restore a snapshot -> a new cluster

# Backups tab -> pick a snapshot -> Restore
#   Snapshot:    20260719-013455   (an RDB you took)
#   New cluster: redis-restored

# Suble provisions a brand-new Redis cluster whose first member
# loads that RDB before Redis starts — so it comes up already
# holding your data, and replicas full-resync from it. Your live
# cluster is never touched — restore is always non-destructive.
# (An RDB is a point-in-time snapshot: you restore a whole
# snapshot, not an arbitrary second.)

An RDB is a point-in-time snapshot: a Redis restore brings back a whole snapshot you took, not an arbitrary second. (Postgres, with its continuous write-ahead log, additionally offers restore-to-any-second.) Restore is always non-destructive — it creates a new cluster and leaves the original running. Deleting a snapshot removes it from your S3 bucket and is permanent.

What it protects against

Replication keeps your Redis online through failures — but it is not a backup. Understand what each one covers.

High availability

If the master goes down, Sentinel promotes a healthy replica in seconds, keeping Redis online. Your data is continuously replicated to every node, and the :6379 endpoint follows the new master with no client reconfiguration.

Backups cover the other half

HA and backups solve different problems. Replication protects against a node dying right now; it does nothing about a bad FLUSHALL an hour ago — every replica faithfully replicates it. That is what RDB snapshots to your own S3 bucket are for — see Backups & restore above.

Pricing

There is no special "managed Redis" SKU. A database cluster costs the sum of its parts — the same per-resource meters as everything else on Suble, all metered hourly and capped monthly.

Member VMs

Each member is billed exactly like a standalone instance — its plan's hourly rate, capped at the monthly price. Three members cost three instances; scale down and the bill follows by the hour.

The load balancer

The managed LB that exposes the endpoints is billed at its size's rate. Reuse an existing load balancer and it is not billed twice.

The private network

The cluster's private network is metered hourly. Reuse an existing network and there is nothing extra to pay. Deleting the cluster releases everything it owns.

The dashboard shows the live monthly estimate as you size the cluster, and the cluster page breaks the running cost down by members, load balancer and network.

Reference

The choices you make when creating a Redis cluster, and what you manage afterward from the cluster page. For the shared infrastructure model — members, load balancer, private network — see the Clusters overview.

Create options

Options

`mode`required	`Database`	Choose Database (not Container) so the cluster runs a managed database engine instead of your containers.
`engine`required	`Redis`	The database engine. This page covers Redis.
`version`required	`7`	The Redis major version. Clusters run Redis 7 today; more versions are on the way.
`nodes`required	`1 or >= 3`	Member count. 1 = single, non-HA. 3+ = HA (one master + replicas, each with a Sentinel). 2 is not allowed — no safe Sentinel majority.
`plan`required	`string`	Member VM plan code (e.g. BXS.s1). Every member runs this plan, and each holds a full local copy of the data.
`network`	`string`	Private network the members + load balancer share. Auto-created with the cluster, or point it at an existing one. Redis is private-only.

Manage

On the cluster page

`Write endpoint (:6379)`	`read`	The single rediss:// host:6379 that always routes to the current master. Shown on the cluster page; use it for reads and writes.
`Read endpoint (:6380)`	`read`	A load-balanced host:6380 that routes across the replicas — use it to push read-only traffic off the master. (On a single node it maps to the one member.)
`Password`	`reveal`	A generated password (requirepass / masterauth), revealed on demand and owner-only. Every member and Sentinel shares it.
`CA certificate`	`download`	The cluster's public CA cert (rediss:// is always on). Download or copy it to pin the server in your client instead of skipping verification.
`Users`	`manage`	Redis ACL users with a read-write or read-only scope, applied to every member (so they survive a failover and work on the read endpoint). Passwords are shown once.
`Members & roles`	`read`	Each member's current role (MASTER / replica) and health — so you can see who leads and that the replicas are linked.
`Metrics`	`read`	Live per-member CPU, memory, disk and network, plus Redis stats — memory used vs max, connected clients, ops/sec, total keys and connected replicas — on the cluster's Metrics tab.
`Updates`	`one-click`	Rolling, zero-downtime OS + Redis updates: replicas first, then a clean Sentinel failover away from the master before it's patched. One dropped connection, no data loss.
`Configuration`	`tune`	Tune the Redis CONFIG keys that matter — eviction policy, max clients, memory cap, AOF durability, and more. Applied live to every member with CONFIG SET, no restart and no downtime.
`Backups`	`configure / restore`	Point backups at your own S3 bucket (live-verified on save): scheduled RDB snapshots plus on-demand. Restore a specific snapshot into a brand-new cluster (non-destructive).
`Activity`	`read`	Failovers, promotions and updates are recorded in the cluster's Activity tab and also fire a notification.