Dropping plugin support in KrakenD Open Source and Lura

Starting with version 3.0, the Community Edition of KrakenD and the Lura Project will no longer support Go plugins. Plugin support continues in the Enterprise Edition, where it remains the right tool for the job. We want to explain the reasoning behind the split.

Why plugins still make sense in Enterprise

The complexity of Go plugins applies equally to the Enterprise Edition, none of the tradeoffs we’ll describe in the next section magically disappear there. What’s different is that Enterprise customers run a closed binary: they can’t fork the source and recompile, so plugins are genuinely the only flexible way to extend the gateway with custom logic. That alone justifies absorbing the complexity. On top of that, we control the build toolchain end-to-end with each customer’s plugin work: the Go version, the dependency set, the build flags, the C library, and the resulting artifact. When a plugin works, it’s because that whole pipeline is aligned on both ends, and we can stand behind the result.

Why plugins no longer make sense in the Community Edition

The starting point is the Go plugin package itself. The plugin package in the standard library has been effectively in maintenance mode for years: it carries external glibc dependencies on Linux, has historically interacted awkwardly with the memory manager, and produces more expensive GC cycles than ordinary Go code. The Go team has been explicit that it isn’t a priority area. Building an extension model on top of it is building on top of a mechanism the language itself treats as second-class.

On top of that, Go plugins are unforgiving: they must be compiled with the exact same Go version, the exact same versions of every shared dependency, the same build flags, and the same C library as the host binary. Any drift produces failures that are difficult to diagnose without access to both build environments.

We’ve spent years trying to close that gap for open source users. We’ve shipped builder images that reproduce our exact toolchain, documented the build process in detail, and iterated on both based on the issues we’ve seen. The builders work when used as documented, they produce working plugins reliably.

What we’ve observed over years is that a meaningful share of plugin issues come from builds that diverge from the documented path: a different Go version pinned somewhere upstream, a dependency bumped independently, a builder image swapped for a local toolchain because it was more convenient. Each of these is understandable in isolation, and each one breaks the plugin in ways that are expensive to debug remotely.

This isn’t a problem better tooling can solve, because the tooling already exists. And it isn’t strictly a dependency-management problem either but often a priority divergence. A shared dependency may carry a CVE that we treat as a false positive in the gateway’s context and aren’t in a rush to bump; the same dependency, recompiled into a plugin running in a different environment, may genuinely be exposed to it. A new upstream release may contain a fix or a feature the plugin author needs but the host doesn’t. Tools surface these mismatches; they don’t reconcile them. Both ends still have to be built in lockstep.

There’s a security angle worth naming on top of that. Carrying plugin support means carrying the full surface area of the host’s dependency graph as part of the plugin contract on both glibc and musl builds. We’ve spent meaningful effort tracking CVEs in transitive dependencies across those builds, and a real share of that work exists because those dependencies are exposed through the plugin ABI. Removing plugins from the Community Edition shrinks that surface for everyone who never wrote a plugin in the first place.

The structural property is this: shipping an in-process extension mechanism to an open source user base that builds in its own environments turns every moving part (Go version, dependency graph, C library, build flags, host version) into something that has to be reproduced symmetrically on both ends. In the Enterprise Edition we own the pipeline on both ends and can offer adequate support for that complexity. In the Community Edition the same complexity exists, but the build pipeline diverges by definition, and no amount of documentation or builder tooling makes the support tractable.

The path for source-level customization

KrakenD is open source, which means the source itself is the extension point. Custom middleware, handlers, and components can be integrated directly into the codebase and compiled into your own binary. This is:

• Not sensitive to Go version or dependency drift.
• Fully debuggable with standard tooling.
• A single artifact you control.

Modern development tooling has made this kind of source-level customization considerably more approachable than it was when we first added plugin support back in 2019. For most users who reach for plugins today, integrating into the source or expressing the behavior in Lua, is both simpler and more robust.

Consolidating plugin support into the edition where we can properly stand behind it also lets us focus our open source work on the parts of KrakenD that benefit every user.

We’ll publish a migration guide alongside the release covering the common plugin patterns and how to express them in source or in Lua.

Plugins have been part of the KrakenD and Lura Community Edition for six years. Removing them from Open Source is a significant change, and we wanted to explain the reasoning rather than ship it as a changelog line. Plugins on Enterprise continue to be the right tool for the job and we continue providing assistance to all our customers.

If you have questions about what this means for your setup please get in touch.