ZooKeeper Support Providers Compared: Instaclustr, Ksolves, Cloudera, Confluent and OSSeva

The short answer

Commercial ZooKeeper support comes in three shapes. A managed service runs ZooKeeper for you (Instaclustr). A support or services firm helps with the ensembles you run yourself (Ksolves, OSSeva). A distribution vendor supports the ZooKeeper inside its own platform (Cloudera for Cloudera Runtime, Confluent for Confluent Platform 7.x). The difference that matters most is version coverage. Upstream ZooKeeper patches only 3.8 and 3.9, and most of the installed base still runs 3.4 to 3.7. Of the providers below, OSSeva is the one that publishes patched builds for those end-of-life lines.

Every provider here was checked on its own website on 4 October 2026. Where a site does not say something, this guide says so rather than guess.

The providers at a glance

Instaclustr (NetApp)

Instaclustr, now part of NetApp, offers ZooKeeper as a managed service on its own platform, alongside managed Kafka, where its documentation covers Kafka clusters with dedicated ZooKeeper nodes and a ZooKeeper to KRaft migration process. Its lifecycle status page lists ZooKeeper 3.8.4 as Closed, with retirement expected in late 2027. Instaclustr defines Closed as still fully supported and tested, but available for new deployments only by exception. Versions 3.8.3 and below, 3.7.1, and 3.6 and below are Retired, meaning no longer available or supported on the platform.

Fits when: you want someone else to host and run the ensemble and you are on, or can move to, 3.8. Does not fit when: ZooKeeper must stay on your own hosts, or it is embedded in a product you cannot repoint at a managed endpoint.

Ksolves

Ksolves sells Apache ZooKeeper support packages for ensembles you run. Its ZooKeeper page lists 24/7 managed operations, SLA-backed technical support, zero-day vulnerability fixes, CVE monitoring and patch advisory for ZooKeeper and dependent components, rolling upgrades, Kafka ZooKeeper to KRaft migration, and security hardening with TLS, SASL and Kerberos. It mentions integration work for Kafka, HBase and Hadoop. The page does not publish a list of supported versions, and it does not say whether fixes are delivered as patched builds for 3.4 to 3.7 or as advice to upgrade. One customer example describes moving an ensemble from 3.4 to 3.8.

Fits when: you want a services team for tuning, upgrades and migrations across a wider big data estate. Ask first: which versions they patch, and in what form.

Cloudera

ZooKeeper is a component of Cloudera Runtime, built and versioned by Cloudera. Runtime 7.3.1, for example, ships Apache ZooKeeper 3.8.1.7.3.1.0-197. It is supported as part of a Cloudera subscription, for as long as the Runtime release is supported. Cloudera's lifecycle policy lists end of support in October 2028 for Base on premises 7.1.9, December 2026 for 7.3.1 and March 2032 for 7.3.2. Limited support for CDH 6.2 and 6.3 and HDP 3.1 ended in 2022, so ZooKeeper on those older distributions has no Cloudera coverage today.

Fits when: ZooKeeper runs inside a current Cloudera cluster. Does not fit when: the ensemble is standalone, or sits under CDH or HDP.

Confluent

Confluent supports ZooKeeper only as the metadata store for Kafka in Confluent Platform 7.x. Its interoperability table lists ZooKeeper 3.8.6 for Confluent Platform 7.7, 7.8 and 7.9. ZooKeeper was deprecated in 7.5 and removed in 8.0, and you cannot upgrade to 8.0 while still on ZooKeeper. Confluent Platform 7.9 is the last release with ZooKeeper; its support ends on 19 February 2027 for Enterprise Standard and 19 February 2028 for Enterprise Platinum.

Fits when: ZooKeeper exists only to run Confluent Platform 7.x Kafka and you plan to migrate to KRaft inside Confluent's dates. Does not fit when: the same ensemble also serves HBase, Solr or another product.

OSSeva

OSSeva ships patched, signed ZooKeeper builds for 3.4, 3.5, 3.6 and 3.7, the lines upstream no longer fixes, and supports 3.8 and 3.9. Fixes include the bundled dependencies that scanners flag, such as Netty, Jetty and log4j, delivered as Maven artifacts, Docker images or tarballs. Where ZooKeeper is embedded in Kafka, HBase, Solr or Hadoop, OSSeva patches it with the product above it and provides VEX attestation for findings against the embedded copy. Patch covers the builds, Assure adds the ensemble audit, a dependency map and compliance attestation, and Operate adds 24/7 ensemble operations with a 15-minute P1 response. See ZooKeeper extended support and ZooKeeper support for detail, and what runs on ZooKeeper for the products covered.

Fits when: ensembles on 3.4 to 3.7 cannot be upgraded on your schedule, or ZooKeeper is buried inside other products. Does not fit when: you want a hosted ZooKeeper endpoint that someone else runs on their own infrastructure.

Self-support

The Apache ZooKeeper project publishes advisories on its security page and releases for the 3.8 and 3.9 lines, with 3.9.6 as current and 3.8.7 as stable. Help comes from the mailing lists, with no response commitment. That is workable for teams already on 3.8 or 3.9 with JVM and quorum experience in-house. For 3.4 to 3.7 it means no fixes at all: CVE-2023-44981, a SASL quorum authentication bypass rated 9.1, has no fix on 3.4, 3.5 or 3.6. See the ZooKeeper end-of-life dates for each line.

What to ask a ZooKeeper support provider

1. Do you patch 3.4 to 3.7, and how? Ask whether the answer is a patched build, a configuration mitigation or a recommendation to upgrade. Ask for the fix they shipped for CVE-2023-44981 on 3.5 or 3.6, which upstream never fixed.
2. How do you handle CVEs upstream does not assess? The 2026 ZooKeeper advisories list only 3.8 and 3.9 as affected, because the project does not evaluate end-of-life lines. A provider should tell you whether each one affects your version, in writing.
3. What is the CVE SLA? Get the time from upstream disclosure to a patched build in the contract, separate from the incident response time.
4. Do you cover embedded ZooKeeper? Kafka, HBase, Solr and Hadoop ship their own ZooKeeper jars. Ask whether the provider patches the copy inside the product, and whether it issues VEX statements when a scanner finding is not exploitable in your configuration.
5. Do you patch the bundled dependencies? Older ZooKeeper releases bundle log4j 1.2.17 and old Jetty and Netty versions. A ZooKeeper fix that leaves those in place still fails a scan.
6. Where does it run, and who holds the pager? Hosted service, your hosts with their engineers, or advice only.
7. What is the exit plan? If the long-term goal is KRaft, ClickHouse Keeper or etcd, ask whether the same provider runs that migration. OSSeva does, through its ZooKeeper to Raft migration service.

How to choose

• On 3.8, happy to be hosted: Instaclustr, within its 3.8.4 lifecycle dates.
• Inside a current Cloudera or Confluent Platform 7.x cluster: the distribution vendor's own support, until its end-of-support date.
• Need hands-on services for tuning, upgrades and migrations: Ksolves or OSSeva, after confirming version coverage.
• On 3.4 to 3.7, on CDH or HDP, or with ZooKeeper embedded in several products: OSSeva, for patched builds and VEX attestation on the versions you actually run.
• On 3.8 or 3.9 with strong in-house skills: self-support can work, as long as someone owns the upgrade to each new patch release.