How to Connect a Custom Domain to Your App: Which Setup Fits?

Buying a domain is the easy part. Connecting a custom domain to your app can disrupt a working site or email if you change the wrong DNS record. Start with the address you want people to visit, identify who hosts the app, and follow that host’s current domain instructions rather than copying settings from another project.

You can make the choice without becoming a DNS expert. The questions below narrow down which records to change and what to verify before you share the new address.

Is your app already reachable at a host-provided address?

If it is not, get the app working there first. A custom domain points visitors toward a deployed app; it cannot make an unfinished deployment serve pages. Open the host-provided address in a private browser window and test the main action, such as submitting a form or loading a saved item. Fix a broken deployment before touching DNS.

If you still need a live address, follow this guide to deploying an AI-built app before changing DNS.

If the app works, find the custom domain instructions in your hosting provider’s current documentation or settings. Replit and other hosting environments can differ in how they ask you to verify ownership and where they send traffic. Follow the instructions for the place actually serving your app, not the tool you used to generate its code.

Do you want the root domain or a subdomain?

A root domain looks like example.com; a subdomain looks like app.example.com. For a product that also needs a separate marketing site, app.example.com gives each destination its own address. If the app is the whole public site, the root domain may be the simpler address to share.

Choose one primary address and decide what the other should do before editing records. Your host may offer a way to redirect the secondary address, but check its current instructions rather than assuming it happens automatically. For a small SaaS with a landing page elsewhere, start with app.example.com and leave the root domain’s existing site alone.

Who controls the DNS records for your domain?

The place where you bought a domain and the place managing its DNS may differ. Find the active DNS provider before changing anything. The app host’s instructions should tell you which record type and value it needs, and whether it requires a verification record. Copy those values from your own project settings rather than from an example screenshot.

Before saving, inspect records already using the name you chose. An existing website record may conflict with the new destination; email records serve a different purpose and should not be casually deleted. If you cannot identify an existing record, leave it in place until you understand its role. Make only the changes required for the address you selected.

Is the domain verified and serving the right app?

DNS updates can take time to appear across networks. Check the hosting provider’s domain status, then open the address on another device or network. Test an actual app action, not just the homepage, and check that the browser shows a secure connection before directing people there. If verification stalls, compare the host’s requested record with the record at your active DNS provider, including the name and value.

Once it works, note the primary address, DNS provider, app host, and the records you changed. Keep the host’s instructions close enough to find when you return to the project. That short recovery note helps you avoid undoing a deliberate setup during a later AI-assisted change.

What should you do before sharing the address?

Run one final check of the flows visitors will use. Review authentication if the app has accounts, test any database writes, and confirm that secrets remain in environment variables rather than client code. A domain makes an app easier to find; it does not make the app ready for sensitive production use.

If your deployment notes are scattered across chats, keep the domain setup and next actions in VibeCrumbs before you move on to the next feature.