How to Move an AI-Built App to a Custom Domain

Moving an AI-built app to a custom domain is mostly a DNS change, and DNS is the easy part. You add one or two records at your domain registrar, point them at your host, wait for the change to spread, and the app answers at yourapp.com instead of a builder subdomain. You can do it in about fifteen minutes. The part that actually causes downtime is what breaks after the URL changes, and AI-built apps break in four predictable places. This guide covers both.

This assumes your app is already deployed and running on a builder subdomain and that you own a domain. If you have not deployed yet, do that first.

Step 1: Point your custom domain with DNS records

Your host will ask for either an A record or a CNAME record. The rule is simple. Use a CNAME for a subdomain like app.yourdomain.com. Use an A record, or your registrar's ALIAS or flattened CNAME feature, for the bare root domain yourdomain.com, because the DNS standard does not allow a plain CNAME on the root.

A common, reliable setup is to point the root at the host and add a www CNAME, then let the platform redirect one to the other so you do not split traffic. Most builders show you the exact values to paste.

Step 2: Wait for propagation and TLS

DNS changes are cached, so the switch is not instant everywhere. It usually settles within an hour and can take up to a day at the edges. After DNS resolves, your host issues an HTTPS certificate for the new domain automatically, which can add a few minutes. Do not panic if the padlock is missing for the first ten minutes. Check progress with a quick lookup:

# confirm the record resolves to your host
dig app.yourdomain.com +short
# or check the certificate once it is live
curl -sI https://app.yourdomain.com | head -n 1

The four things that break, and how to fix them

Everything above is standard. What follows is specific to apps that an AI assistant scaffolded, because these builders tend to hardcode the original URL in a few places you would not think to check.

1. Hardcoded URLs in the code

AI builders often write the deployment URL straight into the source: a base URL constant, absolute links in the header, image sources, or API calls that point at the old subdomain. After the move, those still call the old address. Search the codebase for the old domain string and replace hardcoded absolute URLs with a single environment variable so you never chase them again.

# find every place the old URL is baked in
grep -rn "yourapp.builder.app" ./src

# better: read it from one place
const BASE_URL = process.env.APP_URL   // set APP_URL=https://app.yourdomain.com

Keeping the base URL in an environment variable is the durable fix. Change one value, not twenty files, next time.

2. OAuth and login callbacks

If users sign in with Google, GitHub, or any provider, the login flow sends them back to a redirect URL that you registered with that provider. That URL still says the old domain, so logins fail with a redirect mismatch error the moment you switch. Add the new domain's callback URL in every provider console and in your auth settings. Keep the old one for a while so links already in flight still work. Our guide to social login and OAuth lists where these settings live.

3. CORS and API allowlists

If your frontend and backend are separate, or you call your own API from the browser, the backend probably allows requests only from the old origin. From the new domain those requests are blocked by the browser with a CORS error. Update the allowed origins list to include the new domain, and drop the old one once traffic has moved.

4. Links in emails and integrations

Password resets, magic links, receipts, and webhooks all contain your app URL. If they are built from a hardcoded value, they will send users to the old address after the move. Update the app URL setting your email templates read from, and update any webhook or callback URLs you gave to third parties like payment providers.

Step 3: Redirect the old URL and update search engines

Do not just abandon the old subdomain. Set a permanent redirect from it to the new domain so existing links and any search rankings follow you. If the app already had traffic, tell Google about the move through Search Console's change of address tool, and make sure your sitemap and canonical tags use the new domain. Google publishes a site move guide that walks through preserving rankings.

A quick pre-launch checklist

• DNS record added, resolves to the host, HTTPS certificate issued.

• Old domain string grepped out of the code, base URL moved to an env var.

• OAuth callback URLs updated in every provider and in auth settings.

• CORS allowed origins include the new domain.

• Email and webhook URLs point at the new domain.

• Permanent redirect from the old URL, canonical and sitemap updated.

Frequently asked questions

How long does the domain change take to go live?

The DNS record itself is added in minutes. Propagation usually completes within an hour and occasionally takes up to 24 hours at some networks. Certificate issuance adds a few minutes after DNS resolves.

Will I lose my Google rankings?

Not if you set a permanent redirect from the old URL to the new one and use Search Console's change of address tool. Google carries rankings across a properly redirected move. You lose rankings only if the old URLs start returning errors with no redirect.

Do I need to change anything in the app builder itself?

Usually you add the custom domain in the builder's settings and it handles the certificate. The extra work is in your own code and third-party settings: hardcoded URLs, OAuth, CORS, and email links, which the builder does not touch.

Can I use a subdomain instead of the root domain?

Yes, and it is often easier. A subdomain like app.yourdomain.com uses a plain CNAME, which every registrar supports cleanly, and it leaves your root domain free for a marketing site.