Netra Panel: a VLESS and Trojan proxy panel that runs on Cloudflare Workers

The problem Netra Panel removes: a proxy that needs no server to babysit

Running a VLESS or Trojan endpoint normally means renting a VPS, keeping the kernel and the proxy core current, and watching for the provider suspending the machine. Netra Panel takes the server out of that picture. The README describes it as "a free, self-hosted VLESS / Trojan proxy panel that runs entirely on Cloudflare Workers", with no VPS, no Docker and no server to patch or reboot.

The intended user is someone who wants a working subscription link without becoming a sysadmin, and the repository leans on that: the README points to a Telegram installer bot, @irNetra_bot, as an alternative to the manual deploy steps. The audience is technical enough to open a Cloudflare dashboard and add a binding, but not necessarily interested in running Xray or sing-box on a box they own. The repository itself is thin: LICENSE, README.md and worker.js. There is no test directory, no CI configuration and no build step visible at the top level, which tells you the project is one file you paste, not a codebase you compile.

How the Worker, the KV namespace and the panel fit together

The architecture is small enough to describe in one breath. All logic lives in worker.js, which is deployed as a Cloudflare Worker. Persistent state lives in a Workers KV namespace bound to the Worker under the variable name kv. The panel is a route on the same Worker: the README says to append /panel to the Worker URL, for example https://your-worker.workers.dev/panel, and that on first visit you are asked to set a panel password or skip it.

That single-origin design is the interesting part. The proxy endpoint and the administrative interface share a hostname, so the URL you hand to a client and the URL you use to change settings are the same string with a different path. It also means the KV namespace is the only durable storage. Settings you change in the panel (UUID, Trojan password, secure path, ports, DNS, routing rules, bypass and block lists, according to the feature list) have to be written back to KV, because a Worker has no local disk. The README does not describe what happens to in-flight connections when you save a change, and it does not document any export or backup of the KV contents.

Client compatibility is handled through subscription links. The README lists Xray-core, sing-box, Clash and WireGuard-based clients, naming v2rayNG, Streisand, Clash Meta, Hiddify and NekoBox. Fragment and noise settings exist to make traffic blend in on restrictive networks, though the README does not explain what those settings change at the packet level.

Installing Netra Panel and opening the panel for the first time

Deployment is manual and short. The README gives two routes: a Deploy to Cloudflare Workers button, or creating a Worker yourself in the Cloudflare dashboard and pasting the contents of worker.js into the editor. There is no npm package and no CLI in the repository, so the file is the artifact.

After the Worker exists, create a Workers KV namespace. The README places this under Storage & Databases in the dashboard, and says the namespace name is arbitrary. The binding name is not:

# Cloudflare dashboard, Worker settings
# Settings -> Bindings -> Add binding -> KV Namespace
# Variable name: kv

The README is explicit that the variable name must be exactly kv and nothing else. Then open the Worker URL with /panel appended:

https://your-worker.workers.dev/panel

On that first visit you are prompted to set a panel password, or to skip it. The README states the panel works immediately with built-in defaults after deployment, with no separate setup wizard. What you should see is a panel page rather than an error; if the binding is missing or misnamed, the README says the Worker throws a 1101 error and the panel does not work. That is the first thing to check if the page fails to load.

The binding name, the default credentials and other ways this breaks

The hardest failure mode is also the easiest to hit. A KV namespace bound under any variable name other than kv produces a 1101 error, and the README repeats this warning in more than one language. It is not a configuration the panel can repair from inside itself, because the panel cannot load without it. If you are following the Telegram bot route instead of the manual route, the same requirement presumably applies, though the README does not spell out what the bot does on your behalf.

The second limitation is security by default. The README warns that choosing Skip password means anyone with the Worker URL can reach the panel, and that this is acceptable only for a private or testing deployment. It also says to change the default UUID, Trojan password and secure path before sharing a subscription link, and to treat the Worker URL as a secret because it is the entry point. Those are three separate defaults that ship in a working state, which is convenient for a first deploy and risky for a shared one.

