# loxilb puts an eBPF load balancer in the Kubernetes service path

> loxilb is a Go and eBPF cloud-native load balancer whose main use case is the Kubernetes service type load-balancer, with an Ingress implementation on top, a kube-proxy replacement, Gateway API support and a telco oriented service communication proxy. It is Apache-2.0 licensed, and the last push was on 2026-10-18.

**loxilb-io/loxilb** — eBPF based cloud-native load-balancer for Kubernetes|Edge|Telco|IoT|XaaS.

- Repository: https://github.com/loxilb-io/loxilb
- Website: https://www.loxilb.io
- Stars: 1,886 · Forks: 157
- Language: Go
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/loxilb-io-loxilb

## The main use case is the service type load-balancer

loxilb is an open source cloud-native load balancer based on Go and eBPF, with the goal of cross-compatibility across a wide range of on-premises, public-cloud or hybrid Kubernetes environments. The description says it is being developed to support the adoption of cloud-native technology in telco, mobility and edge computing.

The README is explicit about which service it is for. Kubernetes defines many service constructs, cluster-ip, node-port, load-balancer and ingress, for pod to pod, pod to service and outside world to service communication, and all of these are provided by load balancers or proxies at Layer 4 or Layer 7. Because Kubernetes is highly modular, different software modules can provide them. kube-proxy is the default for cluster-ip and node-port, and for services like load-balancer and ingress no default is usually provided.

That is the gap loxilb targets. The README notes that service type load-balancer is usually provided by public cloud providers as a managed entity, but for on-premises and self-managed clusters there are only a few good options, and even on provider-managed Kubernetes such as EKS many people want to bring their own load balancer. The README states in bold that loxilb provides service type load-balancer as its main use case, and that it can run in-cluster or ext-to-cluster as needed.

The broader feature list adds a kube-proxy replacement with eBPF described as a full cluster-mesh implementation for Kubernetes, Ingress support, Kubernetes Gateway API, and HA capable egress. Network policies are on the list with an empty checkbox, so they are not implemented.

## L4 by default, L7 through Ingress on the same data path

loxilb works as an L4 load balancer and service proxy by default. The README argues that although L4 load balancing provides great performance and functionality, an equally performant L7 load balancer is also necessary in Kubernetes for various use cases, and that loxilb supports L7 in the form of a Kubernetes Ingress implementation enhanced with eBPF sockmap helpers. The stated benefit is that users who need both get them under the same hood.

That sockmap detail is the technical heart of the project. eBPF sockmap helpers let the L7 layer keep the connection's socket state in the kernel, so a connection established through the L7 path can be handed to the L4 path without a userspace round trip. It is the mechanism that lets one program serve both service proxying and ingress without the two halves fighting over the connection.

The Ingress implementation is not the standard one with extra features, it is the standard one built on the eBPF data path, which means the same connection tracking and the same forwarding decisions apply whether the traffic arrived as a cluster service or as an ingress request.

The repository structure reflects the split between the control plane and the data path. There is a loxilb-ebpf/ directory for the eBPF subsystem, with the Makefile building it separately through a subsys target that runs make inside loxilb-ebpf, and a build target that depends on it. The kernel objects are named llb_ebpf_main.o and llb_ebpf_emain.o, and the docker-cp target copies both the binary and the object files into a running container, which shows that the eBPF programs are compiled artifacts deployed alongside the daemon.

## Telco traffic is where the unusual protocols come from

The second half of loxilb's identity is the telco side, and it is not a set of plugins bolted on.

For a telco cloud, loxilb can be used as an enhanced SCP, a service communication proxy defined by 3GPP and aimed at telco micro-services running in a cloud-native environment. The README links the 3GPP specification and a blog post explaining the role.

