Managed Redis

Redis 8 is part of the managed database development baseline introduced in self-hosted alpha.37. Controller and storage setup remain separate operator tasks. The details below describe the current implementation and must be matched to the installed release; they do not establish production or physical multi-zone availability.

Data members and the operator#

Hakopod records a database's project, environment, revision, allocation and lifecycle operation. The credential-safe Opstree Redis operator manages the native members. Application replica counts do not resize the database.

Standalone uses one Redis member. Redis Cluster supports three to sixteen shards with one or two replicas per shard, within the 48-member limit. Each shard primary owns a part of the slot space; its replicas copy that shard. Automatic recovery needs a majority of primaries and reachable replicas.

schema_version = 1
name = "sessions"
engine = "redis"
version = "8"
mode = "cluster"
shards = 3
replicas = 1
cpu = "250m"
memory = "256Mi"
storage_gib = 1

[tls]
mode = "required"

[placement]
spread = "nodes"

This asks for six data members and six volumes. Strict node spreading requires six eligible nodes; a small two-node fixture cannot satisfy it. Capacity includes replacement, sandbox and recovery overhead. Requested storage is not a measurement of bytes used.

Use a cluster-aware client#

An application must follow slot ownership and MOVED/ASK redirections. The initial address is a discovery point; every advertised member needed for requests must be reachable. A generic TCP proxy cannot supply the missing client behavior.

[services.api.bindings.REDIS_URL]
managed_database = "DATABASE_ID"
protocol = "redis"
endpoint = "cluster"
cluster_aware = true

Review the binding before application deployment. The runtime supplies the restricted application account and public trust to that service and creates scoped network grants. Clients must verify hostname and issuer when TLS is required. Read the routing and security guides for shared connection behavior.

Resize with current evidence#

Edit the shard count in the versioned configuration, then review the exact change:

hakopod database resize-plan DATABASE_ID --file redis.toml
hakopod database resize DATABASE_ID --file redis.toml --review-id REVIEW_ID --revision REVISION

Acceptance checks current health, complete slot ownership, observed topology and a verified backup from the last hour. The backup must belong to the correct database revision. The worker rechecks evidence before mutation; stale health cannot approve a resize. Clients must handle changing slot ownership during the operation.

Removing shards can leave retained volumes. Their allocation remains reserved until the exact owned data is reclaimed. A smaller observed member count is not proof that storage has been released.

Backup and isolated recovery#

Redis archives preserve values and absolute expiry. Capture is consistent per shard, not one atomic transaction across the entire cluster. The recovery path supports individual values up to 64MiB; larger values fail explicitly. Check the workload's value sizes before relying on this path.

Recover into a separate compatible empty target. Authenticate the complete archive before writes, preserve the source and keep application access isolated through recovery and inspection. A failed restore may leave a partially populated target; discard it and use a fresh empty target for another attempt.

The import API accepts a standalone Redis 8 RDB archive with matching format and original version metadata. Format number alone cannot prove its Redis major version. Review the checksum and capture-time attestation; Hakopod does not infer capture time from a local file timestamp.

Operator and verification boundary#

The selected Redis operator build uses a credential-safe upstream commit. The released 0.26.0 controller image is not accepted because command failures can expose passwords. The build pins source, builder and runtime images; admission checks the approved digest, source annotation, command timeout and rollout.

The controller's bounded command timeout must accommodate real shard reduction. The development installer requires k3d-hakopod-dev; it must not be used against an operator cluster. Use the pinned release guide and the installed release's controller instructions.

Native lifecycle, slot movement, recovery, security and application binding tests must match the source being released. A healthy two-node fixture cannot establish physical zone/provider resilience. Use a disposable restore rehearsal before relying on the integration for an application.