DEV Community: gokul

When Your Local API Needs to Talk to a Real Device

gokul — Fri, 14 Aug 2026 05:23:36 +0000

There is a point in development where testing entirely on your laptop stops being enough.

The API works.

The frontend works.

The emulator works.

Then you pick up an actual phone and discover that the environment you built everything around doesn't exist on the device.

The backend is running on localhost, but the phone can't reach it.

This is less of an application bug and more of a networking problem.

`localhost` doesn't mean what you think it means

Suppose your API is running on:

http://localhost:8080

From the laptop running the API, that address makes sense.

But localhost always refers to the machine making the request.

So when a phone tries to access:

http://localhost:8080

it is looking for a service running on the phone itself, not your laptop.

That's why replacing a production API URL with localhost often fails during mobile testing.

The traditional solution: local network access

One option is to make the backend accessible through your laptop's local IP address.

The architecture becomes:

Physical Phone
       |
       | Wi-Fi
       |
       v
Developer Laptop
       |
       v
Local API :8080

This can work well.

But it introduces several dependencies.

The devices need to be on compatible networks, the server needs to listen on the appropriate interface, and firewall settings may prevent incoming connections.

It can also become inconvenient when testing with someone else's device.

What changes when the device isn't on your network?

This is where development gets more interesting.

Imagine a QA tester has the mobile application on their phone, but your API is running on your laptop at home.

They aren't connected to your local network.

Giving them your laptop's private IP address won't solve the problem.

You need a publicly reachable endpoint that can forward requests back to the development machine.

That's the basic job of a tunnel.

Real Device
     |
     v
Public HTTPS Endpoint
     |
     v
Tunnel
     |
     v
Developer Laptop
     |
     v
Local API

The API remains local.

Only the network path changes.

Why this can be better than deploying every change

A common alternative is:

Change code
   ↓
Commit
   ↓
Build
   ↓
Deploy
   ↓
Test on phone
   ↓
Find a bug
   ↓
Repeat

For early development, that loop can be unnecessarily slow.

A local backend with a temporary public endpoint can look more like:

Change code
   ↓
Backend reloads
   ↓
Test on phone
   ↓
Fix
   ↓
Test again

That shorter loop is valuable when you're actively developing an API.

Tools such as 21tunnel can provide a public endpoint for a local HTTP service, allowing a physical device to reach the backend without moving the entire backend to a hosted environment.

This is useful beyond mobile apps

The same pattern appears whenever an external system needs to reach something running locally.

For example:

A QA device testing an API
A teammate reviewing a development build
A third-party integration calling a local endpoint
A physical IoT device communicating with a development server
A client testing an unfinished application
A remote developer accessing a temporary service

The common requirement is always the same:

Something outside your machine needs to reach a service inside your machine.

Be careful with authentication

Making the API reachable from the internet changes the security model.

A local development API may have been designed under the assumption that only the developer can access it.

That assumption disappears when the endpoint becomes public.

Before exposing a development API, check:

Authentication

Does the API require authentication?

Authorization

Can a test user access administrative functionality?

Sensitive data

Does the development database contain real user information?

Debug endpoints

Are debugging or internal endpoints enabled?

Secrets

Are development credentials stored in responses or logs?

A tunnel solves connectivity. It doesn't automatically solve application security.

HTTPS matters too

Modern mobile applications and third-party integrations can have restrictions around insecure HTTP connections.

A public HTTPS endpoint can make development closer to the conditions the application will encounter outside the local environment.

This is particularly useful when testing functionality that depends on secure network connections.

What about VPNs?

A VPN can also connect devices to a private development network.

That's useful when an organization needs controlled access to internal services.

But a VPN can be more infrastructure than a developer needs for a quick test.

If the requirement is simply:

"I need my phone to reach this API for the next two hours."

a temporary tunnel may be simpler.

If the requirement is:

"Our entire development team needs permanent private access to internal services."

then a VPN or other private networking architecture may make more sense.

The important distinction

Tunneling isn't about making localhost magically public.

It's about creating a controlled network path between an external client and a service that remains local.

That distinction helps developers choose the right architecture.

For short-lived development and testing, exposing only the required service can be much more practical than deploying an entire environment.

A useful mental model

When debugging connectivity problems, ask one question first:

Where is the client, and where is the server?

If both are on the same machine, localhost is straightforward.

If they're on the same local network, private network addressing may be enough.

If they're on completely different networks, you'll need some form of reachable network path.

That could be:

Public deployment
VPN
Reverse proxy
Port forwarding
Tunnel

The right choice depends on the duration, security requirements, and purpose of the connection.

The development environment doesn't always need to move

One of the useful ideas behind tunneling is simple:

Your code can stay where you're developing it.

You don't necessarily need to deploy an application just because another device needs to communicate with it.

For mobile developers, that can mean faster testing on real hardware and a much shorter feedback loop.

The goal isn't to replace staging or production infrastructure.

It's to remove unnecessary networking friction while you're still building the thing.

Your rate limiter is broken behind a tunnel — the X-Forwarded-For problem

