Reachability

Reachability means: can other computers find your server? A Recued server works fully on your own network. Only some features need traffic to come in from the internet. When you do give your server a public name, that name points straight at your server. The cloud publishes the name. It can also issue the certificate. But it is not in the path of your traffic. It cannot read 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. Some vendors can only push webhooks. If your server has no public URL, those vendors fall back to a regular check.

#Three questions, not one list

Getting a public name is really three choices. They do not depend on each other:

1. Which name? A domain you already own, or a <handle>.recued.net name that Recued gives you.
2. Who keeps the certificate current? You, or Recued.
3. Can traffic get in? Only you can answer that one. It is the router step below, and nothing buys your way out of it.

Pro changes only the second answer. Your own domain works either way. That is the part worth being clear about, because the upkeep is very different.

Everything except the Pro rows is free forever. Pro unlocks no feature. On every row, your traffic goes straight to your server.

The middle row used to make paying customers worse off. Bring your own domain, and you were back to a certificate chore every 90 days. Meanwhile the recued.net name renewed itself. Now Pro covers your own domain on the same terms.

#Letting traffic in

A name and a certificate are not enough on their own. The name points at your home. Your router still has to pass that traffic to your server.

So let port 443 through your router, to the machine running Recued. You do this once, in your router's own settings. Recued cannot do it for you, and neither can the cloud. Your traffic never goes through the cloud, which is the point of the design and the reason this step is yours.

Pro does not change this. Pro gives you the name and the certificate. The router step stays yours either way.

Tailscale is the exception. It links your devices privately, so no router change is needed at all. See Use Recued on another device.

You cannot check this from inside your own network. A request from your own house may never reach the router's outside. Open Settings → Server → Connect a device. The router step there has a button called Check this now. It asks from outside and tells you what it found.

#The address in your links

Your server puts its own address into the links it sends. An answer link in an email. A link in a notice. The page a sign-in comes back to. Recued picks the address each time it makes a link:

• A name Recued has checked is yours, with a certificate.
• Your own domain first, then your Pro address.
• Never a LAN or local address. Those do not open away from home.
• The part the link opens must be Public under Settings → Server → Exposure.

A link into the app itself opens the root of the name. Your Pro address sends that on to app.recued.com. Your own domain does that only when Root URL ( / ) is set to Serve the webclient.

Recued also asks from outside whether each name it manages answers. That means your Pro address, and your own domain when Pro keeps its certificate. Names you manage yourself are never sent for this check. A name where nothing answers is left out of links until it answers again. The Pro card reads the same check.

To choose the address yourself, set RECUED_PUBLIC_BASE_URL on the server. It then comes first, though a LAN or local address is still refused. Reception share links are the one exception: they take an intranet address you set, for visitors on your own network.

#Addresses you hand out

Some addresses are kept by someone else. A vendor stores your webhook address. A Reception link you share gets saved. A customer keeps the address they are given. These work differently from links in notices:

• They never follow the check. One failed check does not move them.
• Each one is kept from the first time it is handed out. Adding a domain later does not move it.
• You can move one yourself. Open Settings → Server → Hostnames and find Addresses you hand out. Pick a name for webhooks, Reception links, or customer access. Automatic takes your own domain first, then your Pro address, and keeps it.
• Moving the webhooks address stops each webhook until you update its address at the other service. Recued tells you how many first.
• Say a kept name is removed or switched off. That use stops and says so. Recued never moves it to another name for you.

RECUED_PUBLIC_BASE_URL still comes first for all of them when it is set.

#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 works. It points straight at your server, with no proxy in between. The certificate is what makes the name trusted. It is issued through an ACME DNS challenge. The private key is made and kept on your server. The cloud handles two things: the name record and the challenge. It sees your hostname and your public IP. It sees none of your traffic. You can run all of this yourself, with your own domain, DNS, and certificate tools. The mechanics are the same.

#Your own domain, without Pro

Point the name at your server. Handle TLS yourself. There are two shapes.

End TLS in front of Recued. Use a reverse proxy, Caddy, or anything else that holds the certificate and forwards to your server. Recued never sees a certificate. Your proxy renews it on its own schedule. Add the hostname in Settings → Server → Hostnames. For where its certificate comes from, pick Looked after somewhere else. Then the server knows the name is yours, and expects TLS to arrive already handled.

Upload the certificate to Recued. Get one however you like: certbot, your registrar, your employer's PKI. Upload it in Settings → Server → Certificates. Recued serves it for that hostname.

⚠ Recued does not renew a certificate you upload. It cannot get a new one for you. It uses the one you gave it until that one runs out. It warns you as the end gets close. Plan to upload a new one about every 90 days. Or pick one of the other two paths.

#Your own domain, with Pro