The list of what each interface needs is the clearest statement of the difficulty. N4 requires PFCP level session intelligence. N2 requires NGAP parsing capability. S6x requires Diameter and SCTP multi-homing load balancing support. MEC use cases might require uplink and downlink understanding. Hitless failover support might be essential for mission-critical applications. E2 might require SCTP load balancing with OpenVPN bundled together. SIP support is needed to enable cloud-native VOIP. N32 requires support for the Security Edge Protection Proxy, SEPP.

The README explains why this list exists: telco 5G and edge services introduce unique challenges due to the variety of exotic protocols involved, including GTP, SCTP, SRv6, SEPP and DTLS, making integration particularly hard. A general purpose load balancer cannot do PFCP session awareness or NGAP parsing, which is the whole argument for a purpose built one.

The repository topics list confirms the scope, with 5g, 6g, sctp, nat64, network-security, network-proxy, edge, hybrid-cloud and public-cloud among the tags.

## The Go dependencies show the breadth of the control plane

The go.mod is where the practical complexity of a multi-cloud load balancer shows up.

There is a Kubernetes client stack, k8s.io/api at v0.29.0, apimachinery at v0.30.0 and client-go at v0.29.0, so the project is a few Kubernetes minor versions behind the current release. There is an AWS SDK v2 with the EC2 service and the instance metadata service feature, which is how the daemon detects and manipulates cloud load balancer resources when running in a public cloud. There is gobgp, the Go implementation of BGP, for advertising routes.

Two loxilb-owned dependencies are notable. github.com/loxilb-io/ipvs v0.1.0 is an IPVS library, and github.com/loxilb-io/loxilib v0.8.9-0.20260804074046-0cd1e5f28d17 is the shared library from the same organisation. 

For the API surface there is a full go-openapi stack, loads, spec, validate, strfmt, swag and runtime, and grpc with protobuf for the internal RPC between components. jwt/v4 is there for authentication, netlink from vishvananda for netlink operations, prometheus client_model and pro-bing, go-cache for caching, mysql driver for state, and oauth2 with golang.org/x/crypto for the cloud provider flows.

The build is a Go 1.25 module, and the Dockerfile pulls Go 1.24.0 for the build image, which is a small inconsistency worth noting if you build it yourself.

## Building loxilb means building eBPF objects and a Go daemon

The Makefile shows the build as two halves, and the version stamping logic is unusually careful.

The default goal is build, which depends on subsys. The subsys target changes into loxilb-ebpf and runs make there, which compiles the eBPF subsystem, and the build target then compiles the Go binary with ldflags that stamp the build timestamp and branch name into common.BuildInfo.

The version handling is worth reading closely. The Makefile comment explains that the git tag is the source of truth for the version, the source tree carries only a dev placeholder, and VERSION defaults to the result of git describe --tags --exact-match, so it is set when building from an exact tag checkout, which is how the deb and qcow2 packaging builds work, and empty otherwise. A patsubst strips a leading v even when VERSION came from the command line. The Dockerfile repeats the same idea with a comment noting that .dockerignore excludes .git, so the build cannot derive the version from a tag and it has to be passed in as a build argument, and that when empty the binary reports the dev placeholder from common/common.go.

That is careful engineering for a detail many projects get wrong, and it is why the release version can be trusted in a running container.

The Dockerfile for the build stage starts from ubuntu:22.04, installs the eBPF toolchain including clang-14, llvm, libelf-dev and libpcap-dev, along with elfutils dwarves, and downloads Go and OpenSSL for the target architecture. It handles arm64 and amd64 with different cross-compiler packages, and it prepares certificate directories under /opt/loxilb/cert and /etc/loxilb/certs, plus a bash completion directory.

The image is published as ghcr.io/loxilb-io/loxilb, with a separate arm64 tag, and the repository has a Dockerfile.buildcheck as well as a main Dockerfile, plus a docker-multiarch workflow and a basic-sanity workflow.

## The AI fork shows where the project is heading next

The README's new item at the top is a fork, loxilb-inference-gateway, and it is a good way to understand what the upstream data path can be reused for.

