Publish a web app
An HTTP app maps one or more hostnames to a service in your home. You point each hostname at the app's DNS target with a CNAME, and the nodes get a certificate and start serving.
You have a connected home and a hostname under a domain whose DNS you control, such as media.example.net.
1. Add the app#
In the panel, open Apps and choose New app:
- Hostnames: one or more names, such as
media.example.net. - Home and origin: where the service runs, as a URL seen from the home, such as
http://192.168.1.20:8096. Usehttps://if the service only serves TLS. - Optional: WebSockets, a WAF mode, a bot challenge, rate limits, response headers and access policies.
The app is served by every node its home is attached to.
2. Point DNS at the DNS target#
Each app gets a DNS target, shown on its page, for example k7m2q9xa.edge.example.net. Create a CNAME for each hostname at your DNS provider:
media.example.net. 300 IN CNAME k7m2q9xa.edge.example.net.
The panel answers the DNS target with the public addresses of the nodes that can serve the app right now, with a 30-second TTL. When a node or its tunnel goes down, it drops out of the answer, with no change on your side. See failover.
A bare domain such as example.net can't hold a CNAME at most providers. Use A and AAAA records for every node serving the app instead. That works, but without failover: a node that goes down stays in the answer.
If your DNS is at Cloudflare, set the record to DNS only (grey cloud). A proxied record sends traffic to Cloudflare instead of your nodes, and certificates can't be issued.
3. Watch the deployment#
The app page runs five checks and re-runs them when something changes:
| Step | Passes when |
|---|---|
| Config | Every node has applied the new configuration. |
| Origin | A node can reach the origin through the tunnel and gets an HTTP answer. |
| DNS | Public resolvers (1.1.1.1, 8.8.8.8, 9.9.9.9) return the DNS target or your nodes for every hostname. |
| Certificate | A certificate is issued for every hostname. |
| Live | A node fetches https://<hostname> through its own public address and gets a valid answer. |
Each failed step says what happened and what to do. The common cases are in troubleshooting.
Certificates#
Nodes get certificates from Let's Encrypt with ACME. Nodes that serve the same hostname share one encrypted certificate store held by the panel, so a certificate is issued once and every node can answer the challenge and serve it. Each node keeps a local copy and keeps serving from it if the panel is unreachable.
For issuance to work, the hostname must point at your nodes and TCP ports 80 and 443 must be open. A CAA record on your domain must allow Let's Encrypt, if you have one.
Protection per app#
| Setting | Values |
|---|---|
| WAF | off, detect (log only) or block, with a paranoia level 1–4. Coraza with the OWASP Core Rule Set. |
| Bot challenge | off, suspicious, always or under_attack. |
| Rate limits | Requests per period, per client IP, for a path pattern such as /login. |
| Access | One or more access policies; the first match wins. |
Watch requests#
Live in the panel streams an app's requests as they reach any node: time, host, path, status, duration, client IP, country and the decision (allowed, WAF block, access denied, challenge, rate limited). Entries pass through the panel while you watch and are not stored.