Recued issues and renews the certificate for a domain you own. You create two DNS records, once. The second one does the real work.

You can use your root domain, like your-domain.com. Or you can use a subdomain, like recued.your-domain.com. Both work. Most people want the root domain. So this page shows that path first, with Cloudflare as the example. The subdomain path comes after it.

The first record makes your domain reach your server. The second lets Recued prove it may issue certificates for that name.

You need both. Having only the first fails in a confusing way. Your domain finds your server. Your server answers. But no certificate can ever be issued. Certificates are checked against a different name: your hostname with _acme-challenge. in front. For the root domain, that is _acme-challenge.your-domain.com. That name is in a zone Recued cannot write to. The second record points it at a zone Recued can write to. The certificate authority follows it.

Settings → Server → Hostnames fills in both records with your own handle. It checks them live. It tells you which one is wrong.

#Your root domain: your-domain.com

These are the two records for a root domain:

DNS forbids a plain CNAME at the root of a zone. So the routing record uses your provider's ALIAS, ANAME, or CNAME-flattening option instead. That is a record type that acts like a CNAME but answers with addresses. That is allowed at a root. Cloudflare, Route 53, DNSimple, and deSEC all have one, under one of those three names.

⚠ Only the routing record is special. The second record is still a plain CNAME. That is because _acme-challenge.your-domain.com is a subdomain of your root. It is not the root itself. The CNAME rule does not reach it. No ALIAS is needed. This is the step most people over-think.

#Cloudflare, step 1: add the two records

Your domain's nameservers must be at Cloudflare. If your domain lives somewhere else, you can move just its DNS to Cloudflare. A free plan is enough. Or use your own provider's ALIAS or ANAME record instead.

1. Sign in to Cloudflare and pick your domain. Open DNS → Records.
2. Does @ (your root) already have an A or AAAA record? That could be an old site or a parked page. Delete it first. A name cannot hold a CNAME and an address record at the same time.
3. Click Add record for the routing record. Type: CNAME. Name: @. Target: <handle>.recued.net. Proxy status: DNS only (click the orange cloud so it turns grey). TTL: Auto. Save.
4. Click Add record again for the certificate record. Type: CNAME. Name: _acme-challenge. Target: _acme-challenge.<handle>.recued.net. Proxy status: DNS only. TTL: Auto. Save.
5. Look at both rows. Both clouds must be grey and say "DNS only". Cloudflare turns the orange cloud on by default for a new record. An orange cloud breaks both records. See "proxying hides the record" below.

Cloudflare allows a CNAME at the root because it flattens it for you. It answers with addresses, which DNS allows at a root. And it looks up <handle>.recued.net again each time. So it follows your server when the address changes.

#Cloudflare, step 2: check it in Recued

1. Open Settings → Server → Hostnames. Add your-domain.com. For the certificate, pick My own domain, managed by Recued.
2. Use Verify on its row to prove you own the domain. Pick DNS TXT or HTTP token. The panel shows what to add. A TXT record in Cloudflare must be DNS only too.
3. The panel shows both records with your real handle filled in. It shows the short names (@ and _acme-challenge) and the full names.
4. Run the DNS check. It has three parts. Your domain points at this server stays a warning (⚠) on a root domain. That is normal. The next sections say why. Certificate delegation must pass. Certificate authority permissions (CAA) passes if you have no CAA records, or if they allow all three authorities. See Limits below.
5. Did a part fail? The panel names the record to fix. Fix it in Cloudflare, then run the check again. Cloudflare changes usually show up within a few minutes.

Want www.your-domain.com too? See "Using both the root and www" below.

#A subdomain: recued.your-domain.com

This path has no catches. Any DNS provider can do it. Both records are plain CNAMEs.

In Cloudflare the steps are the same as above, with two changes. The routing record's Name is recued, not @. The certificate record's Name is _acme-challenge.recued. Both stay DNS only.

The first label is yours to pick: recued, home, hq, anything. Nothing in Recued reads it.

#What to expect on a root domain

Two things are normal on a root domain. The routing check stays a warning. And you must never type an address in by hand. The next sections explain both.

#The routing check stays a warning

Once a flattened record is in place, the Hostnames panel reports the routing check as a warning, not a pass:

Resolves to the right address today, but as a flattened A record rather than a CNAME — if your provider does not keep it in sync with your Recued address, it will break when your IP changes.

That is the normal steady state for a root domain. It is a warning, not a pass, for a reason. DNS cannot tell Recued the difference between two things. One is a provider that re-flattens on every change. The other is an address someone typed in once. It does not block anything. Issuing a certificate depends on the _acme-challenge record and your CAA records. It never depends on the routing record.

#Do not pin an address by hand

