Will Stripe, Auth0, Slack and other webhook senders accept the tunnel URL?

Yes. Nodetonet issues real Let's Encrypt certificates trusted by every modern TLS stack. External services like Stripe, GitHub, Shopify, Twilio, Auth0, Okta, Slack and Discord all verify the full certificate chain — they accept a public CA-signed cert without any configuration, whereas self-signed certs are rejected outright.

Does the subdomain stay the same when I restart my agent?

Yes. Reserved subdomains are persistent — myapp-dev.nodetonet.com keeps the same URL across agent restarts, machine reboots and network changes. Register it with Stripe or your OAuth provider once. Free-tier tunneling tools typically assign a new random subdomain each restart, which forces you to re-register every time.

Can I use my own custom domain (e.g. dev.myapp.com)?

Yes. Add a CNAME record from dev.myapp.com to cname.nodetonet.com, then bind the domain to the tunnel in the panel. Nodetonet auto-issues and auto-renews the Let's Encrypt certificate for your custom domain. This is useful when you want Stripe's webhook metadata to show your production domain rather than a nodetonet.com subdomain.

Will service workers and PWA features work through the tunnel?

Yes. Service workers, PWA installation, background sync and push notifications all require a "secure context" — a real valid TLS chain on the origin. Because Nodetonet terminates a real Let's Encrypt certificate at the edge, your browser sees a fully trusted HTTPS origin and all secure-context APIs function normally. The same applies to WebAuthn and the Credential Management API.

How much does an HTTPS dev tunnel cost?

Nodetonet bills on prepaid credit with no monthly subscription — you pay only while the tunnel is active. An always-on personal dev tunnel costs roughly $1/month; a tunnel used only during business hours and weekdays costs a fraction of that. A hackathon weekend costs cents. There is no per-seat fee, so a five-person team sharing a pool of tunnels pays for actual active time, not seats.

Can I restrict which IPs can reach my dev tunnel?

Yes. Each tunnel supports a per-tunnel IP allowlist so you can accept connections only from specific IP ranges — for example, Stripe's published webhook IP ranges, your office's egress IP, or a CI server. Anything outside the allowlist is rejected before it ever reaches your local machine. See our IP allow/deny lists guide for the setup steps.

How is Nodetonet different from ngrok for local HTTPS development?

The key practical differences: Nodetonet's subdomains are stable across restarts at no extra cost (ngrok charges for reserved domains); pricing is prepaid usage rather than per-seat subscription; and the same account also runs mobile proxies, rotating proxy pools and VPN if your project needs them. See the full comparison at Nodetonet vs ngrok.

Nodetonet for local HTTPS — develop OAuth, webhooks and service workers without self-signed certs

You are building a feature that genuinely needs HTTPS: OAuth login, Stripe webhooks, a service worker, SameSite=None; Secure cookies, or WebAuthn. The browser refuses to cooperate until the URL starts with https:// — and self-signed certificates either do not work at all (Stripe will not POST to them) or eat half an afternoon wrestling with mkcert, certutil, browser trust stores and OS keychains.

TL;DR: Nodetonet issues a real, auto-renewing Let's Encrypt certificate on a stable subdomain in about 60 seconds. Your OAuth provider, Stripe, every webhook sender and the browser all trust it immediately — no self-signed warnings, no re-registering a new random URL after every restart.

Why local HTTPS is hard

Three approaches developers reach for, and the sharp edge each one has:

Approach	What it fixes	What it breaks
Self-signed cert + `mkcert`	Your own browser trusts it	Stripe, Twilio, Slack and any external webhook sender refuse untrusted certs
`chrome://flags` "allow insecure localhost"	Chrome stops warning	Service workers still require a real secure context; push notifications fail; PWA install blocked
Generic tunneling service	Real cert, public URL	New random subdomain on every restart breaks every registered redirect URI; per-seat pricing adds up

The root cause is that browsers and external services validate the full TLS chain, not just whether you accept the certificate in your own browser. Only a real publicly-trusted CA — like Let's Encrypt — satisfies all of them at once.

How Nodetonet fits into local HTTPS development

Create one HTTP tunnel pointing at http://127.0.0.1:3000 and bind it to a subdomain you control (or one we provide). Nodetonet's edge terminates TLS with an auto-issued, auto-renewing Let's Encrypt certificate. From that moment:

