Product / high-performance L4

More traffic. Fewer load balancers.

XLB significantly lowers the operating cost and maintenance overhead of extreme-scale load balancing. Handle millions of requests per second with fewer servers, no traffic-based cloud pricing, and no proxy tuning.

eBPF / XDPLayer 4NATLinux

Why XLB moves more traffic per server

A direct packet path, not a userspace proxy.

HAProxy and NGINX terminate the client connection, pass application data through a proxy process, and establish a second connection to the backend. XLB keeps packet processing in the kernel and forwards the original payload without userspace copies, delivering lower latency and more consistent performance under load.

HAProxy / NGINX2 sockets + userspace copies

kernelClient socketbuffers + TCP state

copy

userspaceHAProxy / NGINXread + schedule + write

copy

kernelBackend socketbuffers + TCP state

The load balancer owns and maintains two bidirectional sockets. Application data is copied into userspace and back to the kernel in both directions.

XLB / XDP0 proxy sockets + 0 userspace copies

01Client

One end-to-end connection

XLB / XDPselect + routeheaders only

02Backend

The client and backend keep one end-to-end connection. XLB routes each packet without reading, buffering, or copying the application payload, reducing latency and jitter on the load-balancer path.

Packet lifecycle

A short path from NIC to backend.

XDP runs early in the Linux receive path. XLB uses that position to handle the load-balancing work before a general-purpose application proxy would see the packet.

01
Classify
Match inbound IPv4/TCP traffic to a configured listener and port mapping. Traffic outside the configuration passes normally.
02
Select
Look up an existing flow or assign a backend for a new connection from the currently available backend set.
03
Rewrite
Update the network and transport headers for the selected backend and maintain the paired flow state for return traffic.
04
Forward
Send the packet toward the backend. The application receives the original TCP flow directly.

Local management

No separate system to keep alive.

A local XLB process reads the config, follows Kubernetes backend changes, and exports metrics. There is no cluster-wide VIP service, BGP manager, configuration database, or controller for your team to operate.

SStatic provider
Declare named backend IPs directly in configuration.
KKubernetes provider
Watch Pods selected by a Service and use ready, non-terminating IPv4 backends.
OOpenTelemetry
Export OTLP metrics over gRPC or HTTP/protobuf.

Backend sourceStatic YAML or K8s API

reconcile↓

Local agentXLB processconfiguration · discovery · telemetry

update maps↓

Kernel / XDPBackend + flow mapsread on the packet path

Configuration

A small surface area on purpose.

Define the listener, one to eight port mappings, backend source, flow cleanup policy, shutdown window, and optional metrics exporter. That’s the contract.

Configuration reference

xlb.yamlstatic provider

name: openrtb-ingress
listen: auto
proto: tcp
mode: nat

ports:
  - local_port: 443
    remote_port: 8443

provider:
  static:
    backends:
      - name: bidder-01
        ip: 10.0.1.11
      - name: bidder-02
        ip: 10.0.1.12

otel:
  enabled: true
  endpoint: http://otel:4317
  protocol: grpc

Operational model

Tuning-free from deployment onward.

XLB uses ordinary Linux and Kubernetes primitives, keeps backends current automatically, and is completely tuning free with no separate control plane.

DEPLOY / 01

Linux host

Run as a binary or privileged host-network container on an XDP-capable interface.

DISCOVER / 02

Backend-aware

Use explicit IPs or continuously reconcile eligible Pods from a Kubernetes Service selector.

OBSERVE / 03

OTLP-native

Use built-in metrics with the local status interface or ready-to-import Grafana and Datadog packages.

Explore monitoring

SHUTDOWN / 04

Reactive grace window

Keep XDP attached briefly on shutdown and reset matching TCP traffic that arrives during the configured window.

COMPAT / 05

Native or generic XDP

Prefer native-driver mode for performance, with generic/SKB XDP as a compatibility fallback.

TUNING / 06

Completely tuning free

No worker, thread, buffer, socket, or connection-profile tuning. Configure the backends and run it.

Before you evaluate

Environment requirements.

Operating system: Linux kernel 5.10+
Traffic: IPv4 / TCP
Routing: NAT mode
Network: XDP-capable interface; native driver preferred
Container mode: Privileged + host network
Backend topology: Backends reachable on separate hosts or Pods

Bring your traffic profile

Test the architecture where it counts.

We’ll help frame an evaluation around your NICs, packet sizes, connection churn, and application deadline.

Evaluate XLB