BPB Worker Panel: a Cloudflare Workers panel for VLESS, Trojan and Warp subscriptions

Who BPB Worker Panel is for, and the problem it removes

Running a proxy on Cloudflare Workers normally means editing a script, redeploying it, and hand-building a client config every time you want to change a port, a DNS server or a routing rule. BPB Worker Panel replaces that loop with a web panel. The README describes the project as a user panel for "FREE, SECURE, PRIVATE proxies and tools including VLESS, Trojan and Warp configs alongside a private DoH server for cross-platform clients." The panel is password protected, and the subscription links it produces are consumed by Xray, Sing-box and Clash-Mihomo based clients.

The audience is narrow and specific. The README's stated goal is connectivity "even when domains or Warp services are blocked by ISPs," and the routing feature list names bypass rules for Iran, China and Russia plus blocking of QUIC, porn, ads, malwares and phishing. That is a tool for a person or a small group in a network where a plain endpoint is likely to be filtered, and who wants configuration changes to happen in a browser rather than in a text editor.

What actually runs: Worker, panel, subscription links

The deployment target is Cloudflare Workers or Pages, and the repository's package.json shows the panel is a TypeScript project built with esbuild rather than a runtime framework: the scripts are check, build and build-dev, with tsc --noEmit for type checking. The runtime dependencies are only jose, jszip and qrcode-generator, which lines up with the panel's job: sign and verify panel authentication, export client configuration bundles, and render QR codes for clients that scan them.

Data flow is one-directional from the panel's point of view. You open the panel, set DNS servers, clean IPs, ports, protocols, Warp endpoints and routing rules, and the panel emits subscription links. Clients poll those links and receive configs for their core. Two features change that simple picture. Node ability lets one deployment share settings and proxies with other BPB users, and proxy aggregation lets the panel pull in other proxies and deliver them inside a single subscription. Both mean the subscription a client fetches may contain entries that do not originate from your own Worker.

The private DoH server is part of the same deployment, and the README notes it is enabled by default "for enhanced security." Customizing the underlying DNS server is exposed as a panel setting.

Installing BPB Worker Panel and getting a first subscription

The README does not put deployment commands in the repository. It points to the project documentation site for installation methods, configuration and usage, and it names BPB Wizard as the deployment route: "Workers and Pages deployments using BPB Wizard in a few seconds." There is no npm install path for end users, and package.json is marked private, so the build scripts are for working on the panel itself rather than for installing it.

The practical first step is therefore to open the installation page the README links to and follow the Wizard flow there. If you are building the panel from source instead, the repository exposes these scripts:

npm run check
npm run build
npm run build-dev

check runs the TypeScript compiler without emitting files, build runs scripts/build.js, and build-dev runs scripts/build-dev.js. Those produce the artifact you would deploy through Cloudflare, but the README does not document a command that pushes it for you.

Once the panel is reachable, the first real use is to configure it and take a subscription link. The README's feature list is the checklist for that screen: choose ports and protocols, set clean IPs or domains, set Proxy IPs and DNS servers, pick Warp endpoints, and turn on the routing rules you want. Then copy the subscription link into a client. The README's client table is the compatibility check before you do, for example v2rayNG 2.2.3, v2rayN 7.22.5, Sing-box 1.12.0, and AmneziaVPN for Warp Pro.

The UDP gap and the 100K request ceiling

The README lists two limitations, and both are hard constraints rather than tuning knobs. First, "VLESS and Trojan protocols on workers do not handle UDP properly, so it is disabled by default." The README calls out the consequence directly: features like Telegram video calls are affected, and UDP DNS is unsupported. DoH is on by default, which mitigates the DNS side but does not restore UDP transport. If your workload depends on UDP, VLESS and Trojan on Workers is the wrong path, and the README's own alternative is Warp configs.

