# Nova Proxy: a self-hosted censorship-resistant proxy on a Cloudflare Worker

> Nova Proxy deploys a VLESS, Trojan and Shadowsocks edge worker plus an admin panel to your own free Cloudflare account. The deployment model is the interesting part; the licence change and the closed panel source are the parts to check before you commit.

**IRNova/Nova-Proxy** — Worker Trojan Warp DNS IP Amnezia Wireguard Sing-box Clash/Mihomo Xray.

- Repository: https://github.com/IRNova/Nova-Proxy
- Website: https://irnova.github.io/Nova-Proxy/Htmel/
- Stars: 3,298 · Forks: 748
- Language: JavaScript
- License: MIT
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/irnova-nova-proxy

## The problem Nova Proxy solves, and who it is actually for

Running a proxy for other people usually means renting a VPS, keeping it patched, and paying for bandwidth you then resell or ration. Nova Proxy takes a different route: the whole thing runs as a Cloudflare Worker on the operator's own free Cloudflare account. The README is explicit that there is no shared server and no middleman, and that the bandwidth, domain and data belong to whoever deploys it.

The intended operator is someone administering access for a group rather than a single user. The panel creates users, gives each one a quota, an expiry date and a daily limit, and issues a private subscription link per person. The README describes the project as "a free, high-quality tool, not a reseller platform", which is a positioning statement as much as a feature list. If you are one person who wants a proxy for yourself, the multi-user machinery is overhead you will never touch.

The secondary audience is the user on the other end, who never sees the panel. They receive a link, open it on a phone, choose Auto, Base64 or Clash, and import it. The README recommends Nova Client for iOS, Android and desktop, and states that any client reading Base64 or Clash also works.

## What runs where: worker, KV, D1 and the failover path

The architecture is a single Worker with two storage bindings. KV is described in package.json as Nova's "compatibility and migration store", while DB is the primary D1 database holding settings, users, usage, logs and authentication. That split matters when you reason about failure: user records and quotas live in D1, so a D1 problem is a panel problem, not just a caching problem.

On the protocol side the Worker speaks VLESS, Trojan, Shadowsocks, gRPC and XHTTP over WebSocket plus TLS. One notable design choice is the mixed protocol link: a single subscription carries both VLESS and Trojan, so if a filter blocks one the client can fall back to the other without the user doing anything. Nova also supports proxy chaining and a backend mode, which routes traffic through your own server when the edge alone is not enough.

Two resilience mechanisms are worth separating. The GitHub mirror failover publishes the subscription to a GitHub repository so users keep a permanent raw.githubusercontent.com link even if the operator's domain is filtered. Self-healing links are a separate behaviour: the README states that if the worker domain changes or a host goes down, configs fall back to a working address on their own. The first protects the subscription URL, the second protects the node addresses inside the config. Neither is documented in enough depth to say how the fallback list is ordered.

## Installing Nova Proxy with Wrangler and opening the panel

The README gives three deployment paths. The one-click Deploy to Cloudflare button uses Cloudflare's supported flow, which creates the Worker, the KV namespace and the D1 database and then connects Workers Builds. The README states that you do not create or paste a Cloudflare API token into Nova on this path. There is also a Telegram installer bot, @IRNovaProxy_Bot, which the README says can complete the deployment from a phone.

The CLI path needs a free Cloudflare account and Wrangler. The README's commands are below; note that the comment states Wrangler provisions and binds KV and D1 automatically.

```bash
# 1. install the Cloudflare CLI
npm install -g wrangler
wrangler login

# 2. install dependencies and deploy
# Wrangler provisions and binds KV and D1 automatically.
npm ci
npm run deploy
```

package.json shows what npm run deploy does: it runs the build script and then wrangler deploy. There is also a check script that builds, runs node --check on worker.js, and does a wrangler deploy --dry-run into .wrangler/dry-run, which is the cheapest way to confirm the artifact parses before touching your account.

After deployment, open the admin URL and finish setup:

