Custom domains

Every service can get a free subdomain, but real apps want real domains.

Bring your own

bootload domain add myapp.com
# → prints a TXT (or CNAME) record to create
bootload domain list      # shows pending → verified
bootload deploy --image ... --domain www.myapp.com

Create the verification record at your DNS provider; verification usually completes within minutes (we re-check continuously — DNS propagation delays don't fail you). Once verified, any subdomain of the domain works in --domain.

Several domains on one service

A service can answer on as many domains as you like. The first comes from --domain at deploy time; attach more to the running service, and detach them again, without a redeploy:

bootload domain attach shop.example.com web
bootload domain attach www.shop.example.com web
bootload domain detach www.shop.example.com web

Every attached domain gets its own certificate. bootload status web lists them all with their TLS state.

Your app learns which domain a request arrived on from the Host header — that is the place to branch on (one code base serving shop.example.com and shop.example.be differently, a tenant-per-domain app, a marketing site and an app on two hosts). For the whole set up front, at boot, the platform injects BOOTLOAD_FQDN, BOOTLOAD_FQDNS and BOOTLOAD_URL — see environment variables.

Buy through bootload

bootload domain search myapp.com     # live availability + price
bootload domain buy myapp.com --autorenew

Charged from your wallet at registrar cost + €2. Registered domains are born verified — deploy on them immediately. Renewal is automatic when --autorenew is on and your wallet covers it (you'll get runway warnings long before it can't).

TLS

Certificates are issued and renewed automatically for every routed domain — BYO and registered alike. Cert status is visible in bootload status (tls=issued/pending/failed, with the error when something's wrong, e.g. DNS not pointing at us yet).