Custom domains
Custom domain setup starts after a healthy deployment. You point a subdomain you already own (for example app.yourcompany.com) at the live application. The default AWS URL stays available the whole time, including while DNS and the certificate are still finishing.
Open this from the project’s Custom domain step and turn on Use your own domain for this project.
Choose how DNS is managed
Section titled “Choose how DNS is managed”| Mode | What you do |
|---|---|
| Keep DNS at your registrar | After setup starts, add the CNAME records ScaleBop shows. Your nameservers stay where they are. |
| Let ScaleBop manage DNS in Route 53 | ScaleBop creates a hosted zone for the subdomain. Delegate the nameservers it shows at your registrar. |
| Use an existing Route 53 hosted zone | Pick a zone already in this AWS account. ScaleBop adds certificate validation and routing records there. |
Enter the hostname first. For an existing hosted zone, ScaleBop lists zones in the account that match that hostname.
Setup requests an ACM certificate for the hostname and waits until DNS proves you control it. Refresh status from the project page. Validation often takes a few minutes and can take longer. If the name does not resolve, or the certificate stays pending, see DNS propagation.
After the hostname is yours
Section titled “After the hostname is yours”The default AWS URL is what the deployment health check uses. The custom hostname is an additional address.
When the custom origin is ready, update anything that still names the old URL:
- Frontend origin variables that are baked into the client, such as
NEXT_PUBLIC_SITE_URLorVITE_APP_URL. - API CORS allowed origins, if the browser app calls a separate API host.
- OAuth callback URLs at your identity provider, when the app uses one.
ScaleBop shows these as guidance on the project when it can tell they apply. Change them, then redeploy if the value is compiled into the app.