Nussknacker: a visual decision engine for acting on Kafka streams

Decisions as scenarios, authored by people who are not programmers

Nussknacker is a low-code visual tool for domain experts to build, run and monitor real-time decision algorithms, instead of implementing them in code. The framing in the README is that every IT system makes decisions continuously, and it lists them plainly: which offer a customer gets, who receives a marketing message, whether a device needs servicing, whether something is fraud.

Such algorithms can be written by programmers. The claim is that with Nussknacker they can be authored and deployed without involving IT, and the visual design tool is the essential part. The unit of work is called a scenario, and it is assembled from prebuilt components covering routing, filtering, data transformations, aggregations in time windows, enrichments from external databases or OpenAPI endpoints, and applications of machine learning models. Once authored, a scenario is deployed for execution with a click of a button, and it can be changed and redeployed whenever there is a need.

The project frames itself against data at rest rather than against other streaming tools. The argument is that spreadsheets have made it possible for hundreds of millions of non-programmers to work with static data, and the same should be possible with real-time data. Splitting the work that way is the design principle: domain experts own the decision logic, and developers take on the problems that are beyond the reach of a low-code tool.

Two processing modes decide what the data looks like at the edges

The available components and the shape of the data depend on the processing mode and the engine, and Nussknacker supports two processing modes.

In streaming mode, Kafka is the primary interface, with input streams of data and output streams of decisions. This is the mode the tool was built around, and it is where the time window aggregations live, which the documentation notes are available on the Flink engine only. A scenario reads from topics and produces decisions to other topics, and the operational model is a running deployment rather than a request.

In request-response mode, the tool exposes HTTP endpoints with OpenAPI definitions. Here the scenario is a synchronous decision service, something an application calls and gets an answer from. The difference matters for how you design the logic, since a request-response decision has no window to aggregate over in the same way, and the set of usable components differs between the modes.

A third mode, batch processing, is in active development and planned for a later release, with a preview available through a blog post on the project site. That is worth knowing before you plan around it, since a batch pipeline is a different proposition from a live decision and the tool does not yet cover it.

SpEL is the glue, and the components are function calls in it

The technical centre of the tool is SpEL, an expression language used to make the prefabricated blocks flexible enough for any transformation or flow control condition.

What that buys you in practice is that every component reads as a function call inside an expression. The documentation makes this point about enrichments, and it is the reason the tool holds together. A scenario that filters records, joins them against a SQL lookup, calls an OpenAPI endpoint, applies a model and writes a decision is one expression per step, and the author never leaves that language.

The enrichment types are SQL, OpenAPI and ML, and all three being function calls is what keeps them from adding complexity to the authoring experience. This matters most in the case the documentation calls out, where the incoming data is thin. Call data records, clickstream and sensor readouts all carry little information on their own, so after the initial filtering the data usually has to be brought in from somewhere else, and a tool that made that a different kind of step would break the flow of the editor.

The Designer is not a diagram-only environment either. It has built-in syntax checking, code completion, versioning, debugging and testing support, which the documentation frames as the condition for a low-code tool to be treated as a professional developer toolkit rather than a toy.

Observability that goes past throughput and Kafka lag

The monitoring argument is specific and, in a way, more interesting than the rest of the low-code pitch. The documentation argues that experimenting with algorithms requires insight beyond pure technical metrics like throughput and Kafka topic lag, and that the integrated monitoring subsystem allows monitoring not only the technical aspects of a running scenario but also its internal behaviour, giving the event count per scenario step as the example.

That is a different question from whether the pipeline is keeping up. It asks which branch of the logic the traffic is actually taking, which is what you need when a decision model is being tuned in minutes rather than in code review cycles.

The architecture story is deliberately borrowed from proven infrastructure. The claim is that Nussknacker achieves throughput, horizontal scalability, resilience and high availability through Kafka, Flink and Kubernetes, which handle all processing tasks. The tool is the authoring and deployment layer on top, not the engine, and the repository layout reflects that division with separate modules for the engine, the scenario compiler, the components, the designer, the live data collector and the security layer.

The metrics story also connects to the experimentation promise. The project claims that iteration time, from implementing a change and deploying it to seeing the result, should be in single minutes if not seconds, and that non-technical users can get below one minute. Monitoring is what makes that loop closed rather than open ended.

A Scala codebase on Flink, with the build and test surface to match

The repository is a large Scala project, built with sbt, and the tree shows what a platform of this kind accumulates.

The build files are build.sbt at the root with a version.sbt, an sbtwrapper directory so the correct sbt version comes with the checkout, and .sbtopts for the sbt options. The code style is enforced by .scalafmt.conf and .scalafix.conf, plus scalafix-rules/ for custom rules, and there is a .sdkmanrc for the Java version. The continuous integration entry points are visible in ciRunSbt.sh and checkStagedBackendFiles.sh, and .husky/ with a pre-commit hook setup, alongside .github/ for the workflows.

The modules reflect the architecture. designer/ is the visual editor, engine/ is the Flink execution side, scenario-compiler/ turns the scenario into something runnable, components/ holds the prebuilt blocks, and there are separate api modules for the common, components, extensions and scenario APIs, which is how a project keeps the public surface separate from the implementation. The examples/ directory holds both dev examples and installation examples, e2e-tests/ holds the end to end suite, and benchmarks/ exists as its own directory, which is a good sign for a project whose claim is throughput.

The site, the demo and the hosted product sit alongside. The README links a hosted demo, the documentation, a Docker quickstart page, an installation section and a Nu Cloud offering, and the package publishes to Maven Central under the pl.touk.nussknacker group with a designer artifact, and to Artifact Hub.

Where the project stands, and where it does not go yet

The maintenance picture has an odd shape and it is the thing to weigh before adopting. The repository is not archived and the last push was on 2026-09-30, so the code is being worked on. The default branch is staging rather than main, which is the normal arrangement for a project that cuts releases from a release branch, and the build status badge points at the CI workflow on that branch.

The listed releases, however, stop well before that. They are v1.18.0 from 2024-11-22, v1.17.0 from 2024-09-20 and v1.16.3 from 2024-08-08. So the most recent published version is close to two years old, while the source tree is ten months past that release. For an Apache-2.0 project that also sells a hosted version, that pattern suggests the open source tree is the community edition and the more current work happens elsewhere, or at least that release cutting has slowed.

The functional gap is explicit rather than implied. Batch processing is in active development, and the request-response mode supports a different component set from the streaming mode, with time window aggregations limited to the Flink engine. And the whole premise assumes the decision logic fits into prebuilt blocks with SpEL expressions, so a domain algorithm that cannot be expressed that way goes back to the developers, which the project presents as the intended division of labour rather than a limitation.

Editorial conclusion

Adopt Nussknacker when domain experts need to change decision logic on live Kafka streams without a developer in the loop, since the visual scenario editor, SpEL expressions and one click deployment cover the iteration speed that the project is built around. Do not adopt it for batch pipelines, since batch support is still in active development, and do not expect it to replace Flink engineering, because the throughput and scaling come from the underlying platform. Before you commit, read the installation documentation and try the hosted demo first, then check the release situation, since the listed releases stop at v1.18.0 from 2024-11-22 while the last push was on 2026-09-30.

Frequently asked questions

Official sources

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