Custom domains

Links can be served from docs.yourcompany.com instead of fermiumusercontent.app. Available on Team (one domain), Business (five) and Enterprise. Setup takes about ten minutes, most of it waiting for DNS.

1. Choose a hostname

Use a subdomain, not your apex domain: docs., share., pages.. The server rejects apex domains, IP addresses, and any name under fermium.app or fermiumusercontent.app. Published content renders inside a browser sandbox on this hostname, so keep it separate from anything that sets cookies for your own users.

2. Add the domain

In the app open Settings, then Domains, enter the hostname under Your own domain for links and click Add domain. The domain appears with status pending and two records to create at your DNS provider:

docs.yourcompany.com.            CNAME   cname.fermium.app.
_fermium.docs.yourcompany.com.   TXT     "fm-verify-<token>"

The token is unique to the domain and shown in the app. The CNAME sends traffic to Fermium. The TXT record proves you control the name.

If your DNS provider flattens CNAMEs (some do at any level), that is fine: the check also passes when your hostname's A records are a subset of the target's A records.

Watch the record name for the TXT: it is _fermium.docs inside the yourcompany.com zone. Many providers append the zone automatically, so entering the full name can produce _fermium.docs.yourcompany.com.yourcompany.com.

3. Verify

Click Verify. The server resolves both records with a real resolver. If either is missing, the status stays pending and the error text says what was seen, for example expected CNAME cname.fermium.app; saw nothing. DNS changes can take up to an hour to propagate; check from outside your network with dig or nslookup and click Verify again.

When both records resolve the domain moves to issuing: a certificate request and a route are created for your hostname, and Let's Encrypt issues the certificate. Click Verify again to poll; when the certificate is ready the status becomes active. This usually takes a couple of minutes.

The full status sequence is pending, dns_ok, issuing, active, with error if provisioning fails. The error text is shown on the domain card.

4. Links use it automatically

The first domain to go live becomes the workspace's link host on its own: the moment its status turns active, and no other link host is set, every URL your agents get back, every copy-link button, the address of a published folder and the url in every API response use your hostname. The domain card shows a default link host badge.

https://docs.yourcompany.com/d/xBVNwKdi7ukQhXrWhQuz4g/

Existing documents are not rewritten; they are simply served from both hostnames. Links already shared on fermiumusercontent.app keep working.

Only one domain is the link host at a time:

• Switch back to the shared host: click Use shared host instead on the domain that carries the badge. New links use fermiumusercontent.app again; the domain stays active and keeps serving.
• Switch to another domain: click Use for links on any other active domain.

The automatic step applies whenever a domain goes live while no link host is set. If you switched back to the shared host and later bring a second domain live, that domain becomes the link host; click Use shared host instead again if you do not want that. A domain that goes live while another one is already the link host changes nothing.

What is served on your hostname

• Only your workspace's documents under /d/. A link to another workspace's document returns not found here.
• The link resolver under /x/, scoped to your workspace, so a bare alias resolves here without the @workspace prefix.
• Your workspace's wiki under /w/: published folders at /w/r/<root-slug>/, and an agent-tree wiki at /w/ when one is enabled, in which case the bare root / redirects to /w/. Your uploaded SVG icons under /icons/.

Anything else on your domain, the bare root included when no wiki is enabled, redirects to the same path on fermium.app. So docs.acme.com/app opens the app, and a visitor who types your domain alone is never left on a 404.

• /robots.txt, which disallows everything unless you turned on search-engine indexing for the wiki, in which case it allows /w/ only.
• The same access rules. A Restricted document sends the reader to fermium.app to sign in and returns them to your hostname.
• The same sandbox and headers as the shared content host.
• The shared favicon and diagram script assets, and health probes.
• No app, no API, no login page. Those stay on fermium.app.

Removing a domain

Click Remove on the domain card. The route and certificate are deleted immediately and, if it was the link host, links revert to the shared host. Delete the CNAME on your side too; a CNAME left pointing at a service you no longer use is how hostnames get taken over.

Troubleshooting

Verification never completes. Check both records from outside your network. Make sure the TXT name is exactly _fermium.<your hostname> and the value is the full fm-verify-... string in one quoted chunk.

Stuck in issuing. Look for a CAA record on yourcompany.com. If one exists it must allow letsencrypt.org. Also make sure the hostname is not proxied by another CDN; the CNAME must resolve to our target directly. Click Verify to poll; the card shows the certificate's current condition.

The browser says the connection is not private. The certificate has been issued but your browser cached an earlier failure, or your DNS still points elsewhere. Wait a minute and try a private window.

Links still show the shared host. The domain is not active yet (click Verify to poll), or someone chose Use shared host instead. Click Use for links on the active domain.

HSTS on the parent domain. If yourcompany.com sends HSTS with includeSubDomains, the new hostname is HTTPS-only from the first request. That is fine; it just means the certificate has to be issued before anyone visits.

The API for all of this is in the REST reference.