Nodetonet for IoT development — expose ESP32, Raspberry Pi or MQTT brokers safely

You're prototyping an ESP32 firmware. The device hangs off your home Wi-Fi. The web UI it serves is genuinely useful — but only when you're on the same LAN. The MQTT broker on your Raspberry Pi talks to half a dozen sensors, but the dashboard you're building lives on a Vercel preview deploy that has no way to reach 192.168.1.42:1883.

TL;DR: Nodetonet HTTP tunnels bridge the gap between devices inside a home router and services on the open internet — over a real HTTPS domain, with TCP pass-through for MQTT, per-tunnel IP allowlists, and a pay-as-you-go model that makes a weekend prototype cost less than a coffee.

This is the IoT-developer trap: the device is in your network; the consumer of that device is increasingly not. Tunneling solves this — and unlike a generic "make a web app reachable" tunnel, IoT workloads have specific needs: TCP for MQTT and Modbus, custom domains so device URLs are memorable, regional edge servers so latency stays low, and per-tunnel access controls so the rest of the internet cannot poke your homelab.

The problem with IoT prototyping

Three things make IoT different from a normal web app:

• Protocols are not all HTTP. MQTT (1883/8883), Modbus TCP (502), raw TCP serial bridges, RTSP video streams. A generic HTTP-only tunnel does not help here.
• Devices live behind home routers. CGNAT, dynamic IPs, no inbound ports. You cannot just "point a CNAME at the device".
• Security blast radius matters. An exposed Mosquitto broker with no auth is a 30-second walk-in for any IoT scanner. You need IP allowlists or token auth on the tunnel itself, not just inside the app.

Generic tools — ngrok, Cloudflare Tunnel, LocalToNet — solve the reachability problem but leave the rest half-answered. See how they compare in our Nodetonet vs ngrok, vs Cloudflare Tunnel and vs LocalToNet pages.

How Nodetonet fits IoT workloads

For each device you want to reach from the outside, you create one of two tunnel types:

1. HTTP tunnel with auto-issued Let's Encrypt certificate — for the ESP32 web UI, the Home Assistant dashboard, the Grafana panel on your Pi, the Node-RED editor. The cert auto-renews before it expires.
2. TCP tunnel for everything else — MQTT, Modbus, RTSP cameras, raw socket protocols. The edge holds an open TCP listener and proxies bytes to your device with no HTTP parsing in the way.

Both tunnel types share a common set of features that matter for IoT work:

• Custom domains. esp32.yourname.dev, mqtt.yourname.dev — URLs are stable and shareable with collaborators, not random subdomains that change on restart. See bringing your own domain.
• Regional edge servers. Pick the region closest to where your dashboard (or your customer) lives so the round-trip stays minimal.
• IP allowlists. Add your office IP and your dashboard backend's egress range; drop everyone else at the edge before any traffic reaches your device. The IP allow/deny guide walks through the setup.
• Audit log. 30 days of per-tunnel events — timestamp, source IP, bytes transferred. When something behaves unexpectedly you can see exactly who connected. See audit logs: who used your tunnel.
• Tunnel health monitoring. The panel shows live connection counts and data rates. Read monitoring your tunnel health for alerting options.

Tunnel type comparison for IoT protocols

Step-by-step setup: Raspberry Pi as an MQTT beta server

Here is a concrete walkthrough — a Raspberry Pi running Mosquitto and Home Assistant, reachable from a Vercel-hosted dashboard:

1. Install the Nodetonet Windows agent (/download) on a PC on the same LAN as the Pi, or install the Linux agent directly on the Pi. See installing the agent.
2. On the panel, create a TCP tunnel: target 127.0.0.1:1883, bind mqtt.yourname.dev, choose the edge region nearest to your dashboard hosting.
3. Add an IP allowlist: include the Vercel egress range and your laptop's IP. Everyone else hits connection-refused at the edge.
4. Create a second tunnel — HTTPS to 127.0.0.1:8080 — for the Home Assistant web UI. Bind ha.yourname.dev. The cert auto-issues in roughly 30 seconds.
5. Update your dashboard environment variables: MQTT_HOST=mqtt.yourname.dev, MQTT_PORT=1883. Deploy. Done.

