CacheCloud: a self-hosted Redis management platform from Sohu TV

The problem CacheCloud solves for Redis operators

Running one Redis instance is a config file. Running hundreds is a scheduling problem: which host has memory left, which app owns which instance, who restarted what, and why a Sentinel failover happened at 3am. CacheCloud targets that second situation. The README describes it as a Redis cloud management platform that supports Standalone, Sentinel and Cluster architectures, with the stated goal of reducing large-scale Redis operation and maintenance costs and improving resource management and utilization.

The repository states the scale it was built against: more than 80 billion commands per day, over 18T of total memory, 420+ applications and 4800+ instances, across 80+ physical machines and 360+ Kubernetes pods. Those are the project's own operating numbers from Sohu TV, not an independent benchmark. They are still useful as a sizing signal: this is a platform designed for an internal Redis fleet, not for a developer who wants a nicer redis-cli.

The audience follows from that. Platform and infrastructure teams inside a company that owns its own machines, or its own Kubernetes cluster, and wants Redis provisioning and monitoring to be a self-service web workflow. If your Redis is a managed service from a cloud vendor, most of what CacheCloud does is already someone else's job.

How CacheCloud is structured: web app, custom layer, ECS module

The top-level repository layout is the fastest way to understand the architecture. There are three modules plus the root build file: cachecloud-web, cachecloud-custom, and redis-ecs, with pom.xml at the root. This is a Maven multi-module Java project.

cachecloud-web is the application itself. The README's image paths point into cachecloud-web/src/main/resources/static, which is where the wiki pages, quickstart guide and client access documentation live. That tells you the web module serves both the operational UI and the documentation that ships with it.

redis-ecs is a separate module, and the name matches the README's claim of support for physical machines and Kubernetes pods as hosting environments. Keeping host-side concerns in their own module rather than inside the web app is the right split: the control plane and the thing that actually touches Redis hosts fail independently.

The functional breakdown in the README lists five areas: Redis provisioning (host initialization, instance deployment, architecture support), operations management (host environment, resource management, application audit, application operations, quality monitoring, diagnostic analysis), statistics and monitoring (log collection, instance collection, machine collection, application statistics, alerting, problem diagnosis), client access (SDK access, language access, client monitoring), and elastic scaling (resource contraction, application scaling, external access). Notice how much of that list is collection and diagnosis rather than provisioning. The provisioning is the easy part; the platform is mostly a data pipeline about Redis.

Building CacheCloud and getting to a first application

The README does not contain install commands. It links to a Quickstart page inside the repository at cachecloud-web/src/main/resources/static/wiki/quickstart/index.md, and to a Client page at cachecloud-web/src/main/resources/static/wiki/access/client.md. Those two files are where the actual setup steps live, and you should read them from the repository rather than from any summary, including this one. Because the README gives no build command, this article does not print one either: copy the commands from the quickstart page itself so you are working from what the maintainers actually support.

What the repository layout does tell you is the build system. The root pom.xml means the project builds with Maven, and the three modules are built together. The README does not state the required JDK version, so check the pom.xml before you start; a Java web application of this vintage is unlikely to be version-agnostic.

There is also a hosted demo linked from the README at http://43.137.44.6:8080/admin/app/list. The README presents it as a trial deployment on public resources, and notes that community members with public resources can contribute to it. Treat it as a look at the UI, not as a place to put anything you care about.

For client integration, the README points at the access documentation rather than showing code. It lists jedis and lettuce among the repository topics, so those are the Java clients the platform expects to integrate with. The access page is the source of truth for how an application registers and obtains its connection information.

Where CacheCloud is the wrong tool

CacheCloud is a control plane for Redis you host yourself. If you do not host Redis, the platform has little to do. A team using a managed Redis offering gets provisioning, failover, monitoring and alerting from the provider, and adding CacheCloud on top means running a Java web application plus its database and its host agents to manage instances that someone else already manages.

Scale is the other boundary. The README's own numbers describe a fleet of 420+ applications and 4800+ instances. The operational overhead CacheCloud introduces, a web app, a custom module, an ECS module, host initialization and collection pipelines, is fixed. For ten Redis instances, that overhead is larger than the problem it solves. The README does not document a lightweight mode or a single-node evaluation path.

The repository's primary language is listed as HTML, which is misleading but informative: a large share of the tracked content is the web UI and the wiki pages that ship inside cachecloud-web. If you are evaluating the project by reading code, expect to spend time in templates and static assets, not only in Java.

Finally, the README does not document rollback behavior for provisioning or scaling operations. Elastic scaling and application scaling are listed as features, and resource contraction is named, but the documentation visible here does not describe what happens when a scale-down is interrupted or a migration fails. That is a gap worth probing in the wiki before you trust the platform with production capacity changes.

CacheCloud compared with running Redis through a cloud vendor

The README includes cost comparison images for Redis master-replica and cluster deployments, under the heading comparing CacheCloud with cloud vendors. The argument is straightforward: if you already own the machines, the marginal cost of a self-managed Redis instance is the memory and the operational labor, while a managed service bills per instance or per capacity unit. The images are the project's own comparison and should be read as such.

The difference in approach is real, though. A managed Redis service gives you an API, a control plane maintained by the vendor, and a support relationship. CacheCloud gives you a web UI, host agents, and the responsibility. You gain control over placement, memory overcommit ratios, and the ability to mix physical machines with Kubernetes pods, which the README lists as supported hosting environments. You lose the vendor's on-call.

There is a middle path the README implicitly acknowledges: the platform supports external access and client integration, so it can sit in front of Redis that it did not provision. That is a legitimate use, using CacheCloud mainly for application-to-instance mapping and monitoring. But the README does not document how complete that mode is compared with fully managed instances, so verify it before designing around it.

Licence, maintenance and upgrade cost

CacheCloud is licensed under Apache-2.0. That permits commercial use, modification and redistribution, and it includes an explicit patent grant. It does not require you to publish your modifications. This is a permissive licence, and it is the same licence used by a large share of the Java ecosystem, so it is unlikely to raise questions in a corporate legal review. None of this is legal advice; read the LICENSE file in the repository root.

The repository is not archived. The most recent release is 3.4, dated 2026-06-08. Before that, 3.3-v2 came on 2024-08-05 and 3.3 on 2024-06-26. The last push to the default branch was on 2026-06-08, the same day as the 3.4 release.

That release history is worth reading carefully. There is a two-year gap between 3.3 and 3.4. A project that ships a major release every two years and then tags one on the same day as the last commit is not a fast-moving codebase. Upgrades are therefore infrequent but also potentially large: going from 3.3 to 3.4 may span two years of accumulated changes, and the README does not document an upgrade procedure or a migration path between versions. Plan to test an upgrade against a copy of your data rather than assuming an in-place jump.

The Apache-2.0 licence also means you can fork if the release cadence does not match your needs. Given the gap between 3.3 and 3.4, that is a realistic option for a team that depends on the platform.

Editorial conclusion

Adopt CacheCloud if you run many Redis instances across many hosts and want provisioning, monitoring and client integration behind one web UI instead of a pile of scripts. Do not adopt it if you run a handful of Redis instances, or if your Redis lives entirely inside a managed cloud service you do not control. Before committing, verify the Java and Maven versions the build expects, check that the quickstart wiki matches your environment, and confirm the client SDKs you need are listed in the access documentation.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. sohutv/cachecloud on GitHub