vvxw/deploy-vercel: a Vercel deployment template for proxying a subscription backend

What vvxw/deploy-vercel actually ships

The repository is a template, not a library. The top-level entries are README.md, index.html, index.js, package.json and vercel.json. The README's first instruction is to click "Use this template" and create a private repository, which tells you the intended workflow: you copy the code into your own repo and then edit it. There is no published package and no release. The package.json names the project "nzws-js" at version 0.1.0, which does not match the repository name, so anyone searching npm for this project will not find it under that name.

The audience is narrow. Steps three through six of the README describe replacing index.html with an AI-generated decoy page, deploying to Vercel, filling a DOMAIN variable with a reverse-proxied domain, obfuscating the file through an external site, and then pulling subscription information out of the running deployment. That is a specific operational routine, not a general web app. If you are looking for a starter for a normal Vercel API, this is the wrong repository; the README will not help you and the dependencies will get in your way.

The README is written in Chinese. It is short, numbered, and assumes context the repository never supplies: what the environment variables in index.js mean, what the service exposes, and how the subscription output is generated. The only supporting reference material is a table of Vercel region codes and a Cloudflare Worker snippet.

The mechanism: index.js, environment variables, and a Worker in front

The data flow implied by the README is: Vercel runs index.js as a Node process, index.js reads environment variables you set in the file itself, and the Vercel-assigned domain is then hidden behind a Cloudflare Worker or Snippet that rewrites the hostname. The README explicitly says the Vercel-assigned domain is blocked and cannot be used for direct node connections, which is the reason the Worker layer exists at all.

The Worker example in the README keeps a list of hostnames and picks one at random per request, then forwards the request with the original path intact. That is a simple load-spreading or failover pattern, and it is the only piece of request-handling logic the README shows in full. Note that the array in the snippet is populated with a single placeholder host, so the random selection does nothing until you add more entries.

The dependency list is where the mechanism gets less obvious. package.json includes ws (a WebSocket server and client), axios, @grpc/grpc-js and @grpc/proto-loader, systeminformation, and an optional node-pty. None of those appear in the README's instructions. A gRPC stack plus a pseudo-terminal dependency plus host system information points at a backend that talks to a remote control plane and can expose a shell, but the README does not describe any of that. Treat the dependency list as the real description of scope and the README as an install checklist.

Deploying it: template, npm install, and the Vercel settings that matter

The README's install path is entirely through the Vercel dashboard. There is no CLI command in the repository, and no local development instruction. The one command that appears is the install command you set in the Vercel project configuration.

First, create your own repository from the template as the README instructs, then open index.js and fill in the environment variables it expects. The README says to leave unused ones empty. It does not list them, so read the file.

npm install

That is the install command the README tells you to open and set in the Vercel project configuration during import. The default Vercel settings are otherwise kept as-is.

Next, replace index.html with your own page. The README calls for a plain HTML file, and it misspells the filename as index.thml in step three while the actual repository entry is index.html.

Then import the project in Vercel: New Project, Import, keep the default configuration, enable the install command, and deploy.

{
  "name": "nzws-js",
  "version": "0.1.0",
  "main": "index.js",
  "scripts": { "start": "node index.js" },
  "engines": { "node": ">=16.0.0" }
}

The package.json above is abridged to the fields that affect deployment. The start script runs node index.js, and the engines field requires Node 16 or newer. Vercel's Node runtime version is chosen in the project settings, not by this file alone, so check that the selected version satisfies the engine constraint.

After the first deploy, the README says to confirm the page loads and the subscription link returns nodes, then put the reverse-proxied domain into the DOMAIN variable in index.js and redeploy. The Cloudflare Worker snippet below is the reverse proxy it refers to; replace the placeholder host with your Vercel domain, without the https:// prefix.

export default {
    async fetch(request, env) {
        let url = new URL(request.url);
        if (url.pathname.startsWith('/')) {
            var arrStr = [
                'xxx-xxx.vercel.app',
            ];
            url.protocol = 'https:'
            url.hostname = getRandomArray(arrStr)
            let new_request = new Request(url, request);
            return fetch(new_request);
        }
        return env.ASSETS.fetch(request);
    },
};
function getRandomArray(array) {
  const randomIndex = Math.floor(Math.random() * array.length);
  return array[randomIndex];
}

