# BFE: Baidu's Layer 7 Load Balancer, and What It Costs to Run It

> BFE Server is the Go forwarding engine behind Baidu's traffic stack, published as a CNCF sandbox project. It routes by content, balances across backends, and expects you to build or deploy a control plane around it.

**bfenetworks/bfe** — A modern layer 7 load balancer from baidu

- Repository: https://github.com/bfenetworks/bfe
- Website: https://www.bfe-networks.net
- Stars: 6,270 · Forks: 950
- Language: Go
- License: Apache-2.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/bfenetworks-bfe

## What BFE Server Actually Is, and Who It Is For

The repository bfenetworks/bfe is one component of a larger system, not the whole product. The README splits BFE into a data plane and a control plane. This repository holds the data plane: BFE Server, the forward engine that does content based routing, load balancing, and forwarding to backend servers. The control plane lives in three other repositories: API-Server for config storage and generation, Conf-Agent for fetching config and triggering a reload, and Dashboard for a graphic interface.

That split defines the audience. If you want a load balancer that reads a config file you edit by hand, BFE Server alone is enough. If you want a UI and an API to manage config across a fleet, you are signing up for four deployments. The README lists the English control plane documentation as coming soon and points to a Chinese deployment document in the api-server repository, which tells you where the project's operational weight currently sits.

## Content Based Routing and the Plugin Framework

The README lists the advantages plainly: HTTP, HTTPS, SPDY, HTTP2, WebSocket, TLS and FastCGI support; content based routing with user-defined rules in what it calls an advanced domain-specific language; multiple load balancing policies; a plugin framework for extensions; RESTful API and Dashboard management; and built-in metrics.

The plugin framework is the part that shapes adoption. The Go module list includes bfe_module and bfe_modules as separate packages, and the repository also carries bfe_wasmplugin alongside a dependency on github.com/bfenetworks/proxy-wasm-go-host. That means extensions can be written in Go against the module interfaces, or loaded as WebAssembly plugins through the proxy-wasm host. The trade-off is real: a Go plugin compiled into the binary is fast but requires you to rebuild and redeploy the server, while a wasm plugin can be swapped without a rebuild at the cost of an extra runtime layer.

The routing rules are the other half. Content based routing means the decision depends on request attributes rather than only on the destination address, which is what lets one BFE instance front many services. The README does not spell out the rule syntax in the repository root; it points to the documentation site and to the book In-depth Understanding of BFE, released in February 2023, for the design rationale.

## Building the Docker Images and Deploying the Kubernetes Example

The quick start in the README targets users who want a running setup fast. Step one is building images from the repository root. The target builds both prod and debug images, and tags come from the VERSION file.

```bash
make docker
```

To override the image name, the README gives an environment variable on the same target.

```bash
make docker BFE_IMAGE_NAME=your-registry/bfe
```

Step two deploys the Kubernetes example with kustomize. Run these from the examples/kubernetes directory.

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

The whoami deployment gives you a backend to route to, so after both commands you should have BFE plus a test workload running. If your cluster nodes cannot pull the image you built locally, push it to a reachable registry first, or load it into a local cluster, then update the bfe image mapping under images: in examples/kubernetes/kustomization.yaml. The README also flags image mirror settings, initialization notes, cleanup, and finalizer troubleshooting in examples/kubernetes/README.md, which is worth reading before you tear the example down.

## Building From Source and the Go Toolchain Requirement

The README's Getting Started section points to docs/en_us/installation/install_from_source.md for building and running the data plane. The repository's go.mod pins go 1.22 with toolchain go1.22.9, and the Dockerfile builds on golang:1.22.2-alpine3.19, so a Go 1.22 toolchain is the floor rather than a suggestion. The Makefile drives the build: make runs prepare, compile and package, make strip does the same with stripped binaries, and make docker is what the quick start uses.

Two details from the Dockerfile matter if you build your own image. The binary is compiled with CGO_ENABLED=0, so it is a static Go binary, and the version string is injected with -ldflags "-X main.version=$(cat VERSION)". The image also pulls Conf-Agent at build time from a GitHub release tarball, with CONF_AGENT_VERSION defaulting to 0.0.2, which means the container image already anticipates the control plane even though BFE Server itself is the data plane.

## Where BFE Is the Wrong Tool