Second, "each worker supports 100K requests per day for VLESS and Trojan, suitable for 2-3 users." That is the README's own sizing statement, and it should be read as a sharing limit, not a suggestion. The same line notes that Warp configs are limitless, so the two protocol families have different capacity behavior on the same deployment. A panel that looks like a multi-user service is, on the VLESS and Trojan side, sized for a handful of people.

A third limitation is structural rather than stated: the panel runs on Cloudflare's platform, so its availability, request accounting and network position are Cloudflare's, not yours. Nothing in the README describes a self-hosted fallback.

How BPB Worker Panel differs from a plain Workers VLESS script

The obvious alternative is the script this project credits: the "Cloudflare-workers/pages proxy script" by yonggekkk, listed in the README's special thanks alongside the CF-vless code author 3Kmfi6HP. That lineage matters, because a plain Workers proxy script and BPB Worker Panel solve the same base problem in different places.

A plain script is edited and redeployed. Configuration lives in the file, changes require a new deployment, and each user typically gets a hand-assembled config or a manually built link. BPB Worker Panel keeps configuration in a panel behind authentication and emits subscription links that clients refresh on their own. The difference is not the protocol support, since both speak VLESS and Trojan on Workers. It is where change happens and who performs it.

The cost of that convenience is surface area. The panel adds authentication, a DoH server, routing rule sets, Warp Pro presets, Fragment support, chain proxy support, node sharing and proxy aggregation. Each is a setting you can get wrong, and the README does not document rollback for a bad configuration. If you only need one endpoint for one person and you are comfortable editing a script, the plain script is the smaller thing to operate. If you want a second person to change their own DNS server without touching your deployment, the panel is the reason to take on the extra moving parts.

Client compatibility decides your protocol, not the other way round

The README's client table is not a formality. Fragment support and Warp Pro support are split across clients in a way that constrains what you can turn on. v2rayNG, MahsaNG, v2rayN and Streisand are marked as supporting both. Sing-box 1.12.0 and husi 1.3.2 support Fragment but not Warp Pro. Clash Meta, Clash Verge Rev, FLClash and WG Tunnel support Warp Pro but not Fragment. Wireguard supports neither.

So a deployment that enables both Fragment and Warp Pro is only fully usable by four clients in that table. If your users are on Clash-based clients, Warp Pro works and Fragment does not. If they are on Sing-box, the reverse. AmneziaVPN appears with Warp Pro support and no Fragment support, and the project description names Amnezia and Wireguard among the cores it targets, which matches that split.

This is the part of the panel most likely to produce a support question, because the panel will happily generate a subscription that a given client cannot fully consume. Check the table against your actual users before enabling features, not after.

Licence, maintenance and what an upgrade costs

The repository is licensed GPL-3.0, and package.json carries the same identifier. GPL-3.0 is a copyleft licence, so if you redistribute a modified version of the panel you should read the licence terms yourself rather than assume the obligations are the same as a permissive licence. Running your own deployment is a different question from redistributing modified code, and this article is not legal advice.

The last push to the repository was on 2026-07-19, the same day as the v5.1.1 release, and the repository is not archived. Releases v5.1.0 and v5.0.0 landed on 2026-07-13 and 2026-07-08, so the 5.x line moved in three steps that month. The README does not document a migration procedure between panel versions, and it does not document rollback. That is the real upgrade cost: your configuration lives in the deployment, and the README gives no described path for preserving it across a version change. If you run this for other people, verify how your deployment's settings survive an update before you update.

Editorial conclusion

Adopt BPB Worker Panel if you want a self-hosted, password-protected subscription endpoint on Cloudflare Workers or Pages for yourself and two or three people, and you accept that UDP is disabled for VLESS and Trojan on Workers. Do not adopt it if you need UDP-based transport or a single deployment serving more than the README's 100K requests per day. Before deploying, check the supported clients table for the minimum version of your client and whether it handles Fragment or Warp Pro, and confirm which of the VLESS, Trojan or Warp paths your use case actually needs.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes