Start here

mytunnel publishes local HTTP services through a public hostname on an edge server you control. It is made of two binaries:

Binary	Runs on	Purpose
mytunnel	Client/source machine	Allocates leases, starts SSH reverse tunnels, lists or releases leases, and runs diagnostics.
mytunneld	Edge VPS	Stores leases, manages Caddy routes, cleans expired leases, reconciles route drift, and serves control commands.

Use mytunnel when you want:

• Public HTTPS URLs for local development or demos.
• DNS, Caddy, SSH users, and logs on infrastructure you operate.
• Owner-scoped tunnel leases instead of a shared global tunnel account.
• A small source-first system that can be audited and installed with shell scripts.

Do not treat it as:

• Application authentication.
• A private network overlay.
• A managed production ingress platform.
• A way to expose sensitive local services without reviewing their auth and data handling.

Required assumptions

Client machine:

• ssh
• curl
• Go 1.25+ for full local verification, or Docker for builds and verification

Edge server:

• Linux with systemd
• Inbound firewall allows the SSH port used by mytunnel, 80/tcp, and 443/tcp
• Wildcard DNS for the tunnel base domain, such as *.tunnel.example.com
• Caddy with a DNS provider module or another way to serve wildcard TLS
• A mytunneld service with access to /etc/mytunneld/mytunneld.env and /var/lib/mytunneld/leases.db

Caution

Anything reachable through a tunnel is public on the internet unless your application adds its own authentication. Run the local service as if it were directly exposed behind a public reverse proxy.

Read next

• Use Quickstart for the shortest clone-to-tunnel path.
• Use Installation when preparing a real edge server.
• Use Security model before adding other SSH users or admin users.
• Use CLI reference when you need exact flags, outputs, and errors.