The agent on the Pi reconnects automatically after reboots, so the tunnel stays live as long as the Pi is running. Read device health: what "online" means for the reconnection behaviour.

Code example: ESP32 publishing to your tunneled broker

An ESP32 Arduino sketch publishing temperature readings to the Mosquitto broker on your Pi via the Nodetonet tunnel. The ESP itself needs no special config — it talks to mqtt.yourname.dev:1883 exactly as if the broker were a cloud service:

#include <WiFi.h>
#include <PubSubClient.h>

const char* SSID      = "homewifi";
const char* PASS      = "supersecret";
const char* MQTT_HOST = "mqtt.yourname.dev";
const int   MQTT_PORT = 1883;

WiFiClient   net;
PubSubClient mqtt(net);

void setup() {
  WiFi.begin(SSID, PASS);
  while (WiFi.status() != WL_CONNECTED) delay(200);
  mqtt.setServer(MQTT_HOST, MQTT_PORT);
  while (!mqtt.connect("esp32-kitchen", "user", "pass")) delay(500);
}

void loop() {
  float t = readDHT22();
  char buf[16];
  snprintf(buf, 16, "%.1f", t);
  mqtt.publish("home/kitchen/temp", buf, true);
  delay(30000);
}

Notice that the sketch is identical to what you would use against any cloud MQTT endpoint. The tunnel is transparent to the ESP32 firmware. You could host a cloud MQTT broker for a monthly fee per device fleet — or keep using the broker on the Pi you already own, reachable through a per-day tunnel that costs nothing when stopped.

Automating tunnel management via the API

For teams running automated test rigs, Nodetonet exposes a REST API so you can create tunnels on-demand, tear them down after a test run, and never pay for idle time. See REST API: your first call for the authentication and endpoint reference, and programmatic tunnel creation in Python for a full CI integration example.

A typical CI flow:

1. Build step spins up a tunnel to the device-under-test.
2. Test suite runs against the public tunnel URL.
3. Post-test teardown deletes the tunnel. Billing stops.

Pricing for this workload

Nodetonet uses prepaid credit — no monthly subscription, no per-GB charge on tunnel data. Each tunnel accrues a small daily charge only while it is active. Typical IoT-developer setups:

• Single-device prototype (1 HTTP tunnel for the ESP32 web UI): roughly $1/month active.
• Home automation stack (MQTT + Home Assistant web UI + Node-RED + Grafana = 4 tunnels): roughly $4/month active.
• Customer demo over a weekend (1 tunnel, 3 days, then stopped): under $0.15 total.
• Automated CI rig (tunnel alive only during the build, ~10 minutes/day): fractions of a cent per run.

Compare that with a managed IoT cloud subscription (typically $10–50/month minimum before data charges), or running everything on a public VPS where you still need a tunnel or VPN for the device side and pay for compute that was already in your home. Read introducing pay-as-you-go pricing for the full model.

When Nodetonet tunnels are not the right fit

• Large device fleets. At a scale of thousands of devices you want a purpose-built IoT platform — AWS IoT Core, EMQX Cloud — with device shadow, OTA pipelines and fleet certificate management. Nodetonet is built for the prototype-to-pilot phase, not a mass-production rollout.
• Strictly UDP protocols today. CoAP, LwM2M-over-UDP and SRT video require UDP, which TCP tunnels do not carry. Until UDP support ships, use a Nodetonet VPN or a WireGuard overlay for those protocols.
• Device-side mutual TLS at the tunnel layer. Presenting a client certificate at the tunnel ingress (not inside the application) is not yet supported. Application-layer token auth is the current approach.

For a single developer prototyping on a Pi, or a small team running a beta with a handful of ESP32 boards: Nodetonet is the shortest path from "works on my desk" to "works from a customer's phone". Create a free account and have your first tunnel live in under a minute.