Custom domains

Attach a hostname you control to an existing production deployment:

xeer domains add app.example.com
xeer domains status app.example.com

The app must have a successful production deployment and must be enabled. Xeer keeps the generated *.xeer.run hostname; a custom domain is an additional origin for the same application, state, and authentication policy.

#Add the DNS records

xeer domains add prints:

• the CNAME from your hostname to customers.xeer.run;
• any ownership TXT record Cloudflare has issued; and
• any certificate-validation TXT records Cloudflare has issued.

Add every record currently shown, then poll:

xeer domains status app.example.com --json

Cloudflare reports ownership validation and certificate DCV as separate stages. Hostname ownership is reported through ownership_verification and the hostname status; certificate TXT records can arrive later through ssl.validation_records while the SSL status is still pending. Treat the domain as ready only when status is active, providerSslStatus is active, and nextAction is ready.

Records can arrive in stages. The JSON result's nextAction is the immediate action to take; an ownership TXT is never hidden behind a “wait” instruction. Xeer reports the domain active only after Cloudflare reports both the hostname and certificate active and a public HTTPS health request through that hostname reaches the exact production artifact deployed for the app.

Cloudflare can return more than one certificate-validation TXT value with exactly the same _acme-challenge name. Create a separate TXT record for every value shown; DNS allows those records to coexist at one name. Do not replace the first value with the second. Keep all records currently returned by xeer domains status until nextAction is ready.

For ordinary DNS providers, TXT pre-validation lets you issue the certificate before changing the CNAME, which avoids a cutover gap. If the customer's DNS is itself proxied by Cloudflare (Orange-to- Orange), ownership pre-validation is not supported: create the proxied CNAME to customers.xeer.run and let Cloudflare perform real-time hostname validation. Certificate TXT records may still be required; follow the records returned by the command.

#List and remove domains

xeer domains ls
xeer domains remove app.example.com

ls includes both generated and custom origins. Removing a custom hostname advances its domain epoch before deleting the Cloudflare hostname and certificates, so a browser cookie from an older attachment cannot become valid again after reattachment. If provider deletion is temporarily unavailable, the CLI returns XE5197 with detached: true and cleanupPending: true; routing is already dark, and repeating the same remove command resumes cleanup.

The default allowance is 10 custom hostnames per user across all of that user's applications. Xeer does not reserve one user's allowance for another user. Remove an unused hostname before adding another after reaching the limit.

Disabling an application also darkens its custom-domain routing generation. Enabling the application does not blindly restore that old mapping: the domain returns to verifying until Cloudflare state and the exact public production-artifact health proof pass again. Temporary DNS/TLS probe failures are retried with a grace period; they do not delete the Cloudflare hostname or certificate.

#Machine-readable workflow

Every command supports --json:

xeer domains add app.example.com --json
xeer domains status app.example.com --json
xeer domains remove app.example.com --json

Provider identifiers and Worker script names are internal and never appear in these results. DNS validation values are public tokens, but Xeer still omits them from audit metadata.