gokul — Thu, 13 Aug 2026 06:46:41 +0000

You put your app behind a tunnel (or any reverse proxy) to test
webhooks. Everything works. Then you notice something odd in your logs:
every single request comes from the same IP address.

 Congratulations, you've met the X-Forwarded-For problem.

What actually happens

 When a request flows through a tunnel, the TCP connection to your app

comes from the relay, not the real client. So request.remote_addr —
the value your framework uses for rate limiting, IP logging,
geo-blocking, brute-force detection — is the relay's address. For every
request. From every user.

 The consequences are quiet and nasty:

  Your rate limiter now rate-limits the relay, not the client. One

aggressive user trips the limit and everyone gets blocked. Or worse, the
limit is per-IP and effectively unlimited, because each relay node looks
like one "user."
* Your access logs are fiction. Security review of an incident?
Every entry says the same address.
* IP allowlists silently break. "Only allow my office IP" now
allows nothing, or everything, depending on how it's wired.

The fix (and its trap)

 The proxy already tells you the real client IP — in the

X-Forwarded-For header. Every framework has a setting to trust it.
Flask: ProxyFix. Express: app.set('trust proxy', ...). Rails,
Django, Laravel: equivalents exist.

 Here's the trap: trust that header blindly and anyone can spoof

it. A client can send X-Forwarded-For: 1.2.3.4 directly, and if your
app believes headers from anyone, your rate limiter is bypassed with a
curl flag.

 The correct setup has two halves:

 1. Trust `X-Forwarded-For` only when the immediate connection

comes from a proxy you control (your tunnel relay, your load balancer).
2. Strip or ignore the header on direct connections.

 Most frameworks express this as "trusted proxies" — a list of proxy

IPs whose forwarded headers you believe. Set it. It's five minutes of
config that determines whether your security features are real or
decorative.

Why this matters more in the tunnel era

 Tunnels used to be a demo-day tool. Now they're how teams test

webhooks, preview for clients, and let AI agents reach local
environments — often for days at a time, fronting apps with real auth
and real rate limits. Every one of those apps is behind a proxy, whether
the developer thought about it or not.

 If you're picking a tunnel, this is one of the details that separates

serious ones: does the relay set and document its forwarded headers? We
built 21tunnel to pass real client IPs through
correctly (and gate tunnels at the edge when you don't want the internet
reaching your app at all) — but whatever you use, spend the five minutes
on trusted proxies.

 Your rate limiter will thank you.

Anyone with your tunnel URL can hit your dev machine — the attack surface nobody mentions

gokul — Wed, 12 Aug 2026 07:24:48 +0000

You start your dev server, open a tunnel to show a teammate your
progress, and get a public URL. You paste it in Slack. They click it,
see the app, great. Meeting ends.

 Who else has that URL?

 Your teammate, obviously. Anyone who scrolls back in that channel. Any

bot that scrapes the link. Anyone who guesses the subdomain if it's a
common word. And here's the uncomfortable part: that URL doesn't point
to a hardened production deployment. It points to your laptop. To the
branch you're halfway through breaking. To debug mode, with stack traces
on, maybe with an admin panel that skips auth in development.

 ## Public dev URLs are real URLs

 We treat tunnel URLs as disposable, but for the hours they're live

they're genuine endpoints on the public internet, fronting machines that
were never meant to face it.

 The failure modes aren't exotic:

 * Debug endpoints leaking environment variables through an error page
 * Admin panels that "temporarily" bypass login
 * Webhook receivers that happily process forged payloads from anyone

who finds the URL
* API keys in a .env file one directory-traversal bug away from
disclosure
* The tunnel you opened on Friday that's still running on Monday,
pointed at a branch that no longer exists

None of this needs a sophisticated attacker. It needs a URL, and URLs leak.

 ## What responsible tunnel hygiene looks like

 **Short-lived by default.** A tunnel should be something you open for

a purpose and close when the purpose is done — not infrastructure that
accretes. If your tool ties URLs to expiring keys, use that. An expired
URL is a dead end for anyone who finds it later.

 **Expose one port, not your machine.** If the tunnel can serve your

whole box, a config mistake becomes a much bigger mistake.

 **Gate it when it matters.** If you're showing a client something or

testing against a third-party service for days, put the tunnel behind
sign-in at the edge, before traffic ever reaches your app. Your
application code shouldn't have to know it's being protected.

 **Scoped keys for AI agents.** If you're handing tunnel access to an

AI coding agent — and more teams are every month — don't give it your
master credentials. Give it a key that can open exactly one tunnel, and
revoke it when the task ends. An agent with a permanent tunnel and a
master key is an intern with root access.

 ## The takeaway

 Whatever tool you use, the principle holds: a public URL is a real

