From microcontroller to secure URL
Tollan brings identity-based remote access directly to constrained IoT devices, from ESP32 prototypes to production fleets.
No card required · one free device · no port forwarding
- outbound-only agent
- mutual TLS
- zero-knowledge relay
- per-route access rules
- No firewall changes
- The agent dials out, so there are no inbound ports to publish.
- Per-device identity
- Every agent connects with its own certificate and route scope.
- 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.
Weighing it up: Tollan vs a VPN Tollan vs ngrok Without port forwarding Behind 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.
From locked-down network to working URL
Tollan keeps the network closed. The device makes the only connection, and operators reach only the service you choose to expose.
Create its identity
Add the device in the console and define which local service should be reachable.
Let it dial out
Download a preconfigured agent or mint an enrollment token, run one installer, and the device connects itself.
Use the URL
Reach the service by hostname while the device network stays closed to inbound traffic.
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 min
Prefer 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.
The controls security teams ask for, without VPN sprawl.
Tollan turns remote device access into managed routes with identity, revocation, isolation, and auditability built in.
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.
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.
Docs that read like an engineer wrote them
Quickstart, a full console guide, the wire protocol, and an ESP32/Arduino device library — all at docs.tollan.ie.
Ship your first tunnel
Register a device, install the agent, and expose a service end to end — in a few minutes.
embeddedESP32 & Arduino library
A device-side agent for microcontrollers, kept wire-compatible with the rest of the fleet.
protocolThe tollan.v1 wire protocol
One authenticated connection, a handful of frames. Every agent implements it for you.
Simple, 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.