NPort: an ngrok alternative that tunnels localhost through Cloudflare's edge

The problem NPort solves, and who actually needs it

Localhost is unreachable from the outside. That single fact breaks a surprising number of everyday tasks: GitHub cannot deliver a webhook to 127.0.0.1, a Stripe test payment cannot call back to your machine, and a colleague or client cannot open the page you are working on. The usual answer is a tunneling service, and the usual tunneling service wants an account, a token, and sometimes a credit card before it hands over a URL.

NPort targets that gap. The README lists its intended uses as development environments, webhook testing for services such as GitHub, Stripe and PayPal, mobile testing on real devices, API debugging, and client demos. The pitch is one command and no signup. That matters most for the ephemeral case: you need a public URL for twenty minutes, then you are done. It matters least for anything long-lived, and the project's own announcement is candid about why.

The tool is published on npm as nport, requires Node.js 20 or newer and npm 10 or newer, and is MIT licensed. The CLI entry point is dist/index.js, exposed as the nport binary.

How the tunnel is built: CLI to backend to Cloudflare edge

NPort is not a tunnel server itself. The client talks to a backend, and the backend holds the Cloudflare account that creates the public hostname. The default backend is https://api.nport.link, and the public URLs live under nport.link, which is also the project's homepage. When you run nport 3000 -s myapp, the CLI asks that backend for a tunnel, the backend calls Cloudflare's API to provision the hostname, and traffic to https://myapp.nport.link is routed back to your machine over the connection the client established. HTTPS termination happens at Cloudflare, which is why the README can promise automatic SSL/TLS without you touching a certificate.

The repository layout reflects that split. src/ holds the TypeScript client, server/ holds the backend you can self-host, and website/ holds the site. There is a CLIENT_SETUP.md at the top level alongside docs/ and tests/, and the build runs through scripts/build.js rather than a bare tsc invocation. Runtime dependencies are small: axios, chalk and ora, which is a CLI spinner. The README also claims WebSocket and Server-Sent Events support, which is the part that decides whether this works for hot-reload dev servers and live-updating apps.

The architectural consequence is the one users feel most: because everyone shares one Cloudflare account by default, everyone shares one API quota. The README's announcement says the backend receives far more tunnel requests than the Cloudflare API allows and that heavy usage from a few users can rate-limit everyone else.

Installing NPort and opening your first tunnel

Confirm the runtime first. The package declares engines of node >=20.0.0 and npm >=10.0.0, so an older Node will not be a supported configuration.

node --version
npm --version

Install globally from npm, or skip installation entirely with npx. The README presents the npm route as recommended and gives npx as the no-install path.

npm install -g nport
npx nport 3000 -s myapp

With the binary in place, expose the port your dev server already listens on. The README's examples cover Next.js and Vue on 3000 and 8080, and Express on 3000. The -s flag requests a specific subdomain; without it you get a random one such as user-1234.nport.link.

nport 3000 -s my-nextjs-app

What you should see is the banner, a spinner line reading "Creating tunnel for port 3000...", then a public URL, a time budget (the sample output shows "4h remaining"), and two checkmarks for connection and compression. If instead you get "Backend Error: CF API Error: [10429] Rate limited", that is the shared backend, not your machine. The README's own advice is to wait a minute or two and run the command again.

For a webhook receiver, start the local listener, tunnel the port it uses, and paste the resulting URL plus path into the provider's webhook settings. The README's example uses port 4000 and the path /webhook.

node webhook-receiver.js
nport 4000 -s my-webhooks

The CLI also carries a language setting. Supported values are en, vi and es, and the choice is saved after the first interactive prompt.

nport 3000 -l es

The shared quota is the real limitation, not the code

Cloudflare error 10429 is an account-wide API request quota. On the default nport.link backend, that account is shared by every user, so the failure mode is not yours to control. A burst of tunnel creation from someone else can produce a rate-limit error on your machine while your local server is perfectly healthy. The README is unusually direct about this and states plainly that it is not your setup and nothing is broken locally.

