Linkerd 2.15 was released today, and along with some significant feature updates, the company behind the project announced significant changes to the open-source model. 

Buoyant, which is the company that created Linkerd, announced it is changing the release model for Linkerd. Starting with this release, stable releases will not be shipped as open-source anymore, but rather as Buoyant Enterprise for Linkerd (BEL), a paid offering which will come with additional tools, features, and testing.

Edge releases and the source code will remain available in the open-source repository. According to an FAQ by Buoyant, the difference between edge and stable releases is that “Edge releases contain the latest code in from the main branch at the point in time when they were cut. This means they have the latest features and fixes, but it also means they don’t have stability guarantees.” Stable releases, on the other hand, “are designed to introduce minimal change to an existing system and come with documented stability guarantees.” 

BEL will be free for non-production use or for production use at companies with less than 50 employees. The company also noted that it was willing to negotiate with non-profits, high-volume use cases, and other organizations with unique needs. 

The new change will go into effect on May 21, 2024, giving organizations 90 days to upgrade. Companies that sign up for BEL in the next 30 days will also receive a discount on the pricing. 

“This change is a big one, but it’s absolutely necessary for us to fund the incredible set of features we’re busy adding to Linkerd,” William Morgan, CEO of Buoyant, wrote in a blog post on the Buoyant website. “We’re tackling significant new work like adding ingress traffic , egress control, IPv6, Windows, eBPF, ambient approaches, and more to Linkerd, and we’re determined to to deliver them with the same ultralight, ultrafast, ‘just works’ approach that makes Linkerd so uniquely today in a space that’s notorious for complexity. Linkerd 2.15 is just a step in a long journey of compounding value. To accomplish these lofty goals, we need the companies that are building their businesses on top of Linkerd to do their part to fund the project. This change ensures that they can do that, while giving the thriving ecosystem of startups, developers, and students the ability to use Linkerd without restriction.”

In terms of what’s new in Linkerd 2.15, a main highlight is that it can now be used for non-Kubernetes workloads, such as applications running on virtual machines, physical machines, and others. This feature, known as “mesh expansion,” is an important step for Linkerd to become a “universal networking layer for cloud native organizations,” which is one of the project’s main goals. 

“While we love Kubernetes, we recognize that even the most sophisticated organizations often still have significant investments in applications that don’t run outside of it. With Linkerd 2.15, regardless of whether your workloads are running on resource-constrained ARM64 edge devices, legacy ‘big iron’ VMs, or physical machines in your server closet, Linkerd’s uniform layer of security, reliability, and observability is at your disposal,” Morgan wrote in a blog post

Linkerd 2.15 also introduces support for SPIFFE, which is a universal identity control plane hosted by the CNCF as a graduated project. By introducing this support, the project maintainers hope to solve the challenge of generating workload identities for non-Kubernetes workloads, making this support important with the addition of mesh expansion. 

In previous iterations of Linkerd, it would use the Kubernetes ServiceAccount to generate a workload identity, but since ServiceAccounts don’t exist for other non-Kubernetes workloads, another solution was needed. 

SPIFFE, and its reference implementation SPIRE, are now used for this purpose. SPIFFE identities are generated using SPIRE, and these IDs can be used alongside Linkerd’s existing system for authorization. 

Finally, the last main update in Linkerd 2.15 is that there is now support for native sidecar containers. According to Morgan, deploying sidecars directly using Linkerd fixes some of the challenges people deal with when using sidecar containers in Kubernetes.

The company also shared some insight into what’s coming next from the project. The next features will be mesh expansion for private networks, parity for Gateway API and non-Gateway API interfaces, support for IPv6, handling ingress traffic, and adding control over egress traffic.