The fork is described as built on this project and licensed under Apache-2.0, the same as loxilb. It keeps the same Go and eBPF data path and adds routing that is aware of how inference engines such as vLLM, SGLang, TensorRT-LLM and llama.cpp serve requests. Every AI capability is opt-in per load balancer rule, and with no AI feature enabled it behaves exactly like upstream loxilb.

The capability table names four things. KV-cache-aware routing sends each request to the endpoint whose KV cache already holds the longest prefix of the prompt. Prefill and decode disaggregation splits each request across prefill and decode pools, with KV transfer coordination and session affinity. An MCP gateway provides stateless validation and per-request selection, or legacy session routing. And AI traffic governance enforces API keys, JWT, model authorization and request and token quotas before dispatch.

The KV cache routing is the one that needs the load balancer to know something about the application, and it is exactly the class of problem a layer 4 balancer cannot solve and a layer 7 aware one can. That is the same argument the telco section makes about PFCP session intelligence, applied to inference serving.

There is also an eBPF Emerging Project badge from ebpf.io, an OpenSSF Best Practices badge, a Go Report Card badge, a Slack community and a documentation site. The governance files are thorough for a project of this size, with GOVERNANCE.md, MAINTAINERS.md, AUTHORS, ADOPTERS.md, SECURITY.md, CODE_OF_CONDUCT.md and CONTRIBUTING.md at the top level, and a Korean README alongside the main one.

## Conclusion

loxilb suits a cluster operator who needs a self-managed service type load-balancer, an on-premises or edge cluster where the cloud provider default is not available, or a telco workload with SCTP and GTP traffic. It is the wrong tool for a managed Kubernetes cluster where the cloud provider's load balancer works, and the wrong tool if you cannot run privileged eBPF code in the kernel. Before deploying, check that the eBPF objects build for your kernel and read the release version list, because the project ships versioned releases such as v0.9.8.8 and the data path is kernel dependent.

## FAQ

### What is loxilb?

It is an open source cloud-native load balancer based on Go and eBPF, aimed at cross-compatibility across on-premises, public cloud and hybrid Kubernetes environments. Its main use case is the Kubernetes service type load-balancer, which the cloud provider usually provides and on-premises clusters usually lack.

### What Kubernetes features does loxilb support?

The feature list covers a kube-proxy replacement with eBPF described as a full cluster-mesh implementation, Ingress support, Kubernetes Gateway API, and HA capable egress. Kubernetes Network Policies are listed with an empty checkbox, meaning they are not implemented.

### How does loxilb handle Layer 7 traffic?

It works as an L4 load balancer and service proxy by default, and adds L7 through a Kubernetes Ingress implementation enhanced with eBPF sockmap helpers, so L4 and L7 run under the same data path.

### What telco protocols does loxilb deal with?

The README lists N4 with PFCP session intelligence, N2 with NGAP parsing, S6x with Diameter and SCTP multi-homing, E2 with SCTP and OpenVPN, SIP for cloud-native VOIP, N32 with the Security Edge Protection Proxy, MEC cases, GTP, SRv6, SEPP and DTLS, plus hitless failover for mission-critical applications.

### How do I build loxilb?

The Makefile default goal is build, which first runs make inside the loxilb-ebpf directory to compile the eBPF subsystem and then compiles the Go binary with version and build info stamped through ldflags. The version comes from the git tag, and the Dockerfile passes it in as a build argument because .dockerignore excludes .git.

## Sources

- [License: Apache-2.0](https://github.com/loxilb-io/loxilb/blob/main/LICENSE)
- [loxilb-io/loxilb on GitHub](https://github.com/loxilb-io/loxilb)
- [Project website](https://www.loxilb.io)
- [README](https://github.com/loxilb-io/loxilb/blob/main/README.md)
- [Releases](https://github.com/loxilb-io/loxilb/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/loxilb-io-loxilb