niceos/redis-cluster repository overview

⁠NiceOS Redis Cluster

NiceOS Redis Cluster is a Redis® Cluster container image built on NiceOS.Container.

It is designed for teams that need a self-managed Redis® Cluster with predictable container packaging, a controlled runtime environment, persistent data layout, cluster bootstrap automation, and compatibility with common Redis® Cluster deployment patterns.

This image is provided as a Bitnami-compatible migration target. It preserves the runtime conventions that many existing Bitnami-based deployments expect, while replacing the underlying base system with NiceOS.Container.

This is not an official Redis®, Bitnami, Broadcom, or VMware image.

⁠What is NiceOS.Container?

NiceOS.Container is a lightweight container-oriented build of NiceOS for infrastructure services.

NiceOS.Container images are built around several principles:

• minimal runtime composition;
• RPM/glibc-based package provenance;
• predictable filesystem layout;
• reproducible release metadata;
• fixed application and image revision tags;
• reduced runtime surface;
• no unnecessary package managers or build tools in the final image;
• container-native execution without systemd.

The goal is to provide application containers that are easy to audit, easy to update, and predictable in production.

⁠What this image provides

This image provides a Redis® Cluster runtime with:

• Redis® Cluster bootstrap logic;
• support for multiple Redis® nodes;
• Redis® Cluster slot allocation;
• replica configuration;
• persistent data under /bitnami/redis/data;
• Bitnami-style runtime paths under /opt/bitnami;
• non-root runtime user model;
• environment-based configuration;
• support for secret injection through environment variables;
• compatibility-oriented entrypoint, setup and run scripts;
• health-check friendly behavior for container platforms.

⁠Bitnami-compatible migration target

Many existing Redis® Cluster deployments, examples, charts and operational scripts expect Bitnami-style container conventions.

NiceOS Redis Cluster keeps the important runtime contract, including:

• /opt/bitnami layout;
• /bitnami/redis/data persistent data path;
• Redis® binaries available through Bitnami-style paths;
• Bitnami-style entrypoint and run behavior;
• common Redis® and Redis® Cluster environment variables;
• non-root container execution;
• compatibility with deployments that expect UID 1001;
• support for secret-driven configuration patterns.

The goal is to make migration easier for workloads that previously used Bitnami-style Redis® Cluster containers.

This image is not an official Bitnami image and is not presented as a vendor-certified replacement. It is a NiceOS-based compatibility image intended to preserve the practical runtime behavior needed by existing deployments.

⁠Image updates

NiceOS images are updated through a controlled release pipeline.

A new image revision may be published when:

• the upstream Redis® component is updated;
• NiceOS.Container packages are updated;
• security fixes are available;
• compatibility scripts are improved;
• runtime behavior or documentation is corrected;
• the image metadata, SBOM or registry publication data is refreshed.

Production users should prefer immutable tags or image digests instead of relying on latest.

Typical tag policy:

<application-version>-niceos<stream>-r<revision>
<application-version>
latest

Recommended for production:

niceos/redis-cluster:<immutable-tag>

Not recommended for production pinning:

niceos/redis-cluster:latest

The latest tag is a convenience channel and may move when a new release is published.

⁠Registries

The image is published to multiple registries as part of the NiceOS release process.

Primary public image:

docker.io/niceos/redis-cluster

Additional mirrors may be available through other registries such as GHCR, AWS ECR Public, or Yandex Container Registry, depending on the release.

For production deployments, use immutable tags or digests and verify the digest recorded in the release metadata.

⁠Persistent data

Redis® data is stored under:

/bitnami/redis/data

Mount this path as a persistent volume when running the container in production.

Example:

volumes:
  - redis-data:/bitnami/redis/data

⁠Configuration

The image is configured primarily through environment variables.

Common variables include:

REDIS_PASSWORD
REDIS_PORT_NUMBER
REDIS_NODES
REDIS_CLUSTER_CREATOR
REDIS_CLUSTER_REPLICAS
REDIS_CLUSTER_ANNOUNCE_IP
REDIS_CLUSTER_ANNOUNCE_HOSTNAME
REDIS_CLUSTER_ANNOUNCE_PORT
REDIS_CLUSTER_ANNOUNCE_BUS_PORT

For production, set a strong REDIS_PASSWORD and avoid exposing Redis® ports to the public Internet.

⁠Running a Redis Cluster

A Redis® Cluster requires multiple nodes. A typical deployment uses several containers connected through the same private network.

For local testing or single-host deployments, Docker Compose can be used to run multiple Redis® Cluster nodes on one host.

For production, place Redis® nodes in a private network, restrict access to trusted applications, use persistent storage, and define a backup and recovery procedure.

⁠Security recommendations

For production deployments:

• do not expose Redis® directly to the public Internet;
• use private networks and security groups;
• restrict access to trusted application servers;
• always set REDIS_PASSWORD;
• store secrets in a secret manager where possible;
• use immutable tags or digest-pinned images;
• monitor Redis® Cluster state;
• back up persistent data;
• review logs after restarts and upgrades;
• enable TLS when required by your security policy.

⁠NiceOS.Container advantages

NiceOS.Container images are intended for users who want more control over the container supply chain.

Key advantages:

• RPM/glibc-based base system;
• controlled build inputs;
• minimized runtime contents;
• predictable image revisioning;
• compatibility-focused filesystem layout;
• non-root runtime model;
• no systemd in the container runtime;
• no unnecessary compilers, package managers or build tools in the final image;
• release metadata suitable for cataloging and auditing;
• multi-registry publication workflow.

This makes NiceOS application containers suitable for environments where traceability, reproducibility and operational control matter.

⁠Compatibility notes

This image is designed as a compatibility-oriented migration target for Bitnami-style Redis® Cluster deployments.

It aims to preserve practical runtime compatibility, but it is not an official Bitnami image. Always test your own deployment manifests, environment variables, persistent volumes, network settings and application clients before production migration.

⁠Legal notice

Redis® is a trademark of its respective owner.

This image is not an official Redis® product and is not certified, approved, endorsed or sponsored by Redis Ltd. or its affiliates.

This image is not an official Bitnami, Broadcom or VMware product and is not certified, approved, endorsed or sponsored by those vendors.

NiceSOFT provides the container packaging, NiceOS.Container runtime environment, compatibility scripts, deployment metadata and release automation for running Redis® Cluster in container environments.

Redis® and other included components are distributed according to their respective upstream licenses.