Custom Domains

Every app ships on a Buildspace hostname (your-app.apps.buildspace.studio for prod, your-app.devapps.buildspace.studio for dev). When you want the app to be your product, point a domain you own at it. Buildspace attaches it to the environment's runtime service, hands you the exact DNS records to create, issues the TLS certificate automatically, and makes the domain your app's canonical URL once it verifies.

You keep control of DNS. Buildspace never asks for registrar credentials — it tells you what records to create, and you paste them into your own DNS provider.

Connect a domain

# production
buildspace domains add app.yourbrand.com

# a separate domain for the dev preview
buildspace domains add dev.yourbrand.com --env dev

The response lists the records to create at your DNS provider:

app.yourbrand.com  [prod]  pending DNS
  target: abc123.up.railway.app
  verified: no   certificate: pending   login redirects: allowed
  DNS records to create at your DNS provider:
    CNAME app  ->  abc123.up.railway.app   (traffic: pending)
    TXT   _acme-challenge.app  ->  bs-verify-…   (verification: pending)

Create both records, then check:

buildspace domains verify app.yourbrand.com

DNS propagation takes anywhere from a minute to a few hours. Re-run verify until the status flips to active — at that point the certificate is issued and the domain becomes the app's public URL.

You can do the same thing in Creator Studio under Hosting → Custom domains, which shows the same records with copy buttons.

Apex vs subdomain

A subdomain (app.yourbrand.com, www.yourbrand.com) is the straightforward case: a plain CNAME works everywhere.

An apex/root domain (yourbrand.com) can't legally take a CNAME in classic DNS. Use your provider's flattening record instead:

Buildspace flags apex domains in domains list and repeats this guidance in the output.

Until it verifies, nothing breaks

Your app stays reachable on its *.apps.buildspace.studio hostname the whole time. The public URL only switches to your domain once it is verified and the certificate is issued, so a half-configured DNS record never takes the app down. The Buildspace hostname keeps working afterward as a fallback and debug URL.

Login on your own domain

Buildspace login is an OAuth-style redirect: your app sends the user to login.buildspace.studio and receives an auth code back at your callback URL. For that callback to be accepted, the origin must be on the app's redirect allowlist — which is what the "login redirects" flag on a domain controls. It is on by default when you add a domain, and you can change it:

buildspace domains auth app.yourbrand.com off
buildspace domains auth app.yourbrand.com on

Your app then sets its own session cookie on your domain from the exchanged token. The platform's .buildspace.studio SSO cookie is deliberately not shared into your domain — it only makes the trip through the login app silent on repeat sign-ins. For the cookie your app sets, use Secure, HttpOnly, SameSite=Lax, and Path=/. SameSite=Strict will drop the cookie on the first navigation back from login; don't use it.

If you want one session to span several of your own subdomains (app.yourbrand.com and account.yourbrand.com), set your cookie's Domain=.yourbrand.com — that's your app's call, not Buildspace's.

Remove a domain

buildspace domains remove app.yourbrand.com

The domain is detached from the runtime service and the app falls back to its Buildspace hostname. Delete the DNS records at your provider afterward.

Reference

• buildspace domains — full command reference, including --json output for agents.
• Hosting overview — how deploys, environments, and env vars work.