# How to connect your own domain to an AI-built app > Connecting a domain needs Pro, a matching subdomain name and one CNAME record. What the platform configures for you, and why the first label matters. Source: https://northerngo.com/resources/connect-custom-domain-ssl/ Language: en Updated: 2026-08-15 --- **Connecting a custom domain requires the Pro plan. You save the domain on the project under My projects, which verifies ownership, approves the domain for login redirects and adds it to the API allow list, and then you create a CNAME record at your registrar pointing the hostname at the target the dialog gives you. HTTPS is handled at the hosting layer; there is no certificate to upload.** ### What a custom domain actually changes A NorthernGo app is always reachable somewhere. The question a custom domain answers is which address a customer sees and, less obviously, which origin the browser considers the app to belong to. Once a domain is connected, it takes priority over everything else. The **Live** button on the project card, the copy-link button, and the embed snippet all switch to `https://yourdomain` as soon as the domain is saved on the project. The `northerngo.com/?app=` link keeps working — it is not disabled — but it stops being the address anyone is handed. This is a Pro feature and it is enforced in two places, so there is no way around it: the menu item opens the upgrade dialog for Free and Premium accounts, and the server independently rejects the configuration call for any plan below Pro. The rest of the publishing model is unchanged from the [guide to publishing an app and getting a live URL](/resources/cloud-deployment-firebase-hosting/), which is worth reading first if you have not yet saved and named your project. ### Step 1: Claim the subdomain name first This step is genuinely required and it is the one that catches people out, because nothing in the interface tells you to do it in this order. When a request arrives on a domain that is not northerngo.com, the server takes **the leftmost label of the hostname** and looks for a project with that name — either as a claimed subdomain or as the project's own id. For `app.yourcompany.com` the label is `app`. For `www.yourcompany.se` it is `www`. So before you touch DNS, open **My projects**, use the **⋮** menu on the project, choose **Create PWA**, and claim the matching name. If your domain is going to be `app.yourcompany.com`, claim `app`. If it is going to be `shop.yourcompany.com`, claim `shop`. Two consequences follow directly from that, and both are worth knowing before you buy a domain for this: - **`www` and `app` are on the reserved list**, along with `api`, `admin`, `shop`, `store`, `support`, `docs`, `demo` and around thirty others. They cannot be claimed as project names. Pick a label that is specific to you — `boka`, `portal`, `kundwebb`, your product name — and use that as the subdomain of your own domain too. - **A bare apex domain does not work well here.** `yourcompany.com` with no label in front would resolve to the label `yourcompany`, which would have to be your project's claimed name. On top of that, the DNS specification does not permit a CNAME record at the apex of a zone. Use a subdomain of your domain, not the root. ### Step 2: Save the domain on the project Still in **My projects**, open the **⋮** menu and choose **Custom domain**. The panel is labelled **Connect custom domain** and takes a single value — the full hostname, with or without `https://`, which is stripped and lowercased before it is stored. The server validates it before accepting: - it must look like a real hostname, with at least one dot - raw IP addresses are rejected - `localhost`, `.local` and `.localhost` are rejected - `northerngo.com` and `northerngo.se` and anything under them are rejected Saving does three things. It writes the domain onto the project record, which is what makes it the app's primary address. It confirms that the caller is on Pro and actually owns a project carrying that exact domain — a deliberate check, because the endpoint feeds an authentication allow list and an unauthenticated version of it would be an open redirect. And it adds `https://yourdomain/*` to the approved redirect list used by Google sign-in, plus the backend's cross-origin allow list, so that API calls and logins from the new address are accepted immediately rather than after a deploy. Then it publishes the current saved version of the app, so there is something to serve when DNS starts resolving. ### Step 3: Create the CNAME record Log in wherever you bought the domain — Loopia, One.com, GoDaddy, Cloudflare — and open the DNS settings. Create a **CNAME** record for the label you claimed in step 1, pointing at the target NorthernGo shows you after saving. Read that target carefully, because there is a real caveat here. **If the dialog shows your own domain back at you, that is not a usable CNAME value.** Once the domain is saved on the project, the publish response describes the app's address as being that domain, and the dialog reflects it. In that case, email support@northerngo.com for the host to point at rather than guessing. One instruction to actively discard: **do not point the record at a Netlify address.** An older version of this documentation told users to CNAME to a "Netlify or Firebase target". Netlify is not part of the serving path, that address does not exist, and following it produces a domain that resolves to nothing. Apps on custom domains are served by the same NorthernGo backend that serves `*.northerngo.com`. Leave the TTL at whatever the provider defaults to, usually 3600 seconds. A shorter TTL is only useful if you expect to change the record again soon. ### Step 4: Wait, then verify DNS propagation is typically minutes and occasionally hours, depending on the TTL of any record you replaced. The certificate follows once the hostname resolves. The interface tells you to allow up to an hour for the padlock to appear, and that matches reality on most providers. You do not upload a certificate, generate a key, or configure a validation record. HTTPS is terminated at the hosting layer for the hostname once it points at the right place. If there is nothing for you to configure, that is the intended state, not a step you have missed. To verify: load the domain in a private browsing window, check that the padlock is present and that the app is your app rather than a redirect to northerngo.com, and if the app has login, sign in once from the new address to confirm the redirect list was updated. ### The limits worth knowing before you start - **One domain per project.** The field holds a single hostname. Two hostnames for the same app means two projects, which means maintaining the same app twice. - **No wildcard domains.** Each hostname is its own record and its own project. - **The apex problem is not solvable inside NorthernGo.** If you want `yourcompany.com` with no prefix to reach the app, the workable pattern is a redirect from the apex to your subdomain, configured at your DNS or registrar level. Many providers offer this as a "web forward" or "URL redirect" record. - **Changing plan matters.** Serving on a domain follows the plan check. If a Pro subscription lapses, the app falls back to the plan's serving rules and the custom domain stops behaving as expected. - **The shared link stays live.** Connecting a domain does not disable `northerngo.com/?app=`. Treat the custom domain as the address you promote, not as a way to make the other one inaccessible. - **Email is not included.** Connecting a domain here has nothing to do with MX records; your mail keeps working exactly as before, and transactional email from apps goes out through the platform's sender rather than yours. ### Troubleshooting **"Custom domain requires the Pro plan."** The account is on Free or Premium. Both the menu and the server enforce this; there is no partial version of the feature. **"The domain is not connected to any of your projects."** The configuration call ran before the domain was written to the project, or it was written to a different project. Reopen **Custom domain** on the right project and save again — saving performs both steps in the correct order. **The domain loads northerngo.com instead of the app.** No project matched the leftmost label of the hostname. Go back to step 1: the label in your domain and the name claimed under **Create PWA** must be identical. `portal.yourcompany.com` needs a project whose claimed name is exactly `portal`. **The domain resolves but the browser warns about the certificate.** Usually the certificate has not been issued yet — give it the full hour. If it persists past that, check that the record is a CNAME rather than an A record pointing at an IP you found somewhere, and that there is no conflicting AAAA or A record for the same label. **Google sign-in fails on the new domain but works on the old address.** The redirect allow list did not receive the new domain, which happens if the save was interrupted. Save the domain again from the project menu; the entry is added idempotently, so repeating it is safe. **Data or AI calls fail only on the custom domain.** The backend keeps an allow list of approved origins and refreshes it when a domain is configured. A domain that was written directly to the database without going through the save flow will not be on that list. Save it again through the interface. Once the domain is live, the app is still a Progressive Web App with its own manifest and icon, so visitors can install it to a home screen under your own brand. Getting the icon right across iOS and Android is covered in the guide to [creating a PWA with custom app icons](/resources/create-pwa-app-icons/), and if you are running a shop on the domain, [Stripe payments](/resources/integrate-stripe-payments-saas/) work the same way there as anywhere else. ## Frequently asked questions ### Can I use my own domain on the free or premium plan? No. Custom domains are a Pro feature, and the restriction is enforced both in the interface and on the server, so there is no workaround. Premium accounts get their own name at yourname.northerngo.com instead, which is a real address with a certificate and full PWA support. ### Why does my domain redirect to northerngo.com instead of showing my app? Because no project matches the first part of your hostname. The server reads the leftmost label — the app in app.yourcompany.com — and looks for a project claiming exactly that name. Claim the matching name under Create PWA on the project first, then the domain will resolve to your app. ### Do I need to buy an SSL certificate for my app? No. There is nothing to buy, upload or renew. HTTPS is handled at the hosting layer once your hostname points at the right target, and the interface tells you to allow up to an hour before the padlock appears. If the warning persists well past that, the DNS record is usually the cause rather than the certificate. ### Can I point my domain without a www or subdomain in front? Not reliably. DNS does not allow a CNAME record at the root of a zone, and the server identifies your app from the leftmost label of the hostname, which a bare domain does not have in a useful form. Use a subdomain such as portal.yourcompany.com and set up a redirect from the root at your registrar. ### What happens to my old northerngo.com link after I connect a domain? It keeps working. The custom domain becomes the address the platform shows and copies for you, but the subdomain and the ?app= share link both continue to serve the same app. If you need the old address to stop working, you have to handle that in the app itself, for example by redirecting when the hostname is not your own. --- ## Related - [How to publish an AI-built app and get a live URL](https://northerngo.com/resources/cloud-deployment-firebase-hosting/) - [How to turn an AI-built app into an installable PWA with your own icon](https://northerngo.com/resources/create-pwa-app-icons/) - [How to accept payments in an AI-built app with your own Stripe keys](https://northerngo.com/resources/integrate-stripe-payments-saas/) - [How to store data in an AI-built app with Supabase](https://northerngo.com/resources/connect-supabase/) --- NorthernGo is an AI-powered platform for building production-ready web apps with zero coding. Local AI generation via WebGPU is unlimited and free, and you own all generated source code. https://northerngo.com/