The practical consequences are worth spelling out. Starting many tunnels in a tight loop burns API calls, and the README explicitly warns against doing that in CI. A pipeline that creates a tunnel per job will compete with every other user for the same quota, which makes NPort a poor fit for automated test suites that need a guaranteed public URL on every run. The four-hour session budget shown in the sample output is another constraint: this is a tool for a working session, not for a service that should answer requests next week.

Self-hosting is the documented escape hatch. The --backend flag points the client at a different server for one session, and --set-backend persists the choice. The README directs readers to the Backend URL Options section and the server/ directory for running their own backend with their own Cloudflare account. That removes the shared-quota problem, but it moves the operational burden onto you, and the README does not document what running that backend requires in terms of Cloudflare credentials, DNS setup or hosting.

NPort compared with Cloudflare Tunnel and ngrok

The closest alternative is Cloudflare Tunnel itself, through the cloudflared daemon. The difference is where the account lives. With cloudflared you authenticate your own Cloudflare account, create a named tunnel, and map a hostname you control in your own DNS; nothing is shared, and nothing expires in four hours. NPort wraps that flow into one command with a subdomain on nport.link, which is why it needs no account and no configuration. You are trading control of the Cloudflare account and the hostname for the absence of setup. If you already have a domain on Cloudflare, cloudflared gives you a permanent URL that NPort's session model cannot.

ngrok is the other reference point, and the README names it as the thing NPort replaces. ngrok ships a persistent agent, an account, and a dashboard with request inspection; NPort ships a CLI with a subdomain flag and a language flag. The README's own feature list is the honest comparison: instant setup, custom subdomains, automatic HTTPS, WebSocket support, no configuration, cross-platform, English/Vietnamese/Spanish UI, free, MIT licensed. There is no request inspector, no replay, no reserved-domain management in that list. What NPort has that ngrok's free tier historically does not is a custom subdomain without an account, and what it lacks is any guarantee that the subdomain stays available.

A smaller point of divergence: NPort is a Node package. If your environment has no Node 20 runtime, cloudflared's single static binary is the easier install.

Licence, maintenance and what upgrading costs you

NPort is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. The repository carries a LICENSE file at the top level, and the package.json declares "license": "MIT". That is permissive enough for internal tooling at a company, but the licence covers the code, not the nport.link service: the shared backend is a hosted service the project operates, and nothing in the MIT grant obliges it to stay up or stay free. If you need a contractual guarantee, self-hosting under the same licence is the route the README points to.

The last push to the repository was on 2026-08-03, the same day as the v2.1.6 release. The two prior releases, v2.1.5 and v2.1.4, landed in March 2026, so the release cadence is a burst followed by a gap. The repository is not archived. The README's announcement frames v3.0.0 as the release that addresses rate limiting, with friendly 10429 messaging, automatic retry with backoff, smarter tunnel cleanup, higher capacity, bring-your-own Cloudflare account, and usage visibility. None of those are described as shipped.

Upgrade cost is low on the surface: the package has three runtime dependencies and a global npm install replaces the binary. The risk is behavioural rather than mechanical. A v3.0.0 that introduces retry and backoff changes how the CLI behaves under load, and a self-hosted backend may need to match whatever the new client expects. The README does not document a rollback path or a version pinning policy, so pinning nport to a known version in package.json is the only obvious hedge.

Editorial conclusion

Adopt NPort if you need a throwaway public URL for a webhook receiver, a phone test, or a client demo and you are willing to hit Cloudflare error 10429 occasionally. Do not adopt it for CI pipelines or anything that must stay up unattended: the README itself warns against starting tunnels in a tight loop, and the shared nport.link backend quota is account-wide, so another user's traffic can stop yours. Before relying on it, read the Backend URL Options section and the server/ directory, run your own backend against your own Cloudflare account, and check whether v3.0.0 has shipped the bring-your-own-account support the announcement promises.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes