Subdomain

What a subdomain actually is

In app.example.com, com is the top-level domain, example.com is the registered domain (often called the apex or root), and app is the subdomain label. You create one by adding a DNS record for that name — typically a CNAME record pointing at your host, or an A record pointing at an IP address. You do not buy it, you do not register it, and you can create as many as you want on a domain you control.

Because the destination is independent, a subdomain can be served by an entirely different platform from the main site. That is what makes it the standard place to put an app: example.com stays with your marketing site while app.example.com runs the product. NorthernGo works the same way — apps on the Premium and Pro plans publish to <subdomain>.northerngo.com, or to a custom domain on Pro.

A subdomain is a separate origin, and that has consequences

This is the part that surprises people. For browser security purposes, app.example.com and example.com are different origins. Practically:

• localStorage, IndexedDB and cache storage do not carry over. A user logged in on one is not logged in on the other unless you deliberately share a cookie scoped to .example.com.
• A service worker registered on one does not control the other. Each host needs its own.
• HTTPS certificates must cover the exact hostname. A certificate for example.com does not cover app.example.com unless it is a wildcard or lists both names.

Subdomain or subfolder?

For SEO this argument has run for years and the honest answer is that both work. Google treats subdomains as part of the same site when the relationship is clear, but signals consolidate slightly more reliably in a subfolder. Where it genuinely matters is operational: a subfolder needs the same server to handle both, a subdomain does not. If the app is a separate deployment, a subdomain is the simpler and more robust choice — see the custom domain guide for pointing one at a published app.