URL. Treat your dev machine like the internet can see it — because for
as long as that tunnel is open, it can.

 ---

 *Full disclosure: I work on [21tunnel](https://21tunnel.com), an

open-source tunnel built around this model — scoped, short-lived keys,
cascade revoke, and edge auth that gates any tunnel behind Google
sign-in with zero code changes.*

Webhook signature verification in Node, Python, and Rust — the raw-body trap

gokul — Tue, 11 Aug 2026 07:57:48 +0000

Every serious webhook provider — Stripe, GitHub, Shopify — signs deliveries
with HMAC. Verifying that signature is your only proof an event came from the
provider and not from someone who found your endpoint URL.

 And everyone hits the same trap: **you must verify against the raw request

body, before any parsing.** Re-serialized JSON is not byte-identical to what
was sent. One byte of difference — a space, key ordering — and every signature
check fails with errors that point everywhere except the real cause.

Here's the correct pattern in three languages.

 ## Node (Express)

 ```js
 const crypto = require('crypto');
 const express = require('express');
 const app = express();

 app.post('/webhooks/stripe',
   express.raw({ type: 'application/json' }), // raw body FIRST
   (req, res) => {
     const sig = req.headers['stripe-signature'];
     const expected = crypto
       .createHmac('sha256', process.env.WEBHOOK_SECRET)
       .update(req.body) // Buffer, not parsed JSON
       .digest('hex');

     const received = sig.split(',').find(p => p.startsWith('v1=')).slice(3);
     if (!crypto.timingSafeEqual(Buffer.from(expected),

Buffer.from(received))) {
return res.status(400).send('invalid signature');
}

     const event = JSON.parse(req.body); // parse AFTER verifying
     res.status(200).send('ok');
   }
 );


python
   Python (Flask)



   ```python
     import hashlib, hmac
     from flask import Flask, request, abort

     app = Flask(__name__)

     @app.post('/webhooks/github')
     def github_webhook():
         raw = request.get_data()  # raw bytes, before parsing
         expected = 'sha256=' + hmac.new(
             WEBHOOK_SECRET.encode(), raw, hashlib.sha256
         ).hexdigest()

         received = request.headers.get('X-Hub-Signature-256', '')
         if not hmac.compare_digest(expected, received):
             abort(400)

         event = request.get_json()  # parse AFTER verifying
         return 'ok'

Rust (axum)

     async fn webhook(headers: HeaderMap, body: Bytes) -> Result<&'static str,
   &'static str> {
         let mut mac = Hmac::<Sha256>::new_from_slice(secret.as_bytes())
             .map_err(|_| "bad key")?;
         mac.update(&body); // raw Bytes, not Value
         let expected = hex::encode(mac.finalize().into_bytes());

         let received = headers.get("x-hub-signature-256")
             .and_then(|v| v.to_str().ok())
             .and_then(|v| v.strip_prefix("sha256="))
             .ok_or("missing sig")?;

         if expected != received { return Err("invalid signature"); }
         // serde_json::from_slice(&body) AFTER this point
         Ok("ok")
     }

The three rules

Raw body first. Any middleware that parses the body before verification breaks the signature.
Constant-time comparison. timingSafeEqual / compare_digest — never == on signatures.
Verify, then process, then 200. Acknowledging before the work commits is how events get lost on crashes.