BFE Server is a forwarding engine with a configuration surface, and it does not pretend otherwise. The README states that the control plane is a separate set of repositories, and that the English control plane documentation is coming soon. If your team has no appetite for running API-Server, Conf-Agent and Dashboard alongside the server, you are choosing to manage config by hand or to write your own tooling. That is a legitimate choice for a small number of instances and a poor one for a fleet.

The Kubernetes story is also an example, not a product. examples/kubernetes is a kustomize sample with a whoami backend; the README describes finalizer troubleshooting and cleanup as things you may need, which is the vocabulary of a sample environment rather than a managed operator. If you want a load balancer that installs as a single binary with a built-in admin UI and no companion services, BFE's architecture works against you. The same applies if you need the control plane documented in English today, because the repository says that documentation is not there yet.

## How BFE Differs From NGINX and Envoy

The closest comparisons are NGINX and Envoy, and the difference is in where extension logic lives. NGINX configuration is declarative and its extension points are modules, with third-party modules requiring a rebuild or a dynamic module build; BFE offers both an in-process Go plugin framework and WebAssembly plugins through bfe_wasmplugin. Envoy takes the other route: its filters are predominantly written against a C++ extension API, and it is controlled through a dynamic xDS API rather than config files that a separate agent reloads.

BFE's model sits between them. The server loads configuration and a Conf-Agent triggers a reload when the config changes, which is closer to the file-and-reload model than to xDS. Routing is content based and expressed in a domain-specific language rather than in NGINX's location blocks. For a team already writing Go services, the plugin path is the concrete advantage: new behaviour is a Go package or a wasm module, not a C++ filter or an out-of-tree module build.

## Licence and the Cost of Upgrades

BFE is under the Apache 2.0 licence, and the repository carries LICENSE and NOTICE files along with a .licenserc.yaml, which is the usual arrangement for a project that expects contributions to carry explicit headers. Apache 2.0 includes a patent grant and permits commercial use; it does not remove the obligation to preserve notices. That is a description of the licence text, not advice about your situation.

Upgrade cost depends on how you extend the server. If you run the stock binary from a release, moving between versions is a matter of replacing the image or binary; the release cadence visible in the repository is frequent, with v1.8.5, v1.8.6 and v1.8.7 published within weeks of each other in August and September 2026, and the last push to the develop branch was on 2026-09-21. If you maintain Go plugins, each upgrade means recompiling against the new module versions, and the go.mod requires a Go 1.22 toolchain, so toolchain drift is part of the maintenance budget. Wasm plugins avoid the recompile but add the proxy-wasm host as a compatibility surface you have to track.

## Conclusion

Adopt BFE Server if you want a Go layer 7 engine with content-based routing and a plugin framework you can extend in-process, and you accept that the control plane is a separate deployment. Do not adopt it if you need a single binary with a built-in UI and no extra services. Before committing, build the images with make docker, apply examples/kubernetes with kustomize, and confirm which configuration path you will use, because the English control plane documentation is listed as coming soon.

## FAQ

### What is BFE?

BFE (Beyond Front End) is a layer 7 load balancer from Baidu, and bfenetworks/bfe is its forwarding engine, called BFE Server. It performs content based routing and load balancing and forwards traffic to backend servers, and it is a CNCF sandbox project under the Apache 2.0 licence.

### How do I install BFE?

The README's quick start builds images with make docker from the repository root, then deploys the Kubernetes example with kubectl apply -k . and kubectl apply -f whoami-deploy.yaml from examples/kubernetes. Building and running the server directly from source is covered in docs/en_us/installation/install_from_source.md.

### Does BFE include a management dashboard?

No, the Dashboard is a separate component in its own repository, alongside API-Server and Conf-Agent, which together form the control plane. The bfenetworks/bfe repository holds only BFE Server, the data plane.

### Which protocols does BFE support?

The README lists HTTP, HTTPS, SPDY, HTTP2, WebSocket, TLS and FastCGI among the supported protocols.

### Can I extend BFE with my own code?

Yes, the README describes a flexible plugin framework for extending functionality, and the repository contains both bfe_module and bfe_modules packages and a bfe_wasmplugin package that depends on the proxy-wasm Go host.

## Sources

- [bfenetworks/bfe on GitHub](https://github.com/bfenetworks/bfe)
- [License: Apache-2.0](https://github.com/bfenetworks/bfe/blob/develop/LICENSE)
- [Project website](https://www.bfe-networks.net)
- [README](https://github.com/bfenetworks/bfe/blob/develop/README.md)
- [Releases](https://github.com/bfenetworks/bfe/releases)

---

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