# cassandra-reaper: scheduling and segmenting Apache Cassandra repairs across a cluster > Reaper is a centralized, stateful service that runs Apache Cassandra repairs for single or multi-site clusters, splitting them into segments and running several in parallel on different nodes, with a REST API, a spreaper command line tool and a local web UI. The trade-off is a stateful service with dated build constraints and no long-term compatibility promise. **thelastpickle/cassandra-reaper** — Automated Repair Awesomeness for Apache Cassandra - Repository: https://github.com/thelastpickle/cassandra-reaper - Website: http://cassandra-reaper.io/ - Stars: 523 · Forks: 241 - Language: Java - License: Apache-2.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/thelastpickle-cassandra-reaper ## Repairing a cluster is a scheduling problem, not a command problem Reaper is described as a centralized, stateful and highly configurable tool for running Apache Cassandra repairs against single or multi-site clusters. The mechanism it offers is specific: the current version supports running cluster repairs in a segmented manner, opportunistically running multiple parallel repairs at the same time on different nodes within the cluster, and basic repair scheduling functionality is also supported. That is the whole thesis. A Cassandra repair is heavy work that touches every replica of a key range, and running one across a whole cluster by hand means a person deciding what runs where and when, then watching it. Reaper takes that decision out of the operator's head and into a service: it splits the repair work into segments, and it can run more than one segment at once on different nodes when the cluster has the headroom. The word opportunistic matters. Parallelism is described as opportunistic rather than guaranteed, which tells you the service is not simply launching as many concurrent repairs as it can find nodes for. It is making a judgement about what the cluster can absorb at that moment. The audience is therefore operations staff, not developers, and the deployment unit is a cluster or a set of sites. Multi-site support is called out explicitly, which means the state model has to describe repairs that span locations rather than a single data centre. ## A database, a REST API, a CLI and JMX The system overview section of the README describes the architecture in four parts, and it is short enough to quote the structure without paraphrasing it away. Reaper consists of a database containing the full state of the system, a REST API, and a CLI tool called spreaper that provides an alternative way to issue commands to a running Reaper instance. Communication with Cassandra nodes in registered clusters is handled through JMX. Three consequences follow. First, JMX is the only channel to the nodes, so the repair logic runs against the node management interface rather than through the native protocol. Second, spreaper is a real client for the service, not a local script, so the same operations are available from a terminal and from the API. Third, everything about a cluster is registered state, and the state lives in the database. The project is built on top of Dropwizard, which is where the REST API, the configuration style and the packaging come from. The top-level layout matches that: a pom.xml for the build, src/ for the code, docs/ for the documentation tree, and the usual project files including a CHANGELOG.md and a CONTRIBUTING.md. The GitHub CI workflow badge points at the master branch, and the repository also carries a codecov configuration and a coverage badge, so the build is wired for automated verification rather than being a one-off assembly. ## No internal caches means the database is the truth One sentence in the README describes a design decision with real operational consequences: the system does not use internal caches for state changes regarding running repairs and registered clusters, which means that any changes done to the storage will reflect to the running system dynamically. That is a deliberate choice against a common pattern. Caching state in memory is faster and easier to reason about in a single process, and it lets a service keep working when its database connection hiccups. Reaper gives both of those up. The database is queried directly, so a change made by hand, by spreaper or by another Reaper instance is picked up by the running service without a restart and without a cache invalidation step. For an operator this cuts both ways. It means you can fix a stuck schedule by editing the state and see the effect, and it means there is no second copy of the truth to drift out of sync. It also means every read of cluster and repair state goes to the database, so the database is on the critical path for the service rather than being a passive archive. The same paragraph mentions the alternative: you can run Reaper with memory storage, which is not persistent and is meant to be used only for testing purposes. That is a testing convenience, not a production mode, and it is the reason the stateful deployment matters. ## The local web UI and the spreaper CLI cover the same ground Reaper comes with a GUI, which in local mode is served at http://localhost:8080/webui/. That address is the entire deployment note for the interface, which tells you the intended first run is on the machine of the person evaluating it rather than behind a reverse proxy in a cluster of services. The interface is the visible half of a design with two ways in. spreaper issues commands to a running Reaper instance, so an operator can drive repair scheduling from a shell, script it, or use it in an environment where a browser is not available. The REST API is the third door: anything the UI does is something the API exposes, which is what makes Reaper usable from an existing automation pipeline. Documentation is treated as part of the repository. The README says the full documentation is available on the Reaper website and that the source for the site is located in this repository at src/docs. So a fork or a private deployment can rebuild the documentation, and the docs track the code rather than drifting from it. For questions that the docs do not settle, the README points to two places: the Issues section of the repository, which it describes as the place for planned development and known issues, and the ASF Slack channel named cassandra-reaper. Neither is a support contract, but both are places where behaviour that is not written down can be found. ## The node toolchain assumptions are the first thing to check The version compatibility section is where a careful evaluator should start, because two of the constraints are old enough to be surprising. For the server side, Reaper can be built using Java 8 or 11, and it is tested against Cassandra 3.11 and 4.0. It is no longer tested against Cassandra 2.x. That gives a clear floor and a clear ceiling: a cluster on Cassandra 2.x is outside the tested range, and a build JDK other than 8 or 11 is not what the project describes. For the web interface build, the README is even more specific. The UI is confirmed to build with npm 5.6.0 and node 10.0.0. The project believes that more generally npm versions up to 6.14 and both node 12.x and 14.x will work. And it says plainly that builds are confirmed to fail with node 16 and later. The recommendation is to use nvm to manage node versions. That is a hard constraint for a modern CI pipeline. A team whose build agent has node 18 or 20 installed cannot build the UI as the project describes it, and the failure is confirmed rather than suspected. If you are evaluating Reaper in 2026, the practical first step is to pin a node version in your build environment with nvm and confirm the UI compiles before anything else. The same caution applies to Cassandra versions outside 3.11 and 4.0, including newer lines, for which the README makes no claim either way. ## Two licences and a fork relationship to know about The repository root lists LICENSE.txt and, next to it, LICENSE-EPL-2.0.txt, plus a NOTICE.md file. The project itself is licensed under Apache 2.0, and the second licence file belongs to the dependency. The README explains why that file is there. Reaper uses an unmodified EPL-2.0 licensed dependency, EclipseStore, and the source code for it is in its own GitHub repository. Because the dependency is used unmodified, the EPL-2.0 terms apply to that component as it is distributed, which is why the licence text is checked in alongside the project's own. This is a description of the terms and not a legal opinion. The practical questions for an evaluator are whether a redistribution of the assembled service triggers any obligation around the EPL-2.0 component, and whether an organisation's internal policy on copyleft-adjacent licences accepts that component. Both are questions for whoever owns that policy, and both are answerable from the two licence files in the repository root. The provenance is worth knowing as well. The README notes that this repository is a fork from the original Reaper project, created by the folks at Spotify, and the fork is maintained under the thelastpickle organisation. The README also directs questions to the ASF Slack channel, which places the project in a wider community context. Fork lineage and upstream divergence are exactly the things to check before committing to it as a long-term dependency. ## A maintained fork with two release lines The activity picture is healthy, and it has a shape. The last push was on 2026-10-20, and the recent releases are 5.0.1 from 2026-09-01, 4.2.7 from 2026-08-19 and 4.2.6 from 2026-08-18. Two things follow from that list. The 4.2.x line received two point releases three weeks apart in August 2026, which is the pattern of a maintained branch receiving fixes. The 5.0.1 release came later and sits on a different major line, so there is a newer major version available alongside a still-active 4.2.x branch. For an operator, that usually means a choice between staying on the branch that is being patched and moving to the major version when you are ready to absorb its changes. The fork relationship makes that choice more interesting than it looks, because the fork and the upstream project do not necessarily release in step, and the README tells you to read the Issues section for planned development and known issues. The CHANGELOG.md in the repository root is the other place to look for what changed between lines. Neither the README nor the listed files describe a deprecation policy for the older line. If you are considering a long-term deployment, treat 4.2.7 as actively patched rather than guaranteed supported, and read the Issues tracker for the fork's own view of the roadmap. ## Conclusion cassandra-reaper fits an operator who repairs a cluster large enough that doing it by hand node by node stops being reasonable, and who wants segmented repairs, parallel execution and scheduling with the state kept in a database rather than in a runbook. It does not fit a cluster on Cassandra 2.x, a team still on Node 16 or later for the UI build, or anyone who needs a stateless deployment, since the memory storage mode is documented as being for testing only. Verify first that your Cassandra version falls inside the tested range of 3.11 and 4.0, that your build JDK is 8 or 11, and that the EclipseStore EPL-2.0 dependency at the root of the repository fits your own distribution policy. ## FAQ ### What does cassandra-reaper actually do? It is a centralized, stateful and highly configurable tool for running Apache Cassandra repairs against single or multi-site clusters. It runs repairs in a segmented manner, can run several parallel repairs on different nodes in the cluster at the same time, and supports basic repair scheduling. ### What are the components of cassandra-reaper? A database holding the full state of the system, a REST API, a CLI tool called spreaper that issues commands to a running instance, and JMX for communication with the nodes of registered clusters. The project is built on top of Dropwizard. ### How do I open the cassandra-reaper web UI? In local mode the GUI is served at http://localhost:8080/webui/. The full documentation is on the Reaper website and its source is in this repository under src/docs. ### Can cassandra-reaper run without a persistent database? There is a memory storage mode, and the README states that it is not persistent and is meant to be used only for testing purposes. The system does not cache state changes, so changes written to storage are reflected by the running system dynamically. ### Which Cassandra and Java versions does cassandra-reaper support? Reaper can be built using Java 8 or 11, is tested against Cassandra 3.11 and 4.0, and is no longer tested against Cassandra 2.x. The web interface build is confirmed to fail with node 16 and later. ### What licences apply to cassandra-reaper? The project itself is under Apache 2.0, and the repository also contains LICENSE-EPL-2.0.txt for the unmodified EclipseStore dependency, which is EPL-2.0 licensed. The repository is a fork of the original Spotify project. ## Sources - [License: Apache-2.0](https://github.com/thelastpickle/cassandra-reaper/blob/master/LICENSE) - [Project website](http://cassandra-reaper.io/) - [README](https://github.com/thelastpickle/cassandra-reaper/blob/master/README.md) - [Releases](https://github.com/thelastpickle/cassandra-reaper/releases) - [thelastpickle/cassandra-reaper on GitHub](https://github.com/thelastpickle/cassandra-reaper) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/thelastpickle-cassandra-reaper