BFE (Beyond Front End) is an open-source, Apache-2.0 licensed layer 7 load balancer written in Go, originally built at Baidu and now a Cloud Native Computing Foundation (CNCF) sandbox project, intended for platform, infrastructure, and networking engineers who need content-based routing and centralized traffic management in front of backend services.

What it is

BFE is the open-source project name for both a forwarding engine and the management tooling built around it. The system is split into a data plane and a control plane. The data plane is the BFE Server in this repository, which performs content-based routing, load balancing, and forwarding of user traffic to backend servers. The control plane consists of three companion components: API-Server, which provides an API and handles the update, storage, and generation of BFE configuration; Conf-Agent, which loads configuration, fetches the latest config from API-Server, and triggers BFE Server to reload it; and Dashboard, which provides a graphical interface for managing and viewing the major configuration of BFE. The project also includes BFE Ingress Controller, built on BFE, so that Ingress in Kubernetes can be fulfilled by BFE rather than by a separate ingress data plane.

The concrete problem it addresses is the gap between plain forwarding and managed traffic control. A conventional layer 7 proxy balances requests and stops there; routing rules, configuration distribution, and reload behaviour are left to whoever runs it. BFE couples the forward engine with a routing rule language, a RESTful configuration API, and an agent that pushes configuration changes into the running server, so that routing policy lives in a managed store rather than in hand-edited files. It lives in the Go and cloud-native ecosystem, with a Kubernetes deployment path and an official Snap package alongside container images.

Key capabilities

• Multiple protocols supported, including HTTP, HTTPS, SPDY, HTTP2, WebSocket, TLS, and FastCGI.
• Content-based routing with user-defined routing rules expressed in an advanced domain-specific language.
• Support for multiple load balancing policies.
• A flexible plugin framework for extending functionality, exposed through the bfe_module Go package documented on GoDoc.
• Centralized management through a RESTful API and the Dashboard interface.
• Detailed built-in metrics for observing the forwarding layer.
• Container image builds via make docker, which produces both production and debug images with tags derived from the VERSION file, overridable with BFE_IMAGE_NAME, plus make docker-push for publishing.

Who uses it and how

• Kubernetes operators who deploy the Ingress Controller to serve Ingress traffic, using the provided kustomization under examples/kubernetes and the accompanying whoami-deploy.yaml sample workload.
• Platform teams that want configuration owned by an API rather than by the edge nodes: API-Server stores and generates config, Conf-Agent fetches it and triggers BFE Server reloads, and Dashboard gives a graphical view of the major settings.
• Engineering teams that need to add behaviour not covered by the core, by writing modules against the plugin framework instead of forking the forward engine.
• Operators who package and ship the load balancer through the Snap store or through private container registries reachable by their cluster nodes.
• Teams standardising on a CNCF sandbox project for the traffic entry point, with the governance and licence that implies.

Getting started

Build the images from the repository root with make docker (setting BFE_IMAGE_NAME if a custom registry path is wanted, and make docker-push to publish), then deploy the Kubernetes example with kubectl apply -k . inside examples/kubernetes, followed by kubectl apply -f whoami-deploy.yaml. Installation details, including image mirror settings, initialization, and cleanup, are in docs/en_us/installation/install_using_docker.md and examples/kubernetes/README.md.

How it compares

No list of paid or commercial products that BFE replaces is provided in the available facts, and no comparable tools are named either. It therefore stands alone in this registry, described only on its own terms as a Go-based layer 7 load balancer and traffic management system with a separate control plane.

When to use it — and when not to

A self-hoster takes on more than a single binary: the full system implies running BFE Server together with API-Server, Conf-Agent, and Dashboard, and the documented quick start assumes Docker image builds plus a Kubernetes cluster whose nodes can pull the resulting image. Teams that want no configuration-management plane, or that have no cluster and no willingness to operate one of these components, should look at simpler forwarders instead. The repository is actively maintained and Apache-2.0 licensed, but the quick-start path is oriented toward container and Kubernetes deployment rather than a one-command local install, and the Kubernetes example documentation itself flags finalizer troubleshooting as a real operational detail.

make docker

make docker BFE_IMAGE_NAME=your-registry/bfe

cd examples/kubernetes
kubectl apply -k .
kubectl apply -f whoami-deploy.yaml