Your browser sees a fully valid certificate chain — no warnings.
Stripe delivers webhooks. Auth0 / Okta / Clerk accept the redirect URI. Slack sends Events API payloads. None of them have to trust anything unusual.
Service workers register and install normally because the origin is a real HTTPS secure context. PWA installation and push notifications work.
WebAuthn and Credential Management API function without flags or workarounds.
Secure cookies with SameSite=None; Secure set and transmit correctly.

Beyond the certificate, Nodetonet adds developer-quality controls for this workload:

Reserved, persistent subdomains — myapp-dev.nodetonet.com stays the same across agent restarts. Register it with your OAuth provider once and forget it.
Custom domain support — point dev.yourapp.com via CNAME so Stripe sees your real production domain in webhook metadata.
Per-tunnel IP allowlist — restrict inbound connections to Stripe's IP ranges during testing. See how allowlists work in our IP allow/deny guide.
HTTP/2 on the edge — the browser's network panel shows real HTTP/2 frames, not a downgraded connection.
Wildcard SSL coverage — one cert covers all your subdomains; details in wildcard SSL certificates.
Prepaid, no subscription — pay only while the tunnel is active. Read the pay-as-you-go pricing model.

Step-by-step: HTTPS on localhost in 5 steps

Create an account at /auth/register and add a small prepaid credit.
Download and run the Nodetonet Windows agent (.exe) on your development machine.
In the panel, create an HTTPS tunnel: target http://127.0.0.1:3000, subdomain myapp-dev (yields myapp-dev.nodetonet.com).
Wait about 30 seconds for Let's Encrypt to issue the certificate. Then open the URL — your local app, served over real HTTPS, trusted by everything.
Paste https://myapp-dev.nodetonet.com/auth/callback into your OAuth provider's redirect URI list, and the same URL into Stripe's webhook endpoint field. Done — no re-registration needed across restarts.

Scripting the tunnel for team workflows

Teams often want the tunnel to spin up automatically alongside the dev server. Here is a minimal shell script that creates the tunnel via the REST API, prints the public URL and tails the request log — suitable for a package.json dev:tunnel script or a CI preview environment:

#!/bin/bash
set -e

API="https://nodetonet.com/api/v1"
TOKEN="${API_TOKEN:?set API_TOKEN env var}"

# Create an HTTPS tunnel targeting localhost:3000
PROXY=$(curl -s -X POST "$API/proxies"   -H "Authorization: Bearer $TOKEN"   -H "Content-Type: application/json"   -d '{
    "type": "https",
    "target": "http://127.0.0.1:3000",
    "subdomain": "myapp-dev"
  }')

URL=$(echo "$PROXY" | jq -r '.public_url')
ID=$(echo "$PROXY" | jq -r '.id')
echo "Tunnel live: $URL"

# Tail the request log every 2 seconds
while true; do
  curl -s "$API/proxies/$ID/requests?limit=10"     -H "Authorization: Bearer $TOKEN"     | jq -r '.[] | "\(.ts) \(.method) \(.path) -> \(.status)"'
  sleep 2
done

Drop this into scripts/dev-tunnel.sh and add "dev:tunnel": "bash scripts/dev-tunnel.sh" to your package.json. See also programmatic tunnel creation in Python and the REST API quick-start for other language examples.

Webhook development with Nodetonet

Local HTTPS is only half the webhook story. The other half is inspecting, replaying and debugging what actually arrived. A few practices that work well with Nodetonet tunnels:

Request inspection — log every inbound payload via the REST API and compare against your handler's output. The audit logs guide covers what is available.
Domain allow/deny — for multi-tenant dev, restrict the tunnel to only your own services. See domain restrictions.
Monitoring tunnel health — confirm the tunnel is up before running an integration test suite. Details in monitoring your tunnel health.

When a tunnel is not the right tool

Browser-only HTTPS. If you only need your own browser to trust your local app, mkcert is free and sufficient — no tunnel needed, no external traffic.
Air-gapped or offline development. Tunnels need an outbound internet connection. Fall back to self-signed certs when offline.
Sub-millisecond latency profiling. Each request adds a round-trip through the edge (~10–30 ms). Fine for OAuth and webhooks; worth measuring if you are profiling something time-critical.

Related Nodetonet capabilities

HTTP tunnels are just one layer of what Nodetonet offers. The same panel also runs mobile proxies, rotating proxy pools, SOCKS5 proxies, geo-targeted exits and a full VPN — all billed on the same prepaid credit, no per-feature subscription. If you are evaluating alternatives, see Nodetonet vs ngrok or Nodetonet vs Cloudflare Tunnel.

Ready to test? Create a free account, set up the tunnel in under five minutes and stop fighting self-signed certificates.