Five files create a network proxy, subscription feed, and cover page
deploy-vercel is much more than its one-line repository description. index.js starts an HTTP and WebSocket server, authenticates several proxy handshakes with one UUID, and opens outbound TCP connections to requested hosts. A subscription route returns base64-encoded VLESS, Trojan, and Shadowsocks-style connection records. The root serves a generic environmental organization page, which the README tells users to replace with another generated HTML page.
The project is documented in Chinese, with no English guide. Its instructions cover creating a private repository from the template, editing settings, importing the project into Vercel, assigning a domain, and optionally putting a Cloudflare Worker or snippet in front of it. The README also says the Vercel-assigned domain may be blocked and unusable for direct connections. That is a warning about the operating model, not a minor setup footnote.
The default UUID is public and must be treated as compromised
index.js falls back to UUID d1cf4b9c-3e57-085d-b34a-797fcf601381. The default WebSocket path is the first 8 characters of that same UUID, while the default subscription path is vercel. Anyone reading the public repository can know all three values. A private fork does not make a published default secret.
A competent operator would replace the UUID and paths before the first deploy, then prevent the subscription endpoint from disclosing credentials to untrusted visitors. The implementation returns the subscription when the configured path matches; it does not add a second authentication check for that HTTP route. The README proposes JavaScript obfuscation through an external website, but obscuring code does not repair a public credential or substitute for access control.
Nezha configuration grants terminal and file operations
The optional Nezha block reports system details such as CPU, memory, disk, process, and network data through gRPC. More importantly, its task stream handles interactive terminal sessions. It starts the configured shell through node-pty when available, then falls back to other pseudo-terminal methods. The same agent can list directories, download files, and upload files to paths supplied by the remote task.
Those capabilities may be intentional for a trusted administration dashboard, but they change the risk category. NEZHA_SERVER and NEZHA_KEY are remote-control credentials, not harmless observability settings. The code uses TLS only when the configured server port belongs to a fixed set of 6 ports; other ports use insecure gRPC credentials. Leave Nezha unset unless you own and secure the dashboard, understand its task protocol, and accept remote shell authority over the process environment.
What happened when we ran it
Our sandbox cloned commit 9b7052b into an unprivileged Debian container with 3 CPUs, 8 GB of RAM, no secrets, and Node 22. The repository contained 5 files, about 1,003 lines of source, and occupied 0.1 MB. It had no CI workflow, Dockerfile, or tests directory.
npm install succeeded in 13 seconds. It added 66 packages and occupied 81 MB on disk, a large expansion from the 0.1 MB checkout. npm audit reported 0 known vulnerabilities across all four severities. That result only checks known advisories in the installed dependency tree; it does not assess the proxy protocol, authentication design, outbound connections, or remote task handlers.
There was no build script or target, so our lab skipped the build. There was also no test script or target, so no tests ran. We did not start the proxy or connect it to Vercel, Cloudflare, a proxy client, or Nezha. The repository therefore gives us a successful dependency installation and no measured evidence about routing, long-lived WebSockets, subscriptions, or remote administration.
Region documentation already has a current dispute
The README lists Vercel region codes across Asia, Europe, Africa, the Americas, and Australia. Issue 6, opened August 21 and updated August 25, says the Dubai, Johannesburg, and Miami codes in that table were unusable in the reporter's tests. The issue is narrow, but it shows why copied platform tables need verification against the current provider rather than trust based on a recent README date.
Project activity is recent. The last push was August 18, 2026, and the issue queue had 5 issues and pull requests combined, with activity through August 25. GitHub returned no latest release. Recent pushes mean the project is not stale, but they do not offset the absence of CI, tests, versioned releases, or a license file for security-sensitive code.
A dedicated proxy core is the safer default
The Vercel template is attractive only when that deployment shape is itself the requirement. Even then, the operator must secure credentials, confirm that use complies with every provider involved, test each region, and own a reverse-proxy layer the README already assumes may be necessary. The generic cover page and suggested obfuscation add concealment without improving protocol security.
sing-box, Xray-core, and V2Ray core demand more explicit infrastructure, but each makes the proxy engine the product rather than hiding it inside a five-file serverless template. They are easier to reason about, configure openly, and isolate on a host you control. deploy-vercel is an audit-first experiment, not a deployment recipe we would hand to a newcomer.