Cloud & Hosting · 7 min read · Updated 15 August 2026
How to publish an AI-built app and get a live URL
Apps built in NorthernGo are published by saving them. The code is uploaded to Firebase Storage and the project record points at it, and the server renders that saved document on every request. Premium and Pro projects can claim a name at yourname.northerngo.com; Free projects are shared through the northerngo.com/?app=projectId link instead. There is no build step, no terminal and no deploy command.
Saving is deploying
The mental model most people bring from other tools is a pipeline: you finish the app, you press a deploy button, a build runs somewhere, and a static bundle lands on a CDN. Then you make a change and repeat the whole thing.
NorthernGo does not work that way, and knowing that saves a lot of confused clicking.
When you save a project, the app's full state is serialised to JSON and uploaded to Firebase Storage at projects/<your-user-id>/<project-id>.json. The project record in Firestore stores the download URL of that file along with the project's name, its subdomain, its icon and any integrations. Nothing is compiled. Nothing is bundled.
When someone visits your app, the server reads that saved document and returns it. The consequence is direct: the live app is always the last version you saved. Save again and the change is live on the next page load, with no republishing step. There is also no rollback, which is the flip side of the same design — save deliberately.
Step 1: Save the project
In the account menu in the navigation bar, choose Save project. The first save creates the project and gives it an id; every save after that overwrites the stored document.
The Free plan allows five saved projects. When you reach that limit, the interface says so plainly rather than failing silently, and you either delete an old project or upgrade. Premium and Pro have no cap on saved projects.
If you are not signed in there is nowhere to save to, so a project built as a guest exists only in that browser tab. That is the single most common way people lose work here.
Step 2: Claim a name at northerngo.com
Open My projects, click the ⋮ menu on the project card, and choose Create PWA. Despite the name, this is the dialog that gives your app its own web address — the PWA part is what comes with it.
Type the name you want in the field marked Choose PWA link. The .northerngo.com suffix is fixed. The rules the server enforces:
- lowercase letters a–z, digits and hyphens only, 2 to 63 characters
- it cannot start or end with a hyphen
- a list of platform names is reserved —
www,api,app,admin,shop,support,docs,demoand around thirty others - names are unique across all users; if the one you want is taken you get a clear error and a suggested free alternative such as
yourname-2
The same dialog takes an app icon, uploaded as an image file and stored with the project. Use a square image, 512×512 pixels is the practical size, and keep it under roughly 700 kB — the icon is stored inline with the project record and an oversized file will be rejected. The details of icon behaviour across iOS and Android are covered in the guide to creating a PWA with custom app icons.
This step requires Premium or Pro. A Free project can technically hold a name, but the server will not serve an app on a subdomain for a Free account — it redirects the visitor to the ?app= link instead, which is a confusing experience to hand to a customer. Claim the name once you are on a paid plan.
Step 3: Open the live link
Back on the project card, the Live button opens your app at the best address it has, and Copy puts that same address on your clipboard. The order of preference is:
- a custom domain, if one is connected — Pro only, covered in connecting a custom domain and SSL
https://yourname.northerngo.com, if a name has been claimedhttps://northerngo.com/?app=<projectId>as the fallback that always works
That third link is not a lesser version of the app in terms of features. It is a genuinely different way of running it, and the difference is worth understanding.
The two ways an app is served
On a subdomain or custom domain, your app is the top-level document. The server assembles the HTML, injects a REST-based SDK into the <head> so window.NorthernGoDB and the other globals exist before your code runs, adds the PWA meta tags, and registers a service worker. The domain also serves a real /manifest.json and /sw.js, which is what makes the app installable on a phone home screen and gives it a styled offline shell.
On the ?app= share link, your app runs inside a sandboxed iframe on northerngo.com, and the SDK calls are bridged out to the parent page rather than made directly. The app works, data saves, login works. What you do not get is installability, a service worker of your own, or a URL that looks like it belongs to you.
That is the practical argument for the subdomain, and it is worth stating honestly rather than dressing up: on Free your app is fully functional but lives at a shared address.
Where Firebase actually fits
The word Firebase appears a lot around this platform, and it is used for three separate things that are easy to conflate.
Firestore holds project metadata: owner, name, subdomain, custom domain, icon, integration settings, timestamps. Firebase Storage holds the saved code as a JSON file. Firebase Hosting serves northerngo.com itself — the builder, the marketing pages, the prerendered resource articles.
Your published app is served by none of those. It is served by the NorthernGo backend, which reads the saved code and renders it per request. So while Firebase is genuinely part of the stack, there is no per-app Firebase Hosting site being created for you, and no hosting configuration you can edit. Being clear about that matters, because it explains why there is no build log to read and nothing to configure when something goes wrong.
What this deliberately does not give you
- No version history. Saving overwrites. If you want a snapshot of a working version, take a ZIP export before making risky changes; export is available on the paid plans through the project menu.
- No staging environment. There is one saved state and it is the live one. Build risky changes in a duplicated project.
- No custom headers, redirects or routes. Your app is one document at one address. Client-side routing inside the document works; server-side routes do not exist.
- No git integration. The source of truth is the saved project, not a repository. If working from a repo matters to you, exporting the code and hosting it yourself is the honest path, and the reasoning is set out in avoiding vendor lock-in with AI builders.
- No control over caching. The service worker on a published subdomain caches the interface shell and static assets but never caches backend calls, deliberately, so your app never shows stale data from the database.
Troubleshooting
The live app shows an old version. Something was changed in the editor but not saved. The served document is always the last saved one — go back to the project, save, and reload.
A subdomain redirects to northerngo.com. No project matches that name. Either the name was never claimed, or it was claimed on a different project. Reopen Create PWA on the correct project and save the name again.
A subdomain redirects to a ?app= link. The project belongs to a Free account. Subdomain serving requires Premium or Pro; the redirect is the fallback rather than an error.
"That name is already taken". Names are unique across every user on the platform, not just your own projects. Take the suggested alternative or pick something more specific.
The app loads but nothing saves. Check that the app is calling window.NorthernGoDB.save rather than localStorage. On a published domain the SDK is injected before your code runs, so the global will exist; if data still disappears on reload, the app is storing it in the browser. The database guide covers how to move it.
A blank page on a subdomain. Almost always a JavaScript error in the saved code rather than a hosting problem. Open the browser console on the live URL — the error will point at the line in the generated document.
Frequently asked questions
Do I have to press publish every time I change my app?
No. The server renders whatever version of the project is currently saved, so saving is what makes a change live. There is no separate build or deploy step, and equally no way to keep a newer draft private while an older version stays online.
Can I publish an app on the free plan?
Yes, but only on the shared link northerngo.com/?app=projectId. Your own name at yourname.northerngo.com requires Premium or Pro. A Free project that has a name claimed will still redirect visitors to the shared link, because the server checks the plan before serving a subdomain.
Where is my app actually hosted and is the data in the EU?
The saved code lives in Firebase Storage with its metadata in Firestore, and the app is served by the NorthernGo backend rather than by a per-app hosting site. Application data written through the SDK goes to a Supabase PostgreSQL database hosted in the EU. NorthernGo is run from Sweden and built EU-data-residency first.
Can I roll back to an earlier version of my app?
Not from the platform. Each save overwrites the stored document, and there is no version history to restore from. The editor has an undo for the current session, and paid plans can take a ZIP export of a working version before making risky changes, which is the practical way to keep a snapshot.
Why can people install my app from a subdomain but not from the share link?
Because installability requires the app to be the top-level document on its own origin, with its own manifest and service worker. A subdomain serves exactly that. The share link runs the app in a sandboxed iframe inside northerngo.com, so the browser has no separate app to install.
Build it yourself
NorthernGo turns a plain-text description into a working web app with a database, login and a live URL. Local AI generation runs on your own GPU, is unlimited, and is free on every plan.