Full walkthrough including idempotency (dedupe on event ID) and retry testing:
testing webhooks locally, the complete guide
(https://21tunnel.com/blog/test-stripe-webhooks-locally/)

Exposing an MCP server to the internet — tunneling guide for Claude Desktop and Cursor

gokul — Mon, 10 Aug 2026 11:02:22 +0000

MCP servers usually run on your localhost — which means hosted
Claude, Cursor on another machine, or a teammate can't reach them.
The fix is a tunnel, but the details matter: which URL survives
restarts, how the config files actually look, and how to avoid
handing your AI tooling a credential it can burn down your account
with.

 This is the full walkthrough.

 ## Why your MCP server is unreachable

 The Model Context Protocol server you just wrote listens on a

local port. That works beautifully when the client is on the same
machine. The moment the client is hosted Claude, a colleague's
Cursor, or anything off-box, localhost becomes a wall: NATs,
firewalls, and the simple fact that localhost:8080 means
something different on every machine.

 A tunnel solves it by running an agent on your machine that

holds a persistent outbound connection to a public edge. Traffic
to your public URL flows down that connection to your local port.

Step 1: Pick a URL that survives restarts

 This is the detail most guides skip, and the one that bites

first. MCP client configs hardcode the server URL. If your tunnel
hands you a new random address on every restart, your config
breaks silently every morning.

 Use a named subdomain so the address is permanent:

 ```bash
 mytunnel http 8080 --subdomain my-mcp
 # ✓ Tunnel active: https://my-mcp.21tunnel.com → 127.0.0.1:8080

That URL is yours across restarts and reboots — paste it into
configs once and stop thinking about it.



   Step 2: Wire up Claude Desktop

   Edit claude_desktop_config.json:



   ```json
     {
       "mcpServers": {
         "my-server": {
           "url": "https://my-mcp.21tunnel.com/sse"
         }
       }
     }

Restart Claude Desktop and the hosted client now talks to the MCP
server on your machine, through the tunnel.

Step 3: Wire up Cursor

Same shape in .cursor/mcp.json:

     {
       "mcpServers": {
         "my-server": {
           "url": "https://my-mcp.21tunnel.com/sse"
         }
       }
     }

Now Cursor on any machine — yours, a teammate's, a CI box — can
reach the same server.

Step 4: Don't hand the agent your master token

If an AI agent is the one opening tunnels, pause here. The default
is exporting your tunnel service's account token into the agent's
environment. That token can typically open unlimited tunnels,
never expires, and shows up in transcripts and logs.

The safer pattern: a master key that cannot open tunnels itself,
which the agent uses to mint its own scoped, short-lived child key
per project:

     eval "$(mytunnel eval mint --project mcp --ttl 4h --output-env)"
     mytunnel http 8080 --subdomain my-mcp

The agent works autonomously, the credential dies on schedule, and
one click cascade-revokes everything it ever created.

Step 5: Gate it if it matters

A public MCP endpoint is a public door. For anything beyond a
quick test, enable edge auth so the URL only responds to signed-in
teammates or an allowlisted domain. One toggle in the dashboard,
no code changes.

That's the whole setup: permanent URL, two config files, scoped
credentials, access control. The full guide with more config
variants: exposing an MCP server to the internet

Why We Rewrote Our Tunnel Stack in Rust

gokul — Fri, 07 Aug 2026 11:34:37 +0000

Testing GitHub Webhooks Locally: A 5-Step Workflow That Actually Holds Up

Setting up a GitHub webhook takes two minutes. You paste a URL into your repository settings, pick your events, and GitHub starts POSTing JSON.

Testing that webhook properly is where everyone gets stuck — your development server runs on localhost, and GitHub's servers cannot reach it. Worse, the failure modes that cause real production incidents (retries, duplicates, out-of-order deliveries) never show up in a happy-path test.

After wiring GitHub webhooks more times than I can count, here's the workflow that actually holds up. Five steps, each addressing a failure I've seen take down a real integration.

Step 1: Get a Stable Public URL

Any tunnel puts your localhost on the internet, but what actually matters is whether the URL survives a restart. GitHub stores your webhook URL in the repository settings — if your tunnel hands you a fresh random address every time the agent restarts, you're editing webhook config every morning, and every mysteriously silent integration is just a stale URL.

Use a named subdomain instead:

mytunnel http 3000 --subdomain gh-hooks

This gives you a permanent https://gh-hooks.21tunnel.com pointing at your local endpoint (e.g. /webhooks/github). Paste that into your repo's webhook settings once, and it keeps working across restarts, reboots, and weekends.

ngrok and Cloudflare Tunnel solve the same problem with different tradeoffs — the requirement is the stable address, not the specific tool.

Step 2: Verify Signatures Over the Raw Request Body

GitHub signs every delivery with HMAC-SHA256, using the secret you set in the webhook configuration, and sends it in the X-Hub-Signature-256 header. This signature is your only proof that an event came from GitHub and not from someone who found your endpoint URL.

The trap that burns afternoons: if your web framework parses the JSON body before your verification code runs, the bytes change. Re-serialized JSON is not byte-identical to what GitHub sent — the signature no longer matches, every event fails verification, and the error messages point everywhere except the real cause.

The fix is the same in every framework: read the raw body first, verify the signature against those exact bytes, and only then parse the JSON.

Express — use express.raw on the webhook route, registered before express.json
Django — read request.body before anything touches the parsed form data

One line of middleware ordering. Get it wrong and nothing works; get it right and you never think about it again.

Step 3: Deduplicate on `X-GitHub-Delivery`

GitHub promises at-least-once delivery. If your endpoint times out, returns an error, or responds too slowly, the delivery comes back — sometimes even when nothing visibly failed.

Every delivery carries a unique ID in the X-GitHub-Delivery header:

Store it with a unique constraint in your database
Do the actual work in the same transaction as the insert
If the insert fails because the ID already exists → the event was already processed → return 200 and move on

Handlers built this way can be retried forever without corrupting state. Handlers built on hope eventually double-create an issue, double-trigger a deploy, or double-charge someone.

Step 4: Replay Deliveries from GitHub's UI

Most developers never notice the Recent Deliveries tab in the webhook settings page. It shows every delivery GitHub attempted — the full request and response — plus a Redeliver button.

Combined with your tunnel's request inspector, this is the fastest debug loop available:

Pick any past delivery
Hit Redeliver
Watch it arrive in the inspector
See exactly how your handler responded

No fake commits, no dummy pull requests, no waiting for real events to trigger the code path you're testing.

Step 5: Test the Failure Paths on Purpose

Happy-path testing tells you the integration works on a good day. Before calling it done:

Return a 500 and watch GitHub's retry behavior
Kill your server mid-delivery
Redeliver the same event twice and confirm the second attempt is a harmless no-op
Disconnect the tunnel, reconnect, and confirm nothing needs manual repair

Each of these takes two minutes. Together they replace the 2 AM incident where you learn all of it at once.

Summary

The complete setup:

Step	What it solves
1. Stable public URL	Webhook config doesn't break on restart
2. Raw-body signature verification	Confirms events actually came from GitHub
3. Idempotent handlers (dedupe on delivery ID)	Prevents double-processing from retries
4. Replay-driven debugging	Fast iteration without fake test data
5. Deliberate chaos testing	Surfaces failure modes before production does

Do these five and moving to production is boring — same handler, same verification, just a new URL and secret in the settings.

Full guide with working verification code in Node, Python, and Rust, plus the retry semantics nobody documents: 21tunnel-blog

Giving AI coding agents a public URL — the master-key delegation pattern

gokul — Wed, 05 Aug 2026 11:55:09 +0000

Your AI coding agent needs a public URL for the preview it just built. Most setup guides tell you to paste your API token into the agent's environment. That token can open unlimited tunnels, never expires, and could be exposed if the agent leaks it. There is a safer pattern that has been used across the industry for years.

Full disclosure: I work with 21tunnel, one of the tunneling services that implements this pattern. While the examples use 21tunnel, the security model applies to any tunneling service.

AI coding agents like Claude Code, Cursor, Aider, and Devin increasingly need to expose localhost so developers can test webhooks, preview applications, or share work with teammates. The real challenge isn't tunneling—it's securely delegating permissions to an autonomous agent.

TL;DR

Don't give your AI agent a permanent API token.

Instead:

Create a master key.
Let the master key mint scoped, short-lived child keys.
The AI agent only receives a temporary child key.
Child keys expire automatically.
If needed, revoke the master key to immediately invalidate every child key it created.

This follows the same security model used by Stripe Restricted Keys, GitHub Fine-Grained Personal Access Tokens, AWS STS, and HashiCorp Vault.

The Problem

Imagine asking Claude Code to:

Create a Next.js application.
Configure a Stripe webhook.
Start the development server.
Expose localhost.
Share the public URL.

The agent needs credentials to create the tunnel.

There are three approaches:

Give the agent your personal API token.
Create another account for the agent.
Give the agent permission to mint temporary credentials.

The first two provide broad, long-lived permissions.

The third provides only the permissions required for the current task.

Why Permanent Tokens Are Risky

Using a permanent API token introduces several problems:

The token may appear in logs or chat transcripts.
The token never expires.
Revoking it affects every application using it.
The token usually has more permissions than the task requires.

The AI agent only needs to create one temporary tunnel—not full account access.

The Master-Key Pattern

The pattern uses three components.

Master Key

Long-lived
Can mint child keys
Cannot directly create or manage tunnels

Child Key

Short-lived
Limited to one project
Automatically expires
Cannot mint additional keys

Cascade Revoke

Revoking the master key immediately invalidates every child key created from it.

Benefits

Short-lived credentials
Project isolation
Easy compromise recovery
Reduced blast radius

Industry Examples

This isn't a new idea.

Examples include:

Stripe Restricted API Keys
GitHub Fine-Grained Personal Access Tokens
AWS STS AssumeRole
OpenAI Service Accounts
HashiCorp Vault Dynamic Secrets

All follow the same principle:

Long-lived credentials should only create short-lived credentials.

Creating a Project

mytunnel projects create staging-preview

Example output:

Project created: proj_8f3a2b

Master key:
mtk_master_a1b2c3...

Store the master key securely.

Minting a Child Key

MTK_MASTER=mtk_master_xxxxx \
mytunnel eval mint \
    --project staging-preview \
    --ttl 1h \
    --output-env

Example output:

export MYTUNNEL_AUTH_TOKEN=mtk_child_xxxxx
export MYTUNNEL_PROJECT=staging-preview

The child key:

Works only within one project
Cannot mint more keys
Automatically expires
Appears in the audit log

Revoking Everything

mytunnel keys revoke --cascade mtk_master_xxxxx

Output:

Revoked 1 master key.

Revoked 17 child keys.

Example Configuration

Claude Code

.claude/settings.local.json

{
  "env": {
    "MTK_MASTER": "mtk_master_xxxxx"
  }
}

Agent instructions:

When localhost needs to be exposed:

1. Mint a temporary child key.
2. Start the tunnel.
3. Return the public URL.

Cursor

Store the master key in a gitignored .env.
Add rules instructing the agent to mint a child key before opening a tunnel.

Aider

Store the master key in:

.aider.env

Start with:

aider --env-file .aider.env

Devin

Store the master key as a workspace secret.

Each workspace receives temporary credentials without exposing permanent account access.

Design Decisions

The implementation intentionally avoids:

Agent-specific SDKs
MCP servers for tunnel management
Additional machine-key types
IP allowlists for temporary credentials
OAuth-based agent authentication

A simple CLI and temporary credentials provide a smaller attack surface while remaining compatible with every AI coding agent.

What Every Tunneling Service Should Provide

A secure delegation system should include:

A master key that cannot directly create tunnels.
Child keys with enforced expiration.
One-step cascade revocation.
Project-level isolation.

As AI agents become part of everyday development workflows, developers will increasingly expect temporary, scoped credentials instead of permanent API tokens.

FAQ

Why not give the AI agent my normal API token?

Because permanent tokens provide broad permissions, never expire, and are difficult to revoke selectively.

What is cascade revoke?

A single action that invalidates the master key and every child key created from it.

Can this pattern work without 21tunnel?

Yes.

Any tunneling service can implement scoped temporary credentials. The examples here simply demonstrate one implementation.

10 ngrok alternatives in 2026 — tested, ranked, honestly

gokul — Tue, 04 Aug 2026 09:51:05 +0000

Every credible ngrok alternative in 2026, tested and scored on a reproducible 8-dimension rubric — setup, stable URLs, custom domains, self-hosting, AI-agent delegation, pricing, inspector, polish.

I maintain one of the tools on this list, so let me get that out of the way up front: yes, 21tunnel is ranked #1 and yes, I'm biased — every competitor was scored on the same reproducible rubric, and I link the scoring method so you can rerun it yourself.

I got here the honest way: my ngrok free tier ran out mid-demo, I rage-tested every alternative I could find, and the notes turned into a benchmark. Here's what actually matters when you pick a tunnel in 2026 — and where each tool genuinely wins.

ngrok is the default tunneling service and has been for a decade. That's worth something. But "default" isn't "best for you" — the free-tier subdomain churn breaks webhook integrations, the paid tier starts at ~$10/mo for a single reserved domain, the server is closed-source SaaS-only, and the AI-agent delegation story is still your-personal-token-in-an-env-var. Below: every credible ngrok alternative in 2026, scored on a reproducible 8-dimension rubric, with honest verdicts on which one fits which job.

TL;DR

Quick verdict by use case:

Default + polish — ngrok still wins on documentation, dashboard polish, and the size of the existing Stack Overflow / Reddit answer pool.
Free + custom domain — Cloudflare Tunnel, if your domain is on Cloudflare DNS.
Simplest setup, no install — Pinggy.io, one SSH command.
Self-host the whole stack — 21tunnel (Rust, MIT + Apache-2.0), frp (Go, Apache-2.0), or bore (Rust, MIT).
Building for AI coding agents — 21tunnel (master key + scoped child keys + cascade revoke). Every other alternative leaks your full-access token to the agent.
Already on Tailscale — Tailscale Funnel is built into your existing mesh, no second tool needed.

How we scored

Eight dimensions, each scored 0–2, then summed for a 0–16 composite. We score on what's in each product's documented free tier (or its lowest paid tier if there's no free tier) as of 2026-05-11. Pricing accurate on the date of writing; the SaaS pricing pages drift, so the absolute numbers age — the relative ranking shouldn't change much.

Setup friction — 0 = needs account + auth token before first run. 2 = single command, no account.
Stable URL on free tier — does the URL survive a tunnel restart? Webhook integrations depend on this. 0 = no. 2 = yes, including a reserved or custom subdomain.
Custom domain on free tier — bring your own domain at $0. 0 = paid only. 2 = free.
Self-hostability — can you run the server-side yourself? 0 = no, SaaS only. 2 = open-source server you can run on your own VM.
AI-agent delegation — does it have a master-key pattern so an AI agent can mint short-lived scoped child keys without holding your god-mode token? 0 = no. 2 = first-class, with cascade revoke.
Pricing transparency — does the public pricing page tell you the full cost of the use case you're shopping for? 0 = "contact us". 2 = simple table.
Request inspector / audit log — can you see and replay what came through? 0 = no. 2 = yes, on free or lowest paid tier.
Polish + ecosystem — docs, dashboard, editor extensions, community size. 0 = barely functional. 2 = best-in-class.

We do not score on "is the company old" or "do investors like it" — those don't matter for the decision you're making. We also don't score raw throughput because every tunneling service is fast enough for development. Sustained production traffic is a different question (none of these are built for that).

The 10 alternatives, ranked

21tunnel — 15/16

Best for: developers building AI-agent workflows, anyone who wants to self-host the entire stack on their own VM, and developers who want a custom domain on a free tier without being locked into Cloudflare DNS.

21tunnel ships an open-source Rust server (TLS 1.3 + yamux multiplexing), an open-source CLI agent (mytunnel), and a hosted dashboard. Free Hobby tier includes 3 concurrent tunnels, 10 Mbps per tunnel, 20,000 requests/month, and custom domain support on signup. Pro is $10/mo flat.

The differentiator is the AI-agent delegation primitive: a mtk_master_ key can mint scoped child keys with TTL, organized into project namespaces with subdomain isolation, with one-click cascade revoke. Same shape Stripe / OpenAI / Resend use for service accounts, applied to tunnels.

Scoring: setup 1 (account needed) · stable URL 2 · custom domain free 2 · self-host 2 · AI-agent delegation 2 · pricing 2 · inspector 2 · polish 2.

Caveat: we made it. Smaller community than ngrok — the Stack Overflow answer pool is thinner. We made up for it with explicit docs but you'll occasionally have to read source.

ngrok — 12/16

Best for: people who want the safe default, have heard of ngrok, and don't need the cheapest or most open option.

ngrok is the category leader and has been since 2015. The agent is open-source on GitHub; the server is proprietary SaaS. Free tier gives you one tunnel with an ephemeral subdomain — fine for a one-off, painful for daily webhook development because the URL changes every restart. Personal ~$10/mo gets you a reserved your-name.ngrok.io. Pro ~$20/mo adds custom domains and multiple concurrent tunnels. Documentation is genuinely excellent — the docs site is one of the best in the developer-tools space.

Scoring: setup 1 · stable URL 0 (free ephemeral) · custom domain free 0 · self-host 0 · AI-agent delegation 1 (auth tokens exist but no scoped child keys) · pricing 2 · inspector 2 · polish 2.

Honest: if you've used ngrok for years and you're happy, the migration cost to anything else isn't worth the savings. Switch when you hit a specific pain point — webhook URL churn, custom-domain pricing, or AI-agent delegation needs.

Cloudflare Tunnel — 12/16

Best for: developers whose domains are already on Cloudflare DNS. Genuinely free for the use case most people care about (one custom-domain tunnel).

Cloudflare Tunnel (formerly Argo Tunnel) is part of Cloudflare's Zero Trust suite. You run cloudflared on your machine, it opens an outbound connection to Cloudflare's edge, traffic for your domain (which must be on Cloudflare DNS) rides through to localhost. Custom domain, free TLS via Cloudflare, all included. Optional Cloudflare Access for auth (free up to 50 users). The setup is heavier than ngrok — you're configuring a DNS record and a cloudflared service — but once it's running, it's just there.

Scoring: setup 1 (requires CF account and DNS setup) · stable URL 2 · custom domain free 2 · self-host 0 (Cloudflare edge is proprietary) · AI-agent delegation 1 (service tokens exist, no first-class child-key mint) · pricing 2 · inspector 0 · polish 2.

Honest: if your domain isn't on Cloudflare DNS, the migration to get this working might cost you more than just paying ngrok or 21tunnel for a year.

Pinggy.io — 10/16

Best for: the absolutely-zero-install case — you just want to run one SSH command, get a URL, share it.

Pinggy is a small, focused tunneling service with an elegant pitch: SSH is already installed everywhere, so use SSH as the agent. ssh -p 443 -R 0:localhost:3000 a.pinggy.io and you get back a HTTPS URL. No binary to install, no account for the free tier, works on Windows / macOS / Linux uniformly. Paid tier ~$3/mo adds reserved subdomains and longer session timeouts.

Scoring: setup 2 (one SSH command) · stable URL 0 (free tier session expires hourly) · custom domain free 0 · self-host 0 · AI-agent delegation 0 · pricing 2 · inspector 1 (web inspector on paid tier) · polish 1.

Honest: the cheapest paid tier in the category. If "I just need a URL right now" is your only requirement, Pinggy is the lightest tool here.

Localtunnel — 8/16

Best for: indie / hobby projects, npm users who want a free tunnel without an account.

Localtunnel is an npm package (npx localtunnel port 3000) that gives you a *.loca.lt subdomain forwarding to localhost. Free, no account. It's maintained by volunteers, uptime is best-effort, and it occasionally goes down for hours. Don't build a webhook-critical workflow on it; do use it for a quick share.

Scoring: setup 2 (one npx command) · stable URL 0 · custom domain free 0 · self-host 1 (the server is open-source on GitHub but running it is fiddly) · AI-agent delegation 0 · pricing 2 (free) · inspector 0 · polish 1.

Honest: indie spirit, modest reliability. Treat it as a community amenity, not infrastructure.

Tailscale Funnel — 10/16

Best for: teams already on Tailscale who want to expose one localhost service to the public internet without adding a second tool.

Tailscale Funnel is Tailscale's "expose a service from your tailnet to the public internet" feature. If you already run Tailscale, Funnel lets you mark a service public with one command — no new binary, no new dashboard. It rides Tailscale's existing auth (SSO, ACLs, device posture).

Scoring: setup 1 (already-on-Tailscale prerequisite) · stable URL 2 (uses your tailnet hostnames) · custom domain free 1 (limited) · self-host 0 · AI-agent delegation 1 · pricing 2 · inspector 0 · polish 2.

Honest: if you're not on Tailscale, the cost of adopting Tailscale just to use Funnel is way more friction than installing ngrok. Don't pick this as your first tunnel tool.

bore — 8/16

Best for: minimalists who want the simplest possible self-hostable Rust binary.

bore is a single Rust binary that does one thing: TCP tunneling. Run bore server on a VPS, bore local 3000 to your-server.com on your laptop, done. No HTTPS termination, no dashboard, no web inspector — that's the point. You bring your own TLS via Caddy in front. MIT-licensed, tiny codebase (~1,500 lines), genuinely simple.

Scoring: setup 1 (need a VPS) · stable URL 2 · custom domain free 2 (you set up DNS) · self-host 2 · AI-agent delegation 0 · pricing 2 (free + VPS cost) · inspector 0 · polish 1.

Honest: if you want a tunnel and you're comfortable running a server, bore is the right pick for the philosophical-minimalist case. Doesn't try to be a product.

serveo — 7/16

Best for: quick one-offs over SSH; no install on most platforms.

serveo is an SSH-based tunnel service. ssh -R 80:localhost:3000 serveo.net and you get a https://*.serveo.net URL. No account, no install. It's run by an independent operator and goes down occasionally; reliability is similar to Localtunnel.

Scoring: setup 2 · stable URL 1 (best-effort subdomain) · custom domain free 0 · self-host 0 · AI-agent delegation 0 · pricing 2 (free) · inspector 0 · polish 1.

Honest: historically reliable, but single-operator means single point of failure. Fine as a backup; not infrastructure.

localhost.run — 7/16

Best for: developers who like serveo's shape but want a more actively-maintained alternative.

localhost.run is essentially serveo's spiritual sibling — SSH-based tunneling, no install, no account for the free tier. Free tier gives you a *.lhr.life URL with hourly rotation; paid tier ~$5/mo gives you reserved subdomains and custom domains.

Scoring: setup 2 · stable URL 0 (free) · custom domain free 0 · self-host 0 · AI-agent delegation 0 · pricing 2 · inspector 1 (paid tier) · polish 2.

Honest: nicer dashboard than serveo, paid tier is one of the cheapest in the category. Picks up where serveo leaves off.

frp — 9/16

Best for: self-host purists who want the most flexibility.

frp (Fast Reverse Proxy) is a Go-based self-hostable tunneling stack. Run frps on a server, frpc on your machine, configure TOML, done. Supports TCP / UDP / HTTPS / STCP / XTCP — the most protocol variety on this list. Apache-2.0 licensed. Documentation is partially Chinese-first; the English docs are good but thinner.

Scoring: setup 0 (TOML config) · stable URL 2 · custom domain free 2 · self-host 2 · AI-agent delegation 0 · pricing 2 · inspector 0 · polish 1.

Honest: if you want maximum flexibility and don't mind a steeper learning curve, frp is the most configurable thing on this list. If you want a product, not a toolkit, look elsewhere.

How to pick

If you want the default and don't want to think about it: ngrok. The docs are excellent, the Stack Overflow answer pool is the largest, and the primitive (a tunnel from a public URL to localhost) is the same everywhere.

If your domain is already on Cloudflare DNS: Cloudflare Tunnel. Free, custom domain, integrates with Cloudflare Access for auth. Setup is heavier than ngrok's but it's a one-time cost.

If you need the cheapest possible paid tier: Pinggy at ~$3/mo or localhost.run at ~$5/mo. Both work over SSH; the differentiator is dashboard polish.

If you want to self-host the entire stack: 21tunnel (if you also want a dashboard and a product), frp (if you want maximum protocol variety), or bore (if you want the smallest binary).

If you're building AI-agent workflows: 21tunnel. The master-key pattern was built specifically for this case — every other tool on this list leaks your god-mode token to the agent.

If you're already on Tailscale: Funnel. It's already paid for.

Frequently asked questions

What's the best free alternative to ngrok in 2026?
Cloudflare Tunnel if your domain is on Cloudflare DNS (custom domain free, no time limits). Pinggy if you want zero install. 21tunnel's free Hobby tier if you want 3 concurrent tunnels + custom domain + an upgrade path to AI-agent delegation.

Is there a fully open-source alternative to ngrok?
Yes: 21tunnel (Rust, MIT + Apache-2.0, server + agent + dashboard), bore (Rust, MIT, agent + server), frp (Go, Apache-2.0). ngrok itself open-sources only the agent.

Why is ngrok so expensive compared to alternatives?
Brand inertia. They were first and they're still the default. Cloudflare Tunnel undercuts on price (free), 21tunnel undercuts on feature-for-feature pricing ($10/mo with custom domain vs ngrok's $20/mo Pro), Pinggy undercuts on absolute price (~$3/mo).

Can these handle production traffic?
Honestly, no — none of these are designed for sustained production traffic. They're development tools. If you need a public endpoint for a production app, terminate at a normal CDN / load balancer and connect to your real backend.

Which alternative is best for AI coding agents?
21tunnel, because of the master-key delegation pattern. The agent gets a short-lived scoped child key, not your god-mode token. Cascade revoke from the dashboard nukes every key the agent ever minted in one click. ngrok and Cloudflare Tunnel both work but require giving the agent a higher-privilege token than ideal.

What about self-hosted ngrok v1?
ngrok's v1 was open-source. v2 onwards is closed. The v1 codebase still exists on GitHub but is unmaintained and missing a decade of fixes. Don't deploy it to production. Use frp or 21tunnel for the self-host case.

Want to try the open-source alternative we ranked #1? 21tunnel is free on Hobby (3 tunnels, 10 Mbps per tunnel, 20,000 requests/month, custom domain on signup) and Pro is $10/mo flat. Or run the whole stack on your own VM — dual MIT + Apache-2.0 license, no SaaS dependency.