Reachability

A Recued server is fully functional on your own network. Public reachability is needed only by features that receive inbound traffic. When you do publish a name, it points directly at your server — the cloud publishes the name and can issue the certificate, but it is not in the traffic path and cannot decrypt what flows to you.

#What needs inbound reachability

Outbound-only integrations need none of this: IMAP mail sync, API polling, and Salesforce's streaming subscription are all connections your server opens outward. A vendor that can only push webhooks falls back to periodic reconciliation when your server has no public URL.

#Two ways to get a name

Bring your own. Point any domain or dynamic-DNS name at your server and issue certificates however you prefer. Nothing in Recued requires the paid plan; this path is free forever.

Recued Pro. A $5.99 USD/mo convenience for people who don't want to run DNS and certificates themselves: a <handle>.recued.net name plus an automatically renewed certificate. Pro gates no capability — it removes setup friction, nothing else, and your traffic still goes straight to your server.

#How the name and certificate work

Most home and small-VPS addresses change over time. Dynamic DNS solves that: your server keeps its own name record pointed at its current address, so the name always resolves — directly to your server, with no proxy in between. The certificate that makes the name trustworthy is issued through an ACME DNS challenge; the private key is generated and kept on your server. What the cloud handles is the name record and the challenge — it sees your hostname and public IP, and none of your traffic. The bring-your-own path is the same mechanics with your own domain, DNS, and certificate tooling.

#Use HTTPS

Browsers restrict the cryptography that pairing and the webclient depend on to secure contexts: HTTPS, or plain HTTP on a loopback address. That is why the boot log prints http://127.0.0.1:<port>/webclient/ — on the server machine itself, that address needs no certificate and works offline.

#Reaching the webclient from another device

Your server answers on every interface, so http://192.168.1.x:<port>/webclient/ loads from a phone or laptop on the same network. The page appears; the app then stops with a message instead of pairing. Nothing is broken — a plain-HTTP address on a LAN IP is not a secure context, so the browser withholds the Web Crypto APIs pairing needs, and Recued says so rather than failing obscurely.

Two ways forward:

Put HTTPS in front. Any TLS termination works: a reverse proxy with a certificate, a private-network service that provides one, or a name and certificate as described above. This is the durable answer, and it is the only one that scales past a single device.

Opt one browser in. Chromium browsers can treat a specific origin as secure: open chrome://flags/#unsafely-treat-insecure-origin-as-secure, add the exact origin (http://192.168.1.121:7718, matching host and port), and restart the browser. This is per-device and per-browser, and it relaxes a protection that applies to that origin generally — reasonable on a home network you control, not something to hand to other people.

#Choose which address the server binds

By default the server detects your network interface, binds every interface, and stays reachable on both loopback and your LAN address. On a machine with several candidate interfaces — a container bridge or a VM network alongside the real one — it follows your default route to decide which address to publish.

To pin it, set network.lan_bind_address in config.toml and restart:

[runtime]
"network.lan_bind_address" = "192.168.1.121"

The value is bound exactly as written, so it also narrows what the server answers on: 127.0.0.1 serves only the server machine, and 0.0.0.0 serves everything. If the address is not one this machine has, the server logs the reason at boot and falls back to detection rather than refusing to start.

#Next

Pick a release channel in Updates.