Get the app working first
Start with the public address your host provides. If the app fails there, a custom domain will not repair it. Test the important routes, sign-in and saved data before introducing another moving part.
Find the account that manages your domain's authoritative DNS. It may be the registrar where you bought the name, or a separate provider. Make a record of the existing entries, especially anything used for email, before changing them.
Connect the name through your host
Add the domain in the hosting platform and follow its instructions for your project. It should tell you what needs verifying and which DNS records to create. Don't copy an IP address from an unrelated tutorial: the right target belongs to your deployment.
- Choose the primary address: the bare domain or its www version.
- Add the exact verification and routing records requested by the host.
- Preserve unrelated records, particularly mail delivery and domain verification entries.
- Wait for the host to show the domain and certificate as ready.
- Redirect the secondary address to the primary one while preserving page paths.
Check the certificate and the whole journey
Open the HTTPS address directly and confirm the browser reports a secure connection. Test both the primary name and the www alternative. A redirect should land on the same page, not drop every visitor at the homepage.
Then check services that remember your old address: authentication callbacks, allowed origins, payment redirects, form protection and email links. A homepage can look perfect while the sign-in flow still sends customers back to a preview URL.
If the new address isn't working
Keep the domain registration current and use an account you control. Set a renewal reminder and check the payment method; the address is part of running the product, not a one-time design choice.
- Domain not found: confirm the spelling, active nameservers and required DNS records.
- Host shows ‘pending’: recheck the exact record name and target, including whether the provider appended your domain automatically.
- Certificate warning: inspect the host's domain and certificate status before adding conflicting records.
- Redirect loop: review both the host's redirects and any proxy rules rather than adding another redirect.
- Home works, sign-in fails: compare authentication settings with the final HTTPS hostname.
A few fair questions.
How long does DNS take?
It varies with cached records, their time-to-live and the provider's verification process. Check the authoritative records and the host's status instead of repeatedly changing settings while waiting.
Will connecting my website break email?
Adding the correct website record need not change email. Replacing nameservers or deleting existing MX and related records can. Preserve the email configuration when connecting the site.
Does HTTPS make my whole app secure?
It protects the connection. It does not fix data permissions, leaked credentials or unsafe application logic. Those need their own checks.