NPort: A Cloudflare-Powered Tunnel Tool That Hits a Shared Quota Wall
NPort is a powerful, lightweight ngrok alternative that creates secure HTTP/HTTPS tunnels from your localhost to public URLs using Cloudflare's global edge network. No configuration, no accounts, just instant tunnels with custom subdomains!
At a glance
- What is it?
- NPort is a TypeScript CLI that exposes localhost through Cloudflare's edge network, but its shared backend is already rate-limiting users. Here is how it works, where it stumbles, and who should run their own backend.
- Who is it for?
- Adopt NPort if you need a free, no-signup tunnel for demos, webhook testing, or mobile previews and can tolerate occasional rate limits. Avoid it for CI or high-frequency tunnel creation, where the shared backend's 10429 errors will stall you.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 37 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What NPort Actually Solves
NPort targets a familiar pain: you have a local server on port 3000 or 8080, and you need a public HTTPS URL in seconds. The README lists the usual use cases: sharing a dev build with a client, receiving webhooks from GitHub or Stripe, testing a mobile app on a real device, and debugging API integrations. The tool is a CLI, written in TypeScript, published on npm, and licensed under MIT. It does not require an account, and the default flow is a single command. That is the core promise, and for a quick demo it is genuinely convenient. The catch is that the convenience depends on a shared backend that has already hit Cloudflare's API quota, which the project announcement admits. So the tool solves the instant-tunnel problem, but it does so on a shared resource that can throttle everyone.
How the Tunneling Mechanism Works
The README does not expose the internal protocol, but the architecture is visible from the CLI options and the error messages. NPort connects to a backend server, by default at https://api.nport.link. That backend talks to the Cloudflare API to provision a tunnel endpoint, then the client establishes a connection to Cloudflare's edge. The public URL is a subdomain under nport.link, for example user-1234.nport.link or myapp.nport.link. The client prints a banner, shows the URL, and reports a four-hour time limit. Compression is enabled by default, according to the output. WebSocket and Server-Sent Events are listed as supported. The mechanism depends on Cloudflare's global network for HTTPS termination and routing, which is why the tool can claim automatic SSL and worldwide reach without owning any infrastructure beyond the backend.
Installation and First Run: Real Commands
The requirements are Node.js 20 or newer and npm 10 or newer. You install globally with npm install -g nport, or you skip installation and run npx nport 3000. The basic invocation exposes port 3000 with a random subdomain. For a custom subdomain, use nport 3000 -s myapp, which creates https://myapp.nport.link. The long form is --subdomain. There is also a --backend flag for a one-time custom backend URL, and --set-backend to save it permanently. Language is set with --language or -l, accepting en, vi, or es, and the first run shows an interactive picker. The default port is 8080 if you omit the argument. These commands are all documented in the README, so a new user can go from zero to a public URL in under a minute, assuming the backend is not rate-limited.
The Rate Limit Problem Is Real and Documented
The most honest part of the README is the announcement at the top. It states that the shared backend receives more tunnel requests than the Cloudflare API allows, and users see error 10429: Rate limited. The README explicitly says this is not a user setup problem. The fix, for now, is to wait a minute or two and retry. The project plans a v3.0.0 with automatic retry with backoff, better cleanup of abandoned tunnels, and support for bring-your-own Cloudflare account. Until that release, the tool is fragile under load. The README advises against starting many tunnels in a tight loop or in CI, because each start consumes API calls. That is a direct limitation: NPort is not suitable for automated test suites or any workflow that creates tunnels frequently. The shared quota is a genuine architectural constraint, not a hypothetical edge case.
Running Your Own Backend: The Escape Hatch
The README points to a server/ directory in the repository for running your own backend. That is the documented way to avoid the shared quota. You would use --backend https://your-backend.com for a temporary override, or --set-backend to make it permanent. The README does not provide setup instructions for that server in the visible text, so you would need to inspect the repository yourself. The existence of this option is the key differentiator from a closed tunnel service: you can take the client and the backend code, run it against your own Cloudflare account, and remove the shared bottleneck. That is a real escape hatch, but it shifts the operational burden onto you. You need a Cloudflare account, you need to handle the API credentials, and you need to keep the backend running. The README is clear that this is the path for users who need it working right now.
What the CLI Does Not Tell You
The README lists features like automatic HTTPS, WebSocket support, and cross-platform support, but it does not document the tunnel's lifetime beyond the four-hour display in the sample output. That four-hour figure appears in the example, but there is no explicit statement of whether it is a hard limit or a rolling expiration. The README also does not mention any authentication for custom subdomains. If you pick a subdomain like myapp.nport.link, nothing in the material suggests that someone else cannot claim the same name later or that you have exclusive rights. The tool is free and open source, so those gaps are acceptable for a dev utility, but they matter if you plan to use it for a persistent public endpoint. The rate limit announcement is the only concrete failure mode documented; other behaviors, like what happens when the tunnel drops, are left unstated.
Alternatives and the Difference in Approach
The obvious alternative is ngrok itself, which the README names directly. ngrok offers a hosted service with a free tier, but it requires an account and an authtoken, and the free tier has a random subdomain that changes each session unless you pay. NPort's approach is to remove the account step entirely and rely on a shared Cloudflare backend. That is a meaningful difference: NPort is simpler to start, but it inherits the shared quota problem. Another alternative is a self-hosted tunnel like bore or localtunnel, which let you run your own server without Cloudflare. Those give you full control but require you to manage the server and the domain. NPort sits in between: it has a hosted default, but it also offers a self-hosted backend option. The trade-off is clear: hosted simplicity versus quota reliability, and self-hosting versus operational overhead.
Maintenance and License Implications
The project is under the MIT license, which permissive and allows commercial use, modification, and redistribution with attribution. The README does not describe a contribution process or a changelog, but the release history shows active development: v2.1.4 in March 2026, v2.1.5 in late March, and v2.1.6 in August 2026. The repository is not archived, and the last push matches the latest release. The maintenance cost for a user is low: the CLI is a single npm package, and updates come through npm. The operational cost appears when you run your own backend, because you take on Cloudflare API management and server uptime. The README's v3.0.0 roadmap indicates that the maintainers are aware of the scaling issue, but until that release, you should expect occasional interruptions on the shared backend. The license does not restrict you from forking the project to fix issues yourself, which is a practical fallback.
Editorial conclusion
Adopt NPort if you need a free, no-signup tunnel for demos, webhook testing, or mobile previews and can tolerate occasional rate limits. Avoid it for CI or high-frequency tunnel creation, where the shared backend's 10429 errors will stall you. Before relying on it, verify the current rate limit status, test your custom subdomain availability, and if you need guaranteed uptime, plan to run your own backend with a personal Cloudflare account, as the README suggests.
Community notes