Redis Stack
Reference for SeaGit’s Redis Stack template: a managed Redis-compatible store, Valkey 8.1 or Redis 8.2, running in a Kubernetes cluster in your own AWS account, backed up to your own S3 bucket. For a walkthrough, see Deploy Redis in Minutes. For when a cache helps and which settings fit, see Redis use cases.
What the Redis Stack is
The Redis Stack template deploys one Redis-compatible server into a cluster you choose, in your AWS account, from a single form. You pick who can reach it: apps in the cluster, anything in the VPC, or the internet over TLS with an IP allowlist. Backups go to S3 in the same account: one on deploy, one every night at 03:00 UTC, and a final one when you delete the stack. When it is ready, the Stack tab shows the endpoint, a masked password and ready-to-paste code for redis-cli, Node.js, Python, Go and a .env file. In live runs a stack was reachable about three and a half minutes after Deploy on a cluster that already existed; the template budgets five. Your data never leaves your account, and you pay AWS directly for the EBS volume, the load balancer (if any) and S3.
The template is available on paid plans. It needs a native (sgt-k8s) cluster with the EBS CSI add-on. If you do not have a cluster yet, Getting Started walks through creating one in your AWS account.
What gets deployed
One application with one component, redis: a release of the sg-redis Helm chart from charts.seagit.com, pinned to one cluster.
| Part | What it is |
|---|---|
| Redis or Valkey | A StatefulSet with one replica and its own EBS volume. AOF persistence is on. Pods are kept off spot nodes. |
| In-cluster service | <dep>.<space>.svc.cluster.local:6379, plain TCP. Always created, whatever you pick for reach. |
| Private load balancer | Only with Reachable from: My VPC. An internal Network Load Balancer on port 6379. |
| Public load balancer | Only with Reachable from: Internet. A dedicated internet-facing NLB. Port 6379 accepts TLS only, from the Allowed IPs. |
| Public name and certificate | <dep>.<environment domain>, with a cert-manager certificate. Redis reloads the certificate on renewal without a restart. |
| Backups | A CronJob and two Helm hooks that write gzipped RDB snapshots to S3 in the cluster’s AWS account. |
The password is generated for each stack and stored as a Kubernetes Secret. It is never put on a command line. Each reveal in the Stack tab needs update access to the app and is written to the audit log.
Options in the form
Engine
Valkey 8.1 (default) or Redis 8.2. Both speak the Redis protocol, so the same clients and commands work. Valkey is the Linux Foundation fork of Redis 7.2 under the BSD licence. Redis 8 is licensed under AGPLv3, RSALv2 or SSPLv1, at your choice; check that this suits how you use it.
Size
| Size | Memory limit | Data limit (maxmemory) |
|---|---|---|
| Small (default) | 128 MB | 96 MB |
| Medium | 512 MB | 384 MB |
| Large | 2 GB | 1.5 GB |
The data limit is lower than the memory limit so Redis has room for client buffers and copy-on-write during a snapshot. Storage is a separate EBS volume, 2 GiB by default, 1–500 GiB.
When memory is full
| Policy | Use it when |
|---|---|
| Refuse writes (noeviction) | The default. When data reaches the limit, writes fail with an OOM error and nothing is deleted. Use it when Redis holds data you cannot rebuild: sessions, queues, counters, locks. |
| allkeys-lru | Evicts the least recently used key, any key. The usual choice for a pure cache. |
| volatile-lru | Evicts the least recently used key among keys that have a TTL. Keys without a TTL are never evicted. Use it when one instance holds a cache (with TTLs) and data you must keep (without). |
| allkeys-lfu | Evicts the least frequently used key. Better than LRU when a small set of keys is read far more than the rest. |
Reachable from
| Choice | Who can connect | Cluster needs |
|---|---|---|
| This cluster only | Apps in the same cluster | Nothing extra |
| My VPC | The cluster plus anything in its VPC: ECS tasks, EC2, Lambda in the VPC, peered networks | Load Balancer add-on |
| Internet | Anywhere, over TLS, limited to the Allowed IPs you set | Load Balancer and cert-manager add-ons, and an environment domain |
Allowed IPs (Internet only) takes comma-separated IPv4 CIDRs, such as 203.0.113.7/32. The default, 0.0.0.0/0, lets anyone on the internet attempt a connection; TLS and the password are still required, and the Stack tab shows a warning. Addresses outside the list time out at the load balancer. Allowed IPs are fixed at deploy time in this version.
Connect
The Connect card on the Stack tab shows Provisioning until the load balancer has a healthy target, then Ready. It lists:
- Endpoint: the public name, the VPC load balancer or the in-cluster name, depending on reach. Port 6379, user
default. - TLS: required on the internet (
rediss://), off on private networks (redis://). - Password, URL and an In-cluster URL, masked until you choose Reveal.
- Allowed IPs, the Engine and the Backups location as an
s3://URI. - Code tabs for redis-cli, Node.js (ioredis), Python (redis-py), Go (go-redis) and .env.
TLS clients check the certificate against the system CA bundle, which macOS and most Linux distributions include. Docker images differ: checked from AWS on 11 October 2026, redis:8.2-alpine connected and verified the certificate, while the Debian-based redis:8.2 image failed with certificate verify failed until ca-certificates was installed.
# from your laptop, with redis-cli installed
redis-cli --tls -u "rediss://default:<password>@<dep>.<your domain>:6379"
# or with Docker (the -alpine image includes a CA bundle)
docker run --rm -it redis:8.2-alpine redis-cli --tls -u "rediss://default:<password>@<dep>.<your domain>:6379"Backups to S3
Backups always land in the AWS account that runs the cluster. Choose where in the form:
| Destination | Details |
|---|---|
| New bucket | SeaGit creates a bucket in the cluster’s AWS account. Leave the name empty for a generated one. Encryption: S3-managed keys, a new KMS key SeaGit creates (you choose its alias), or a KMS key you already have. |
| Existing bucket | A folder in a bucket you already own, in the same account. Access is limited to that folder. Optionally a KMS key ARN; empty uses the bucket’s default encryption. |
Three kinds of backup run:
- First backup, right after deploy, so the stack is never without one.
- Nightly, at 03:00 UTC, kept for the number of days you set (7 by default).
- Final, when you delete the stack, written as
final-<timestamp>.rdb.gz. If Redis is not running, the final backup cannot be taken: start the stack first, or choose Delete anyway.
Each backup is redis-cli --rdb (a point-in-time RDB snapshot taken over the replication protocol), gzipped, plus a _status.json with the last result. Inside the cluster, only the stack’s own service account has an IAM role for its bucket or folder.
Restore a backup
Restore is a manual procedure in this version. It replaces the stack’s data with a backup; anything written after that backup is lost. The steps were run verbatim on Redis 8.2 and Valkey 8.1 on 11 October 2026, and the full script is in Back up Redis to S3 and restore it. The short version:
- Scale the StatefulSet to 0 (or use Stop in the portal).
- Run a one-off pod with the stack’s service account that downloads the backup from S3 to the data volume.
- Install it as the base file of a new AOF:
appendonlydir/appendonly.aof.1.base.rdbplus a one-line manifest. - Scale back to 1 and check the log for “keys loaded”.
The AOF step matters. The server runs with AOF on, and Redis or Valkey 7 and later with AOF on and no AOF directory start empty and ignore dump.rdb. Copying the backup to dump.rdb, the usual advice, silently restores nothing.
Stop, start and delete
- Stop scales Redis to zero and keeps the volume. Start brings it back with its data (checked live on both engines).
- Delete takes a final backup, then removes the Kubernetes objects, load balancers, DNS name and volume. Backups in S3 stay unless you tick Also delete my backups; on an existing bucket that empties only the stack’s folder.
Limits in this version
- One node. A single replica with no failover and no Redis Cluster sharding. The pod restarts on failure and AOF keeps writes across restarts, but there is downtime while it does.
- Recovery point. If the EBS volume itself is lost, you can lose up to 24 hours of writes, back to the last nightly backup.
- Allowed IPs are set at deploy. Changing them means a new stack.
- AWS only.
For data that must survive a node loss with no downtime, or more than a few GB of memory, use a replicated managed service. See Do you need Redis Cluster?