Custom domains

Adding a domain

On the app's Settings → Domains, choose Add a domain and enter a domain your team controls: a subdomain such as app.example.com, or a bare domain such as example.com when its DNS is on Cloudflare (see DNS records). Production's Domains page adds domains for production, the latest deploy; a development environment's adds them for that environment. Before the first deploy, a production domain shows a "hasn't been built yet" page, as production's own address does. A domain belongs to one app at a time, across every team.

DNS records

We don't manage your domain's DNS, so the Domains page, ib-apps domains and the API list every record to add at your DNS provider, each marked Required or Optional with what it's for:

Certificates come from Let's Encrypt, Google Trust Services or SSL.com, and the authority can change at renewal. CAA records, where a domain has them, allow only the authorities they name, so we look the domain's CAA records up when it's added and each time it's checked, and list a CAA record for each authority they leave out (letsencrypt.org, pki.goog, ssl.com). Some DNS providers add CAA records to every domain: Vercel's allow Let's Encrypt and Google but not SSL.com. A CAA record goes on the parent domain, not beside the CNAME; a bare domain's go on the domain itself.

A bare domain (example.com) is the top of its DNS zone, where DNS doesn't allow a CNAME. It can be added only when its DNS is on Cloudflare, which flattens a CNAME at the root: add the CNAME as listed. Elsewhere, an ALIAS, ANAME or flattened CNAME is answered with plain addresses, which can't be verified, so the domain is refused when it's added. Use www.example.com instead, and redirect example.com to it at your DNS provider or registrar; most offer that, Vercel's included.

Once the required records are in place, the domain is verified and its certificate issued, usually within a few minutes. If your DNS provider offers its own proxy for the CNAME, turn it off; the domain must point straight at cname.inferencebureau.app. A bare domain's CNAME on Cloudflare (shown as @) can stay proxied or DNS only.

A domain serves nothing until its _ib-verify TXT record is found, even once its CNAME points here: a CNAME only says where a domain points, and one another team removed may still point here. The value is new each time the domain is added. Once the domain is active you can remove the record. A domain not proven within 7 days of being added is let go, so it can't keep its owner from adding it.

Primary domain

Once one of production's domains is active, Make primary sends visitors there. Browsers that open production's inferencebureau.app address are redirected to the same path on the primary domain (a 308). Only page loads are redirected: the page's own requests, and webhooks and API calls pointed at the old address, are still served there, so nothing that already calls it breaks. Production's other domains keep serving as they are.

At production's next deploy, IB_APP_URL becomes https:// and the primary domain, and a Shopify app's URL in the Shopify admin moves to it too, so links the app sends out and the admin both use it. Unset primary, or removing the domain, stops the redirect within a minute, and the next deploy moves them back. If the primary domain stops pointing here, the redirect stops too until it's fixed.

Development domains

A development environment's Domains page adds domains that serve that environment's live dev server, hot reload included, for testing what needs your own domain (cookies on a shared parent domain, a sign-in provider's allowed origins). They count toward the plan's domains like production's, can't be primary, and are freed within the hour when the environment is deleted. Preview as a user stays on the environment's inferencebureau.app address.

Status

Pending domains are checked every hour and each time the Domains page opens; Check again asks right away, and has the domain's pointing and certificate looked at again now instead of on the usual schedule. Active domains are checked once a day. Removing a domain stops it serving the app within a minute and frees it for any app. Deleting an app, or a development environment, frees its domains within the hour, and a domain that was never active is freed 7 days after it was added.

From the CLI and the API

In a linked folder, or with --app <slug>:

ib-apps domains                          # list, with the DNS records still to add
ib-apps domains add app.example.com
ib-apps domains add dev.example.com --env development
ib-apps domains check app.example.com    # ask again now, instead of waiting for the hourly check
ib-apps domains primary app.example.com  # send production's visitors there (primary off: to none)
ib-apps domains remove app.example.com

ib-apps domains add adds a domain for production unless --env names a development environment; a linked folder's own environment doesn't count here.

The API has GET and POST /v1/apps/:app/domains (send environment with a development environment's name to add one for it), PATCH /v1/apps/:app/domains/:domain with {"primary": true} or false, POST /v1/apps/:app/domains/:domain/check and DELETE /v1/apps/:app/domains/:domain. Each domain comes back with its environment, whether it's apex and primary, its status, a message while it isn't active, and the records to add. Listing needs access to the app; adding, checking, changing and removing need a sign-in as an owner or admin, or a key with Apps Permissions.

curl https://api.inferencebureau.com/v1/apps/portal/domains \
  -H "Authorization: Bearer $IB_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"domain": "app.example.com"}'

Plans and limits

Custom domains aren't billed separately. Traffic to them counts toward production's requests and bandwidth like any other. See Plans and usage.