```bash
# open this in a browser after deploy
https://<your-worker>.workers.dev/admin
```

The README says the short setup ends with you setting your admin login. Before that step, one binding deserves attention. NOVA_CLAIM_TOKEN is described in package.json as optional but recommended: with it set, the panel only accepts its first admin password at /install?claim=<value>, so nobody who finds the address first can claim the panel. Generate it with the command the README gives:

```bash
openssl rand -hex 16
```

Leave it blank and the old behaviour applies, where whoever opens /install first sets the password. For a panel that will hold other people's credentials, leaving it blank is a mistake. Full deployment, verification and update instructions are in DEPLOY.md.

## Updates arrive as a pull request, and that is the right shape

Repositories created from this project include a daily Check for Nova updates GitHub Action. When a release is available it opens a pull request containing only worker.js and version.json. You review the diff and the Cloudflare preview, then merge to deploy through Workers Builds. The README mentions an optional hands-off mode controlled by one repository variable, validated before it applies.

This is the strongest part of the design. Because the deployable unit is a small artifact plus a version file, the update diff is readable even though the source behind it is not. The README says rollback instructions are in DEPLOY.md, but the README itself does not document rollback, so read DEPLOY.md before you enable the automatic mode rather than after something breaks.

The cost side is modest: the tooling is npm and Wrangler, the runtime is Cloudflare's free plan, and the README notes that free Cloudflare limits apply. The recurring work is reviewing update pull requests and watching whether the artifact still boots, which is exactly what the check script is for.

## The closed panel source and the licence change you should read first

Nova ships as a protected release. The public repository holds a minified and obfuscated worker.js plus deployment metadata, and the maintainable panel source is kept private. The README calls this "protected panel, open tools": the client apps, Nova Radar and the verified helpers stay open while the panel does not.

The README is unusually candid about the limits of that protection. It states that the protection does not make the code impossible to recover, and that a Cloudflare account owner can always inspect a Worker running in their own account. It declines to claim the code is unrecoverable. Treat that as an accurate description of a deterrent, not a security boundary.

The licence position is the part that decides whether you can use this at all. Releases through 4.2.0 were published under MIT, and the README says that historical grant still stands for those versions. Starting with 4.3.0, Nova-authored changes are under PolyForm Noncommercial. Self-hosting, studying and modifying Nova for noncommercial use is permitted; reselling access or running paid hosting is not permitted without written permission. The repository carries LICENSE, LICENSE-HISTORY.md and LICENSE-MIT-LEGACY files, so the version boundary is checkable in the tree rather than only in prose. This is a description of the terms, not legal advice; if you operate commercially, read the licence files themselves. There is also a TRADEMARKS.md, which is worth opening if you plan to name your deployment anything close to Nova.

Note the version mismatch in the tree: package.json reports 4.8.1 while the README's release-notes section still describes 4.5.2 as the latest release. The release list shows v4.7.4 as the most recent tagged release. When you decide which licence applies to what you are running, check version.json and the release tag rather than the README prose.

## Where Nova Proxy is the wrong tool

Calls are the clearest boundary. Voice and video over UDP cannot ride a plain free Worker, and the README says so directly: enable the WARP node or a backend server for FaceTime, WhatsApp and Telegram calls. If your users' main need is calling, you are signing up for the WARP node or for a server of your own, which removes much of the reason to pick a Worker-only design.

Auditability is the second boundary. If your threat model requires reading the code that handles user credentials and usage records before you trust it, the minified artifact is not that. The panel stores authentication data in D1, and you cannot review the logic that guards it. Nova Radar, the in-browser scanner that finds clean Cloudflare IPs for the current network, is a partial counterexample: the README lists it among the open tools, so the scanning side is inspectable even though the panel is not.

Third, the free plan is a real constraint rather than a footnote. The README frames self-hosting as scaling without shared cost, but every operator still lives inside Cloudflare's free-tier behaviour, and the README does not quantify where that ceiling sits. If you need predictable throughput for a large group, a Worker on the free plan is the wrong substrate regardless of how good the panel is.