If you want a specific region, the README provides a code table. hnd1 is Tokyo, hkg1 is Hong Kong, sin1 is Singapore, fra1 is Frankfurt, iad1 is Washington D.C., and so on through 24 entries. The README does not say how to apply a region code to the deployment; it presents the table as a reference only.

Where this template breaks down

The largest limitation is documentation. index.js is the whole application and the README never describes it. Variables are referenced by name (DOMAIN is the only one it names) but the full set, their types, and which are required is left to the reader. That is a real cost: you cannot tell from the README whether an empty variable disables a feature or crashes the process.

The dependency set is a second problem. A gRPC client stack, a WebSocket library, and systeminformation all pull native or platform-sensitive code paths. node-pty is listed as an optional dependency, which suggests the project tolerates its absence, but the README does not say what degrades when it is missing. On a serverless platform this matters more than on a long-lived VM, because the runtime is rebuilt on each deploy.

Third, the README's own checklist admits the Vercel domain is blocked and unusable for direct connections. That means the deployment is not useful on its own; it only works behind the Cloudflare layer, and the Cloudflare Worker snippet is the only place that logic is written down. If Cloudflare changes how Workers or Snippets behave, the README offers no fallback.

Fourth, there is no licence file in the repository metadata. Without a stated licence you have no explicit grant to redistribute or modify the code, which is a genuine blocker for anything beyond personal use.

Finally, the README's obfuscation step routes index.js through a third-party website. That is a manual, non-reproducible step, and it means the deployed file will not match the file in your repository.

How this differs from a plain Vercel deployment

The obvious alternative is deploying a normal Node service to Vercel directly, or to a host like Railway or Fly.io. The difference is in what each assumes about the runtime. A standard Vercel deployment expects stateless request handlers, and Vercel's own documentation covers environment variables through the dashboard rather than through edits to a source file. This template inverts that: it stores configuration inside index.js, which means every configuration change is a code change and a redeploy.

A second difference is the proxy layer. A conventional deployment is reachable at its assigned domain. This one is designed to sit behind Cloudflare Workers or Snippets, with the Worker rewriting the hostname. If you deploy the same code on a VPS, you would typically terminate TLS and route with nginx instead, and you would not need the Worker at all. The template's shape is a consequence of the platform, not of the application.

The region table is another point of contrast. Vercel lets you pin a function region in project settings, and the README lists 24 codes, but it does not explain how to set one. A host that gives you a fixed machine, such as a small VPS, makes the region decision once at purchase time. Here the region is a platform setting you have to find yourself.

Maintenance, versioning and licence

The repository is not archived, and the last push was on 2026-08-18. There are no releases. Version 0.1.0 in package.json is the only version marker, and the package name does not match the repository, so there is no changelog to follow.

Upgrades are manual by construction. Because the template is copied into your own private repository, you do not receive upstream changes; you would have to diff your copy against the original yourself. The README does not describe an update procedure, and there is no migration guidance for the dependency versions pinned in package.json.

On licensing: the repository metadata does not state a licence, and no licence file appears among the top-level entries. That absence is worth checking before you reuse the code in anything you distribute, and it is a question for whoever maintains the upstream repository rather than something to assume. Nothing here is legal advice.

The operational cost is the ongoing one. Every configuration change means editing index.js, re-running the obfuscation step, and redeploying, and the Cloudflare Worker hostname list has to be updated by hand whenever your Vercel domain changes.

Editorial conclusion

Adopt this only if you already run a subscription or proxy backend and want a Vercel-hosted copy of it, and you are comfortable editing index.js by hand and fronting the result with Cloudflare. Do not adopt it if you want a documented, self-contained service: the README never explains what the environment variables do, the licence is not stated in the repository metadata, and there is no rollback or upgrade path. Before deploying, read index.js end to end, confirm which variables are required versus optional, and check package.json against the runtime you expect on Vercel, because the dependency list (ws, axios, @grpc/grpc-js, @grpc/proto-loader, systeminformation, optional node-pty) is far heavier than the README's five-step description suggests.

Frequently asked questions

Official sources

1. Issues
2. README
3. vvxw/deploy-vercel on GitHub