Skip to Content
Faable DeployCustom DomainsCustom Domain

Custom Domain

To serve your Faable app on your own domain, add the domain in the dashboard and point a DNS record at Faable. Go to Faable Dashboard > Projects > Domains , create a Domain entry, and link it to your deployed Faable App. Faable then issues an SSL certificate automatically, so your site is served over HTTPS.

Subdomains (CNAME)

For a subdomain such as www.example.com, create a CNAME record pointing to the target shown in the dashboard:

www IN CNAME <domain_id>.faable.link.

🚀 Your site is ready at: https://www.example.com

Apex domains (ALIAS)

If your domain is an apex (root) domain such as example.com, create an ALIAS record instead of a CNAME, because the DNS standard does not allow CNAME at the zone apex:

. IN ALIAS <domain_id>.faable.link.

Check with your DNS provider that it supports ALIAS (sometimes called ANAME or “CNAME flattening”) at the apex — it is not universally available. Providers that support it include Cloudflare, DNSimple and Namecheap. GoDaddy does not, and neither does Route 53: its alias records only point at AWS resources, not at faable.link. If yours does not, use an A record or serve on www and redirect the root — all three options, and how to choose, are in Apex domains.

Root and www together

example.com and www.example.com are two hostnames. To serve one and send visitors of the other to it, add them as a pair: when you add a root domain or its www, keep Also add … checked in the dashboard (or run faable deploy domains add example.com --www).

The name you type is the one that serves your app. The other is added too and answers every request with a permanent redirect to the same path on the first, so search engines see one site instead of the same page twice. Deleting the domain you typed deletes its pair as well.

Both names need their own DNS record: the root with ALIAS or A (see Apex domains) and www with its CNAME. Each one gets its own certificate.

If you are unsure which one should serve, choose www: its CNAME follows Faable wherever your app runs, while the root needs an ALIAS or a fixed address.

Redirecting one domain to another

Any domain of the project can send its visitors to another domain of the same project: an old name to the new one, a second brand to the main site, or a www you added on its own. In the dashboard, open the domain and pick the target under Redirect; from the terminal:

faable deploy domains redirect www.example.com example.com

Every request gets a permanent redirect to the same path and query on the target: 301 for GET, 308 for every other method, so a form post is not turned into a GET. The target must serve your app itself (a domain that redirects cannot be a target, so there are no chains). DNS and the certificate stay as they are. To serve the domain again, choose Don’t redirect, or run faable deploy domains redirect www.example.com --off.

A domain that redirects belongs to its target: deleting the target deletes it too.

Moving a live domain without downtime

If the domain already serves your site somewhere else, switching its record to Faable first would leave a short window — usually a minute or two — in which visitors reach Faable before its certificate exists and see an HTTPS error. Avoid it by letting Faable issue the certificate before any traffic moves:

  1. Add the domain in the dashboard, but don’t change its CNAME/ALIAS yet.

  2. Create this extra record (the exact target is on the domain’s page, under Moving a domain that is already live somewhere else?):

    _acme-challenge.www IN CNAME <domain_id>.acme.faable.com.
  3. Wait until the domain’s page says the record is in place (or faable deploy domains check www.example.com shows Pre-validation … ✅). Faable issues the certificate within a couple of minutes, while your current host keeps serving.

  4. Now switch the CNAME/ALIAS to <domain_id>.faable.link. — the certificate is already there, so HTTPS works from the first request.

Keep the _acme-challenge record afterwards: Faable renews the certificate through it. If you remove it, renewal falls back to the usual check over HTTP once the domain points at Faable. On Cloudflare, create it as DNS only (grey cloud) — a proxied record hides it.

Verification and propagation

  • After creating the record, Faable verifies the domain and provisions the certificate. This usually completes within minutes once DNS is correct.
  • DNS propagation can take anywhere from a few minutes up to the record’s TTL (time to live). Lowering the TTL before you migrate makes later changes propagate faster.
  • You can check the live record with dig www.example.com CNAME +short or dig example.com ALIAS +short.

Troubleshooting

  • Domain stuck “unverified”: the DNS record is missing or points to the wrong target. Re-check the exact <domain_id>.faable.link. value in the dashboard (note the trailing dot) and that you edited the right zone.
  • Certificate not issued yet: verification must succeed first; a misconfigured record blocks SSL. See SSL certificates.
  • Apex CNAME rejected by provider: this is a DNS rule, not a bug. See Apex domains; for GoDaddy specifically, GoDaddy.
  • Old site still showing: you’re seeing cached DNS. Wait for the previous TTL to expire, then re-check with dig.
  • Conflicting records: remove any existing A/AAAA/CNAME on the same name that point elsewhere, since they override or conflict with the Faable record.
  • Domain shows “Check error” and is managed by Cloudflare: the proxy (orange cloud) hides your record from Faable. See Cloudflare.
  • Editing records at your registrar changes nothing: the domain is using someone else’s nameservers. Check with dig NS example.com +short and edit the records there — see Cloudflare or Namecheap.

Last updated on