Beyond configuration, the whole design assumes Cloudflare. The README does not document rollback, version pinning or a migration path off Workers. There is no documented rate limiting, no per-user quota and no accounting of how much traffic a subscription has moved, at least not in the README. If your use case needs to bill, cap or audit individual users, this is the wrong tool, and a panel backed by a conventional server with a real database is the honest alternative.

What the README does not tell you about running it long term

Upgrades are the weakest documented area. Releases exist (the repository lists V6, V7 and V8 between 2026-08-20 and 2026-08-28), but the README describes no upgrade procedure at all. Because deployment is pasting worker.js into the Cloudflare editor, updating in practice means replacing that file with a newer copy and redeploying. Whether your KV-stored settings survive that replacement is not stated. The README also does not document any schema versioning for the KV data, so a release that changes the shape of stored settings could leave you with a panel that reads old keys.

The licence is MIT, which is permissive: you can use, modify and redistribute the code, and the repository ships a LICENSE file at the top level. MIT also means no warranty and no support obligation from the author, and the README routes questions to Telegram at @NetraIR rather than to a documented support process. If you fork it, the licence does not require you to publish your changes, but it does require you to keep the copyright notice. None of this is legal advice; read the LICENSE file for the actual terms.

On maintenance, the repository is not archived and the last push was on 2026-09-14, so the project is being touched as of this writing. That is a statement about repository activity, not a promise about response times or backwards compatibility.

Netra Panel against running Xray or sing-box on your own VPS

The direct alternative is the conventional setup: an Xray-core or sing-box server on a VPS, with a panel such as one of the web front ends for those cores managing users. The difference is where the code runs and who absorbs the failure. On a VPS you control the IP, the ports, the TLS certificate and the logs, and you can run any protocol the core supports, including ones that need UDP or raw sockets. You also own the patching, the abuse handling and the bill.

Netra Panel inverts that. You get no server to maintain and no monthly cost for the compute, per the README's framing, and deployment is measured in minutes. In exchange you accept the Worker runtime's constraints and Cloudflare's account-level rules, you store state in KV rather than a database you can query directly, and the panel and proxy share one origin. If Cloudflare suspends the account or the Worker, you lose both the endpoint and the panel at once, and the README documents no export of the KV data beforehand.

There is also a client-side difference. A VPS deployment can offer whatever the core supports, while Netra Panel exposes VLESS and Trojan plus Warp and Warp Pro routing, and reaches clients through subscription links for Xray-core, sing-box, Clash and WireGuard-based apps. If your clients are already those apps, the subscription format is the practical compatibility layer.

Who should deploy Netra Panel, and what to check before sharing a link

Take it if you want a VLESS or Trojan endpoint for yourself or a small group, you are comfortable in the Cloudflare dashboard, and you would rather not run a server. The single-file deployment and the built-in defaults mean you can have a working panel shortly after creating the Worker, and the Telegram bot at @irNetra_bot exists for people who would rather not do the manual steps.

Skip it if you need per-user traffic accounting, quotas, or an audit trail; if you need a documented rollback when an upgrade goes wrong; or if you cannot accept that the panel and the proxy disappear together if the Cloudflare account does. In those cases a VPS running Xray-core or sing-box with a conventional panel is the more predictable choice, even with the maintenance it brings.

Before you hand a subscription link to anyone, do three things the README calls out. Confirm the KV binding is named exactly kv, since a misnamed binding produces a 1101 error and an unusable panel. Change the default UUID, Trojan password and secure path from inside the panel. And decide deliberately whether to set a panel password: skipping it means anyone holding the Worker URL can open the panel, and the README limits that choice to private or testing deployments.

Editorial conclusion

Adopt Netra Panel if you want a VLESS or Trojan endpoint without renting or patching a server, and you accept that the panel, its KV storage and the proxy traffic all sit inside one Cloudflare account. Do not adopt it if you need per-user accounting, a documented rollback path, or a deployment that survives losing that account. Before sharing a subscription link, verify the KV binding is named exactly kv, change the default UUID, Trojan password and secure path, and decide whether the panel password is worth setting.

Frequently asked questions

Official sources

1. License: MIT
2. netrair/netra-panel on GitHub
3. Project website
4. README
5. Releases