Connect your own domain

By default your site is tollable at a subdomain we give you (yourname.naulon.app), covered by a certificate we already hold. Most publishers want their own domain instead, www.yoursite.com or yoursite.com. This page is how you get there. The certificate is issued and renewed at the edge for you; you never manage TLS.

What you'll do

Adding a custom domain is two DNS records and a click. You prove you own the domain, we route traffic through the edge, and a certificate is issued automatically.

1. In the dashboard, open Connect → Add a domain and enter your domain.
2. We show you the records to publish at your DNS provider. Add them.
3. Click Verify. Once your records resolve, the domain joins your tollable hosts and a certificate starts issuing.

The records

You'll add up to two records at whatever DNS provider is authoritative for your domain (where your nameservers point, often the registrar, or Cloudflare, Route 53 and so on).

Routing points your domain at us. This is also how we confirm you control it, so it's the only record most people need:

www.yoursite.com   CNAME   customers.naulon.app

A root/apex domain (yoursite.com with no www) can't use a plain CNAME. Use your provider's CNAME-flattening / ALIAS / ANAME record type with the same target, or contact us.

Publishing that record sends your domain's live traffic through us, so only add it when you're ready to go live. If you want to prove the domain is yours first, to get it claimed or because go-live is a separate change window, pick one of the other proof methods when you add the domain: a TXT record, a meta tag on your homepage, or a file at a known path. None of them touch your live traffic; you add the routing record later, as its own step.

You can change your mind after the fact. On the domain's card, ← Use a different method swaps the proof without starting over: the same domain, the same claim, a different record.

Auto-renewal (recommended, add once) lets the edge renew your certificate forever with no further action from you:

_acme-challenge.www.yoursite.com   CNAME   www.yoursite.com.<your-delegation-id>.cloudflare.com

The exact target (with your delegation id) is shown in the dashboard when you add the domain, so copy it from there. Skip this record and the certificate still issues; it just means renewals lean on the routing record staying in place.

After you verify

• Certificate status shows in the dashboard: issuing while the edge validates and mints the certificate (usually a few minutes), then active.
• Once active, https://www.yoursite.com serves through us with a valid certificate, and the toll applies to your articles exactly as it did on the subdomain.
• Your origin server needs no certificate for the custom domain and is never exposed directly: the edge terminates TLS and forwards to us.

If verification says "not yet"

DNS takes time to propagate. If Verify reports the records aren't visible, wait a few minutes and try again. Nothing is lost, and you can re-verify as often as you like.

One case is not propagation and waiting will never fix it: a proxied record. If your DNS provider proxies the hostname itself (Cloudflare's orange cloud, and the equivalent elsewhere), your CNAME is replaced at the edge by the proxy's own addresses, so nothing outside your account can read it, including us. A CNAME proof on a proxied subdomain can't pass however long you wait, and we say so rather than leave you re-checking. Two ways out: turn the proxy off for that record (grey cloud / DNS only), or prove ownership with a TXT record instead, which resolves normally through a proxy. Both are fine; the TXT route also leaves your live traffic alone.

If your origin has its own bot or rate protection

Once traffic routes through us, every request to your origin arrives from the naulon fleet rather than from each visitor directly. That is how we classify humans against agents and apply the toll before your origin ever sees the request. One side effect: your origin sees all of that traffic coming from a small, fixed set of fleet addresses, not thousands of visitor IPs.

If your origin sits behind its own bot-management or rate-limiting edge, whether a hosting firewall, Cloudflare in front of your origin or AWS WAF, that edge can read the fleet's concentrated traffic as a single-source flood and start challenging or rate-limiting it. Full page loads usually survive (a browser can solve a JavaScript challenge), but background requests (prefetches, fetch and XHR, feed pulls) can't, so they fail intermittently and the site feels slow or half-broken.

The cleanest fix is a shared secret the fleet sends on every request to your origin, which you match at your edge. There is no IP dependency, so it keeps working if the fleet scales past one address. In the dashboard, open your domain's settings, find Protect your origin, and click Generate secret (copy it, because it's shown only once). The fleet then sends it on every request to your origin as the header x-naulon-origin-auth. Add a rule at your edge that trusts any request carrying that header with your secret and skips your bot and rate challenges for it:

• Cloudflare (in front of your own origin). A WAF custom rule: when the header equals your secret, action Skip the remaining rules.
• Vercel Pro. A firewall rule matching the header, action Bypass. On the free plan header rules aren't available, so use the IP fallback below instead.
• AWS WAF or ALB. A string-match rule on the header equal to your secret, action Allow, ordered ahead of your rate and bot rules.
• An application-level check. Treat a request carrying the header and your secret as trusted.

Step-by-step per platform, with the exact rule to paste, is in Protect your origin.

Then click Verify and we fetch your origin from the fleet's own address three times: with no header, with a deliberately wrong secret, and with the correct one. We then tell you whether the bypass is working. The wrong-secret probe is what separates a rule that checks your secret's value from one that only checks the header is present; Protect your origin lists what each verdict means. Because the secret is a fixed header, TLS already keeps it private in transit, and it only grants "reach an origin we already sit in front of", so there's little to gain by replaying it. Rotate it any time by regenerating (that breaks the bypass until you update your edge rule, so update both together).

If your platform can only match by IP (some plans, notably Vercel free, challenge before any of your own rules run), exempt the fleet's egress by address instead. Ask us for the current fleet egress address, which the Protect your origin panel also shows, then:

• Vercel. vercel firewall system-bypass add <ip>; it exempts the IP from automatic mitigation and takes effect immediately.
• Cloudflare. An IP Access rule (or WAF skip) for that address.
• AWS WAF or ALB. Put the address in an allow IP set ahead of your rate and bot rules.

Either way, if your origin runs an application-level bot check, prefer leaving it off the routes we proxy. We have already classified human against agent before the request reaches you, so a second check there only fights ours.

Removing a domain

Removing a custom domain from your hosts stops tolling on it and releases the certificate. Your subdomain (yourname.naulon.app) keeps working regardless.