Introduction
What tunnelctl is, the problem it solves, and how its pieces fit together.
tunnelctl is a managed reverse-tunnel service. It lets you take a service running
on your machine — a dev server, an API, a database, a webhook receiver — and expose it on
a stable public endpoint like myapp.intunnel.eu, without touching firewalls, routers, or
TLS certificates.
# log in once with your SSO account
tunnelctl login
# expose localhost:8080 on https://myapp.intunnel.eu
tunnelctl up http myapp 8080That's it — the public endpoint is live for as long as the tunnel runs.
The problem it solves
Sharing a local service usually means one of: deploying it somewhere, fighting with firewall and NAT rules, or hand-configuring a reverse proxy and a tunneling client. tunnelctl removes all of that. You authenticate with your existing identity provider, and a single command forwards traffic to your local port over an encrypted control channel.
HTTP, TCP and UDP tunnels
tunnelctl handles HTTP/HTTPS (addressed by a slug → https://<slug>.intunnel.eu) as
well as raw TCP and UDP (addressed by a remote port → tcp.intunnel.eu:<port>,
udp.intunnel.eu:<port>). You pick the protocol per tunnel — see
Tunnels & protocols.
How the pieces fit together
tunnelctl is made of a few cooperating components:
CLI
The tunnelctl binary you run locally — logs you in, reserves tunnels, and runs an embedded FRP client with a per-tunnel background daemon.
Server
The control plane. Manages tunnel reservations, issues connection tokens, and orchestrates the FRP handshake over a reconciliation-friendly HTTP API.
Concepts
The model behind it all — HTTP/TCP/UDP tunnels, SSO authentication & tokens, and the embedded FRP transport.
At runtime the flow is:
You authenticate the CLI against your identity provider (OIDC / Keycloak). The CLI stores a short-lived access token and refreshes it automatically.
The CLI asks the server to reserve the endpoint (an HTTP slug or a TCP/UDP remote port) and issue a per-tunnel connection token.
The CLI's embedded FRP client opens an encrypted control channel to the tunnel edge and registers the public endpoint using that token.
Public traffic to <slug>.intunnel.eu (HTTP) or tcp.intunnel.eu:<port> (TCP/UDP) is
forwarded down the tunnel to your local host:port.
Where to next
- New here? Start with the Quickstart.
- Want the full command surface? See the CLI reference.
- Curious how it works? Read Concepts.