There is one way to get a root domain wrong. You look up your server's current address. You type it in as an A record. That works until the address changes. Then the name points at somebody else's machine. That is the exact failure dynamic DNS exists to prevent. Recued reports it as "Points at an address that is no longer yours". But only once it has already happened.

Use ALIAS, ANAME, or flattening instead. Then your provider looks up <handle>.recued.net again by itself.

#If your provider has no ALIAS option

Some registrars' bundled DNS has none. Cloudflare has one: it flattens a CNAME at the root by itself. Two ways out, best first:

• Move DNS for the domain to a provider that has one. Your registration stays where it is. Only the nameservers change.
• Use a subdomain instead. recued.your-domain.com needs nothing special. It works on every provider.

A root-domain redirect service is not a way out. It answers HTTP. Recued needs the name itself to point at your server.

#Using both the root and www

They are two hostnames. Enrol each one in Settings → Server → Hostnames. Give each its own pair of records: a flattened routing record at the root, and a plain CNAME at www. Add an _acme-challenge CNAME for each. Each gets its own certificate. Each counts on its own against the five-domain limit below.

#Getting the records right: names are relative

Most DNS providers want the name relative to your zone. So enter _acme-challenge.recued, not the full _acme-challenge.recued.your-domain.com. If you paste the full name, you usually get _acme-challenge.recued.your-domain.com.your-domain.com. Nobody complains. The record looks made, and it points nowhere. On a root domain, the routing record's relative name is @. Its challenge record's relative name is _acme-challenge. The Hostnames panel shows both the relative and the full form of every record, for this very reason.

#Getting the records right: proxying hides the record

Some providers can proxy a record. In Cloudflare that is the orange cloud. Both records must be set to "DNS only". A proxied CNAME is answered with the provider's own addresses instead. So the certificate authority cannot follow the _acme-challenge one. And a proxied routing record puts that provider in the path of your traffic. TLS ends there. That is the very thing the rest of this page exists to avoid. Cloudflare proxies by default. So this is the common case, not a rare one. On a root domain it is easy to miss, because Cloudflare's flattening and its proxy are separate settings on the same record.

A trailing dot on a value is fine either way. Providers differ, and both spellings are accepted.

#Leave the _acme-challenge record in place

It is not a one-time step. Every renewal uses it. Delete it, and nothing breaks today. Everything breaks about 60 days from now, when the certificate runs out.

Recued checks the record again on a schedule. It does not wait for a renewal to fail. It flags the hostname as soon as the record stops working. Quietly, when there is plenty of certificate time left. Urgently, as the end gets close.

#Limits

Up to five custom domains per server. This part is Pro. It uses Recued's certificate-issuing capacity on your behalf. Each domain gets its own certificate. They do not share one. So a mistake in your zone can never affect your <handle>.recued.net name. That is the address you would need in order to come back and fix things.

CAA records can limit which authorities may issue for your domain. If you have them, add all three: sectigo.com, pki.goog, and letsencrypt.org. Recued rotates between them. Allow only some of them, and you get a certificate that renews most of the time. That is the worst kind of failure to find. CAA is inherited down the tree. A record set at your root applies to a subdomain too. So check, even when the name you enroll has none of its own.

#Use HTTPS

Browsers only allow the cryptography that pairing and the webclient need in a secure context. That means HTTPS, or plain HTTP on a loopback address. This is why the start-up log prints http://127.0.0.1:<port>/webclient/. On the server machine itself, that address needs no certificate. It works offline.

#Reaching the webclient from another device

Your server answers on every network interface. So http://192.168.1.x:<port>/webclient/ loads from a phone or laptop on the same network. The page appears. Then the app 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 holds back the Web Crypto APIs pairing needs. Recued says so, instead of failing in a confusing way.

Two ways forward:

Put HTTPS in front. Anything that handles TLS works. It can be a reverse proxy with a certificate. It can be a private-network service that provides one. Or it can be a name and certificate as described above. This is the lasting answer. It is the only one that scales past a single device.

Opt one browser in. Chromium browsers can treat one specific origin as secure. Open chrome://flags/#unsafely-treat-insecure-origin-as-secure. Add the exact origin, such as http://192.168.1.121:7717, with matching host and port. Restart the browser. This is per device and per browser. It relaxes a protection for that origin in general. That is reasonable on a home network you control. It is not something to hand to other people.

#Choose which address the server binds

By default the server detects your network interface. It binds every interface. So it can be reached on loopback and on your LAN address. Some machines have several candidate interfaces, such as a container bridge or a VM network next to the real one. Then the server 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. 0.0.0.0 serves everything. If the address is not one this machine has, the server logs the reason at start-up. Then it falls back to detection. It does not refuse to start.

#Next

Pick a release channel in Updates.