# Lenses Stream Reactor is an Apache 2 licensed set of Kafka connectors > Stream Reactor is a collection of Kafka Connect sources and sinks maintained by Lenses.io, covering Cassandra, MongoDB, Elasticsearch, S3, MQTT, JMS, HTTP, FTP and more. The connectors are open source under Apache 2, the support policy is explicit about which major versions get fixes, and the deprecation list says which connectors are on their way out. **lensesio/stream-reactor** — A collection of Kafka Connect sinks and sources maintained by Lenses.io. - Repository: https://github.com/lensesio/stream-reactor - Website: https://lenses.io - Stars: 1,069 · Forks: 379 - Language: Scala - License: Apache-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/lensesio-stream-reactor ## One repository, a shelf of connectors The project describes itself as a collection of Kafka Connect sinks and sources maintained by Lenses.io, and the readme claims the position of being the leader in offering Apache 2 licensed Kafka Connectors, Stream Reactor, since 2016. The claim about the licence is the important one for an adopter, because Kafka connectors are exactly the kind of component that tends to live behind a commercial licence. Everything in this repository is Apache 2, and the FOSSA badge in the readme is the licence scanning service confirming it. The shape of the repository shows how many connectors there are. Each one is a directory named for what it talks to: kafka-connect-cassandra and kafka-connect-cassandra-sink, kafka-connect-mongodb, kafka-connect-elastic6 and kafka-connect-elastic7 with a shared elastic-common, kafka-connect-opensearch, kafka-connect-aws-s3, kafka-connect-azure-cosmosdb, kafka-connect-azure-datalake, kafka-connect-gcp-storage, kafka-connect-http, kafka-connect-ftp, kafka-connect-jms, kafka-connect-mqtt, and a kafka-connect-sql-common for the database family. There are also shared modules, kafka-connect-common, kafka-connect-cloud-common and kafka-connect-aws-s3 as a separate directory, plus a java-connectors directory and a project directory for the sbt build definition. The topic list adds the systems the connectors are expected to reach, with awss3, azure-datalake, cassandra, cosmosdb, elasticsearch, eventhubs, gcp, http, influxdb, jms, mongodb, mqtt, pubsub and s3. The audience is a team running Kafka Connect who needs to move data between Kafka and a system that has no first party connector, and who wants the connector code to be open and auditable rather than a jar from a vendor with a licence attached. ## The support policy says which versions get fixes Most open source projects are vague about this. The readme here is not. Under the standard support agreement, assistance is provided for the current major version and the preceding major version exclusively. The example given is that if version 8.x is the current major release, support covers the 8.x and 7.x series. Enterprise level support commences from version 7.0 onwards. Then there is the statement about how fixes are prioritised. Lenses prioritizes backporting fixes rather than incorporating new features, and does this on a limited basis across select prior releases. And the last line is the one that saves an operator time: if you contact support about an unsupported version, they will point you at the policy and encourage you to upgrade. That combination, a two major version window, fixes rather than features, and no support for anything older, is a coherent commercial policy and an unusual amount of clarity for a readme. It also tells you something about how to use the project. A connector on an older major version is not a liability you can carry indefinitely, and the natural rhythm is that you upgrade your Kafka, which moves you to a newer Stream Reactor, which moves you to a newer major line, which is where the fixes are. There is a parallel commercial layer. Lenses offers a developer experience solution for engineers building real-time applications on any Apache Kafka, and subscribed customers are entitled to full 24x7 support for selected connectors, including priority over feature requests and security incident service level agreements. ## The Kafka compatibility table is a migration tool in disguise There is a Kafka Compatibility section in the readme, and it is worth reading as a table of transitions rather than a list of versions. Kafka 2.8 through 3.5, which is Confluent 6.2 through 7.5, maps to Stream Reactor 4.1.0 and later. Kafka 3.1 on Confluent 7.1 maps to Stream Reactor 4.0.0, and the Kafka 2.8 build maps to 4.0.0 as well. Kafka 2.5 on Confluent 5.5 maps to Stream Reactor 2.0.0 and later. And Kafka 2.0 through 2.4 on Confluent 5.4 maps to Stream Reactor 1.2.7. Read as a whole, that is a story about three generations of the connector set. There is a 1.x line, a 2.x line, a 4.x line, and the current one is 12.x. The gap between 4.1.0 and 12.x in the readme's own numbering is a reminder that the version line has moved a long way from the Kafka releases the table was written for, and the table's top entry, Kafka 2.8 to 3.5, stops short of the Kafka versions current in 2026. So the table is a starting point rather than the whole answer. The release notes at the Lenses documentation site are where the mapping for a recent Kafka version would be, and the practical check for an adopter is to find the Stream Reactor release that matches the Kafka version you actually run, and to read the release notes for that line rather than assuming the top row applies. The current release history is 12.1.0 on 2026-07-31, 12.1.1 on 2026-08-26 and 12.1.2 on 2026-09-14, and the repository was pushed to on 2026-10-12, so the 12.x line is where work is landing. ## The deprecation list tells you which connectors are leaving The readme carries a deprecation notice, and it is two paragraphs that say a lot about the state of the connector set. First, in the next major release, Elasticsearch 6 support will be removed, to be replaced with OpenSearch and Elasticsearch 8 support. The replacement is visible in the repository, where kafka-connect-elastic7, kafka-connect-opensearch and a shared kafka-connect-elastic-common sit alongside the older kafka-connect-elastic6. Second, a list of connectors that have been deprecated and are no longer included in future releases: Elasticsearch 6, Kudu, Hazelcast, HBase, Hive and Pulsar. That list covers a lot of ground. A connector set that carried connectors for all of them was a broad one, and saying plainly which ones are not coming back is more useful than letting them rot. There is a wrinkle visible in the tree, which is worth knowing before you plan an upgrade. The kafka-connect-elastic6 directory is still present, and the end to end test instructions in the readme still ask you to build an elastic6 assembly before running the tests. So the deprecated connector is still in the source at the moment, and the removal is announced for the next major release rather than done. If you are on Elasticsearch 6, that is a scheduled migration to plan for, not a hypothetical one. The changelog also mentions a series of next generation connectors in active development, with an invitation to send feedback about which connectors should be worked on, which is a reasonable way for a connector suite to evolve given the pace of the systems it targets. ## Building is sbt, and each connector is its own project The build is sbt, and the readme gives the four commands that matter. A full compile and a full test: ```bash sbt clean compile sbt test ``` Assemblies, which is how a connector is packaged for deployment into a Connect worker: ```bash sbt assembly ``` And the useful part, which is building one connector rather than all of them. The project names in the examples are the connector names, so: ```bash sbt "project cassandra" compile sbt "project cassandra" test sbt "project cassandra" assembly ``` That matters more than it looks. A connector suite this wide does not need to be built in full to contribute to one of them, and the per project targets mean the edit, test, assemble cycle for a single connector is much shorter than a full multi module build. The repository shows the rest of the tooling. There is a build.sbt and a project directory for the build definition,.scalafmt.conf and.scalafix.conf for formatting and linting,.jvmopts and.sbtopts for JVM and sbt settings, a suppression.xml, and a WORKFLOW.md that the readme points to for a detailed explanation of the GitHub Actions setup. There are also dev-scripts, a smart-build.sh, an int_test.sh and an import-public-pr.sh, and a benchmarks directory, plus ADOPTERS.md, which is a separate document about the adapter architecture. ## End to end tests need the connector archives built first The end to end test section contains the kind of instruction that saves an hour, because it states a precondition that is easy to miss. If the connector archives are not already built, you must first build them. The readme lists the four that the end to end suite needs: ```bash sbt "project cassandra" assembly sbt "project elastic6" assembly sbt "project mongodb" assembly sbt "project redis" assembly ``` And then the tests run with: ```bash sbt e2e:test ``` The reason is that these are not unit tests with mocks. An end to end test of a Kafka Connect source starts the connector, points it at a real system, and checks what lands in the topic. The connector under test is loaded the way a real worker loads it, from a packaged archive, so the archive has to exist before the suite can use it. The redis connector is a good illustration of why this matters, because the test needs a real Redis to talk to and the connector needs to be a distributable unit to be pointed at it. Two other details in the same area are worth noting. There is a separate int_test.sh script in the repository root, suggesting an integration test path distinct from the sbt e2e task, and the readme notes that the archives must be built first, which implies the end to end suite does not do that for you. ## Where the open source ends and the commercial tier begins The split between what the repository gives you and what Lenses sells is the thing to hold on to when you evaluate this. The repository is Apache 2, which means the connector code, the build, the tests and the deprecation policy are all there for anyone to use, fork or audit, and the readme says so directly, that Lenses is the leader in offering Apache 2 licensed Kafka Connectors since 2016. What is sold is support and, in the wider Lenses product, a developer experience solution for building real-time applications on Kafka. Subscribed customers get 24x7 support for selected connectors, priority over feature requests, and security incident service level agreements, and the support policy is tied to that arrangement, with assistance for the current and preceding major versions and enterprise support starting at version 7.0. So the realistic adoption picture is that the connectors themselves are free and complete, and the paid layer is what a large organisation buys when a connector outage in production becomes an incident with a name attached. That is a cleaner arrangement than the alternative, where the open source is a sample and the real connector is behind a login, and it is why the support policy is written with the precision it is. The one thing to check before committing is the deprecation list against your own estate, because the connectors that are leaving are not a small set. If your pipeline depends on Elasticsearch 6, Kudu, HBase, Hive, Hazelcast or Pulsar, then the adoption question is not whether Stream Reactor is good but when the connector you rely on is going away, and the answer the readme gives is the next major release. ## Conclusion Stream Reactor is worth adopting if you run Kafka Connect and want connectors under the Apache 2 licence with a vendor that states its support window in writing, because the set is broad and the compatibility matrix tells you exactly which Stream Reactor version matches your Kafka version. It is the wrong choice if you need a connector that was deprecated, since Elasticsearch 6, Kudu, Hazelcast, HBase, Hive and Pulsar are no longer included in future releases, and it is the wrong choice if you need a feature that only arrives in the commercial tier. Before you deploy, read the version support policy against the major version you are on, and note that the current release is 12.1.2 from 2026-09-14 while the repository was pushed to on 2026-10-12. ## FAQ ### What is Lenses Stream Reactor? It is a collection of Kafka Connect sources and sinks maintained by Lenses.io, covering systems including Cassandra, MongoDB, Elasticsearch, OpenSearch, AWS S3, Azure Cosmos DB, GCP storage, HTTP, FTP, JMS and MQTT. The connectors are released under the Apache 2 licence. ### Which Stream Reactor version matches my Kafka version? The readme gives a compatibility table: Kafka 2.8 to 3.5 on Confluent 6.2 to 7.5 uses Stream Reactor 4.1.0 and later, Kafka 3.1 and Kafka 2.8 use 4.0.0, Kafka 2.5 uses 2.0.0 and later, and Kafka 2.0 to 2.4 uses 1.2.7. The release notes at the Lenses documentation site cover the newer lines. ### Which Stream Reactor connectors are deprecated? The readme lists Elasticsearch 6, Kudu, Hazelcast, HBase, Hive and Pulsar as deprecated and no longer included in future releases, and says that in the next major release Elasticsearch 6 support will be removed and replaced with OpenSearch and Elasticsearch 8 support. ### How do I build a single connector in Stream Reactor? The build is sbt, and the readme gives the per project targets, for example sbt "project cassandra" compile, sbt "project cassandra" test and sbt "project cassandra" assembly. The full build is sbt clean compile, sbt test and sbt assembly. ### What do I need before running the Stream Reactor end to end tests? The connector archives have to be built first, so the readme asks you to run sbt "project cassandra" assembly, sbt "project elastic6" assembly, sbt "project mongodb" assembly and sbt "project redis" assembly, and only then sbt e2e:test. ## Sources - [lensesio/stream-reactor on GitHub](https://github.com/lensesio/stream-reactor) - [License: Apache-2.0](https://github.com/lensesio/stream-reactor/blob/master/LICENSE) - [Project website](https://lenses.io) - [README](https://github.com/lensesio/stream-reactor/blob/master/README.md) - [Releases](https://github.com/lensesio/stream-reactor/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lensesio-stream-reactor