Cloudless — SSH-first Reverse Proxy / Tunnels

VT100-ish landing, because the UX is the protocol.

Cloudless is controlled via standard SSH clients: the SSH username is the command. User actions may use SSH, passkeys (WebAuthn), and recovery keys depending on the flow.

Control plane: register@ verify@ release@ ls@ info@ put@ get@ status@ watch@ activate@ login@ protect@ vendor@ kite@
Tunnel plane: up@ and tunnel@
Bind tokens: tcp udp https https1... or a hostname/label in the -R specification

# Quick Start
user@host$ ssh register@cloudless.site myapp.cloudless.site email=me@example.com
user@host$ ssh verify@cloudless.site <TOKEN>
user@host$ ssh -R myapp.cloudless.site:443:localhost:8443 tunnel@cloudless.site

The SSH username selects the tunnel model: up@ for Cloudless HTTPS gadgets, tunnel@ for raw tcp/udp, registered Cloudless HTTPS hosts, and full custom-domain passthrough.
# Zero-Effort Web (up@)
user@host$ ssh -R :443:127.0.0.1:80 up@cloudless.site
user@host$ ssh -R myapp.cloudless.site:443:localhost:8443 tunnel@cloudless.site

Examples:
- empty bind token -> generated gadget host
- registered label / hostname -> stable Cloudless host

For Cloudless-managed web publishing, up@ is the recommended mode.
# Web Access Model
Frontend:
- Cloudless-managed web publishing uses HTTPS on the public side

Backend:
- up@ publishes a Cloudless HTTPS gadget endpoint
- tunnel@ publishes either raw tcp/udp, a Cloudless HTTPS endpoint, or a full custom-domain passthrough endpoint
- if web hints are missing, Cloudless probes the backend to distinguish HTTP vs HTTPS

Custom domains:
- full custom domains require explicit verification
- DNS TXT verification uses a value derived from the SSH fingerprint

Notes:
- raw tcp/udp are never probed
- full custom domains stay in passthrough mode
# Advanced (tunnel@)
user@server$ ssh -R tcp:10000:localhost:22 tunnel@cloudless.site
user@server$ ssh -R udp:10000:localhost:4000 tunnel@cloudless.site
user@server$ ssh -R myapp.cloudless.site:443:localhost:8443 tunnel@cloudless.site

Use tunnel@ when you want raw transport, a registered Cloudless HTTPS host, or a full custom-domain passthrough endpoint.
# RAW TCP / UDP
user@server$ ssh -R tcp:10000:127.0.0.1:22 tunnel@cloudless.site
user@client$ ssh activate@cloudless.site
user@client$ ssh -p 10000 user@cloudless.site

user@server$ ssh -R udp:10000:127.0.0.1:4000 tunnel@cloudless.site
# Kite (High-Performance UDP via TCP)
user@host$ ssh -T kite@cloudless.site > kite.zip

# The archive includes builds for multiple CPU architectures (x86_64, ARM, etc)
# Source code is available on GitHub

./kite 51820:192.168.1.50:51820

user@server$ ssh -R udp:10000:127.0.0.1:51820 tunnel@cloudless.site
user@client$ ssh activate@cloudless.site
# Custom Domains
- Require explicit verification
- DNS TXT value is derived from the SSH fingerprint
- Verify the domain before publishing traffic through it
# Dashboard
user@host$ ssh login@cloudless.site

Supports:
- Passkeys
- Recovery keys
- Service management
# Runtime Behavior
- up@ selects Cloudless HTTPS gadget publishing
- tunnel@ selects raw tcp/udp, Cloudless HTTPS hosts, or full custom-domain passthrough
- activate@ is required for raw consumer access on controlled ports
- public bind tokens are tcp, udp, https, https1..., or a hostname/label
# Public Service
- The public Cloudless service is currently free for testing and evaluation
- No uptime, availability, or persistence guarantees are provided
- Limits, restrictions, quotas, or access conditions may change at any time
- You are responsible for the services and traffic you expose through Cloudless
# Security Notes
- login@ issues a dashboard login flow
- Recovery keys are one-time generated and stored hashed
- IPC sockets live under /run/cloudless
Privacy | Terms | Acceptable Use | Abuse