## How Nova Proxy differs from Xray and sing-box deployed on a VPS

The obvious alternative is the same core protocols on a VPS: Xray or sing-box installed on a machine you rent, with a panel such as one of the common web front ends in front of it. The protocols overlap heavily. Nova speaks VLESS, Trojan and Shadowsocks, which is the same family those cores serve, so the difference is not the wire format.

The difference is where the process lives and who carries the traffic. On a VPS you control the operating system, the kernel, the listening ports and the logs, and you can read every line of the panel because it is a normal application. You also pay for the machine and its bandwidth, and you are the one patching it. Nova inverts all of that: no server to patch, no bandwidth bill, but no operating system to inspect either, and the panel logic is a build artifact.

A second difference is the subscription model. Nova's panel is built around per-user links with quota, expiry and daily limits, plus format negotiation through Auto, Base64 and Clash. A bare Xray or sing-box config file has none of that; you would add it with a separate panel or write it yourself. If you already run a panel you like on a VPS, Nova's advantage shrinks to the hosting model, and the closed source becomes a straight downgrade.

The honest summary: Nova competes on operational cost, not on capability. If free hosting on Cloudflare is the constraint you are optimising for, it is a coherent answer. If control and auditability are the constraint, a VPS stack wins and Nova is the wrong direction.

## Conclusion

Adopt Nova Proxy if you want a per-user subscription panel on your own free Cloudflare account and you accept a minified deployment artifact with a noncommercial licence from 4.3.0 onward. Do not adopt it if you need auditable panel source, if you plan to resell access, or if your users depend on voice and video calls without a WARP node or backend server. Before you hand out links, verify three things yourself: that /install is reachable only with your NOVA_CLAIM_TOKEN set, that your subscription link survives in the format your users' clients accept, and that the rollback path in DEPLOY.md actually restores the previous worker.js.

## FAQ

### What is Nova Proxy?

It is a control panel and edge worker that runs on Cloudflare Workers, giving you VLESS, Trojan, Shadowsocks, gRPC and XHTTP over WebSocket plus TLS on your own free Cloudflare account. The panel manages users, quotas and subscription links, and it is deployed by you rather than shared with other operators.

### How to use Nova Proxy?

Deploy the Worker with the one-click button, the Telegram installer bot, or Wrangler, then open the admin URL and finish the short setup, which ends with setting your admin login. After that, turn on multi-user in the panel, create a user with a quota and expiry, and send that user their private link to import as Auto, Base64 or Clash.

### How to use nov proxy?

The README does not describe a separate product called nov proxy; the deployment steps it documents are Nova Proxy's, and they start with a free Cloudflare account and either the one-click Deploy to Cloudflare button, the @IRNovaProxy_Bot installer, or Wrangler with npm run deploy.

### Which is safer, a VPN or a proxy?

The README does not compare Nova Proxy against VPNs, so it does not answer this. What it does say is that user subscription links are credentials and should be treated like passwords, and that you should keep the admin login private.

### Should I turn the proxy on or off?

The README does not discuss when to enable or disable a proxy at the client level. It only describes the server side: per-user links with quota, expiry and daily limits, and Resistance Policy presets with plain-language on and off toggles that you configure in the panel.

### How exactly does a proxy work?

The README does not explain proxy fundamentals. It describes Nova's own mechanism instead: a Worker on your Cloudflare account that serves VLESS, Trojan and Shadowsocks over WebSocket plus TLS, with a KV compatibility store and a D1 database holding settings, users, usage, logs and authentication.

## Sources

- [Official documentation](https://irnova.github.io/Nova-Proxy/Htmel/)
- [Official README](https://github.com/IRNova/Nova-Proxy#readme)
- [Project repository](https://github.com/IRNova/Nova-Proxy)
- [Release notes](https://github.com/IRNova/Nova-Proxy/releases)

---

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