tollanA secure URL for every device.
Give every field device a cryptographic identity and a private or public URL — without opening a port.
Certificate active · agent connected
TLS passthrough · payload private
mTLS edge rule · IP allowlist
Basic auth · audit logged
Live tunnel health · outbound only · no inbound ports
- Outbound only
- No firewall holes or exposed device ports.
- Per-device identity
- Each agent connects with its own certificate.
- Payload private
- The relay routes passthrough traffic without decrypting it.
Built for the places remote access usually breaks
Start with the device or network problem in front of you, then use the same Tollan model as the fleet grows.
PLCs behind firewalls
Support machine networks without asking IT to open an inbound port.
Raspberry Pi behind CGNAT
Give a Pi a stable URL when dynamic DNS and port forwarding cannot help.
ESP32 from anywhere
Expose a board or prototype through the same outbound access model.
Weighing it up: Tollan vs a VPNTollan vs ngrokWithout port forwardingBehind CGNAT
A tiny device can answer at a normal HTTPS address.
Tollan is designed for the mixed reality of field work: microcontrollers, gateways, routers, lab machines, and customer networks that you do not control.
- Give each device a named route instead of asking for a VPN profile.
- Keep the customer network closed while the device makes an authenticated outbound connection.
- Use the same model from ESP32 prototypes to larger site gateways.
Online in three steps
Works behind NAT, CGNAT, and strict firewalls — no inbound ports, no runtime to install, one static binary.
Register the device
Add a device in the console and choose how its services are exposed.
Run the agent
Download a preconfigured agent or mint an enrollment token, run one installer, and the device connects itself.
Reach it anywhere
The device dials out to the relay; you reach it by hostname. It opens no inbound ports.
See the fleet you are actually running
Every device, its address and whether it is online — plus the certificate and the one route you chose to expose. This is the console, not a mock-up.
Agents for the platforms already in the field
Use the same access model across gateways, lab machines, routers, Windows boxes, and ESP32 projects. Full operating systems get an agent; microcontrollers get a protocol-compatible library.
Linux
x86-64, ARM64 and 32-bit ARM · installs as a systemd service
Raspberry Pi
Every model, including Pi Zero and Pi 1 (ARMv6) · same Linux agent
macOS
Apple Silicon and Intel · installs as a launchd service
Windows
x64 and ARM64 · PowerShell installer, runs at start-up as a system task
OpenWrt & iStoreOS
Routers and gateways, x86-64 and ARM64 · installs as a procd service
ESP32
Arduino and PlatformIO library · same wire protocol as the fleet agent
Something else on the bench? We're happy to hear what you're running.
See what changes when the device dials out.
The walkthrough shows the complete path from private device to reachable URL: no router change, no VPN concentrator, and one managed route for exactly the service you expose.
- Why NAT, CGNAT, and customer firewalls make inbound access brittle.
- How an outbound agent avoids turning the site network into a public target.
- What the relay needs to route, and what passthrough encryption keeps private.
Watch 7 minPrefer to read it? The walkthrough in writing
The walkthrough starts on a device that has no public address: a gateway on a customer network, behind NAT or carrier-grade NAT. Nothing on the internet can open a connection to it, and nobody wants to publish a forwarded port to change that.
Registering the device in the console creates its identity. Every device holds its own CA-issued certificate. The private key is generated on the device and never leaves it. The agent then makes a single outbound connection to Tollan and keeps it open, the same way a browser or an update check reaches out, so the site firewall stays closed.
With the tunnel up, you publish one service rather than the network. Many devices share one address, demultiplexed by hostname — no port-per-device sprawl. A visitor uses that hostname; the relay matches it and splices the connection down the tunnel the device already opened.
The last part covers what the relay can and cannot see. Passthrough traffic is never decrypted at the relay. We route by TLS SNI without reading a single byte of your payload. Where you do want Tollan to hold the door, a route can terminate HTTPS at the edge instead, which is what makes password and address rules possible. Both modes are per route, and you choose which one each service uses.
Boring where it counts. Sharp where it matters.
Per-device PKI
Every device holds its own CA-issued certificate. The private key is generated on the device and never leaves it.
Zero-knowledge passthrough
Passthrough traffic is never decrypted at the relay. We route by TLS SNI without reading a single byte of your payload.
Hostname routing
Many devices share one address, demultiplexed by hostname — no port-per-device sprawl.
Fast revocation
Revoke a device and its live tunnels drop in seconds — the relay re-checks certificate status continuously.
Isolated organizations
Every resource belongs to an organization, and the boundary is enforced and adversarially tested in CI.
Gateway fan-out
One agent can expose anything on the device network — cameras, PLCs, gateways — each service behind its own route.
Edge access rules
Attach IP allowlists, basic auth, or mutual-TLS to a route as edge access rules.
Account security
Console accounts get role-based access, optional TOTP two-factor, and an append-only audit trail.
Simple infrastructure
The relay avoids extra queueing layers and keeps the operating model straightforward.
Docs that read like an engineer wrote them
Quickstart, a full console guide, the wire protocol, and an ESP32/Arduino device library — all at tollan-docs.pages.dev.
Ship your first tunnel
Register a device, install the agent, and expose a service end to end — in a few minutes.
ESP32 & Arduino library
A device-side agent for microcontrollers, kept wire-compatible with the rest of the fleet.
The tollan.v1 wire protocol
One authenticated connection, a handful of frames. Every agent implements it for you.
The relay never reads your bytes
Passthrough traffic is never decrypted at the relay. We route by TLS SNI without reading a single byte of your payload.
Read the security modelSimple, device-based pricing
Transparent pricing for teams running remote access across real field fleets.
Answers before you connect the first device
Does Tollan work behind NAT or CGNAT?
Yes. The device or gateway opens an outbound connection to Tollan, so it does not need a public IP address or an inbound firewall rule.
Do I need port forwarding?
No. Tollan is designed for closed networks: the agent dials out, and visitors use the route you configure.
Can Tollan read my device traffic?
Passthrough traffic is never decrypted at the relay. We route by TLS SNI without reading a single byte of your payload.
What devices can I connect?
Tollan supports Linux, Raspberry Pi, macOS, Windows, OpenWrt and iStoreOS gateways, plus an ESP32 and Arduino library.
Is Tollan a VPN replacement?
For reaching specific services it usually is: you publish one service per route instead of putting a whole subnet in scope, and there is no client to install on every laptop. A VPN is still the better tool when you genuinely need the whole network.
How is this different from a developer tunnel like ngrok?
Developer tunnels are built around a session on your own machine. Tollan is built around devices you ship: each one holds its own certificate, keeps a named route, and can be revoked on its own.
Bring your first device online
Free tier, no card required.