Documentation/Deployment/Publish Your App (Go Live / Supero Cloud)

Publish Your App (Go Live / Supero Cloud)

Go Live publishes your generated app to a permanent, Supero-hosted URL — no cloud account, no infrastructure to configure. This page covers the Supero Cloud path: how preview and live differ, how long a preview lasts, what the deploy contract is, and how to take an app back offline.

Publishing to Supero Cloud: request, asynchronous build, status polling, and a live URL — Go Live is asynchronous. You get a 202 and a poll URL, not a finished deployment.

Before You Publish

⚠️ Publishing is not the same as being ready for real users

This page covers the mechanics of getting an application live. It does not cover hardening it. Before you point real customers at a published app, work through Going to Production — it covers the seeded demo credentials a generated app ships with, the demo login affordances, the permissive-by-default access policies, and which tenant your customers should be in. That last one matters more than it sounds: anyone left in default-tenant can read every tenant in the project.

Overview

Once you have built an app in a project, Go Live turns it from a temporary preview into a permanent app that Supero builds and hosts for you. There is nothing to provision and no cloud account to connect. The published app answers at:

text

https://live-{domain}-{project}.supero.live

where {domain} is your Supero domain and {project} is the project name. Both are lowercased and any character outside a-z, 0-9 and - becomes a dash. If the combined name would exceed 49 characters it is truncated and a short hash is appended, so very long project names still produce a valid, stable hostname. You do not choose the hostname, and it cannot be changed after the fact.

🚨 You cannot point your own domain at a published app

There is no custom-domain support on Supero Cloud. No DNS automation, no certificate provisioning, no domain mapping. Routing for *.supero.live is a fixed set of rules in front of the platform, and a published app is reachable only at the live-{domain}-{project}.supero.live address above. The custom-domain fields in workspace and tenant settings are tenant-routing text fields whose own help text tells you to configure DNS manually — they do not change where a deployed app answers. If you need a branded address, mail [email protected] and treat it as a manual arrangement.

ℹ️ App hosting vs. self-hosting the platform

Going live is a per-project choice about where your app's UI runs — it is not the same as self-hosting Supero itself. To run the UI in your own AWS or GCP account instead, see Deploy to Your Own AWS or GCP. To run the platform itself on infrastructure you control, see On-Premise Deployment. For a side-by-side comparison, see Choosing a Deployment Option.

What Actually Gets Hosted

Going live publishes your app's UI to a public URL that Supero builds and hosts. Authentication, your data, business logic, connected services, and AI generation all continue to run on Supero's backend — going live does not move any of that, it gives the UI a permanent home and address.

text

Your users' browser --HTTPS--> https://live-{domain}-{project}.supero.live  (UI, hosted by Supero)
                                    |
                                    +--/api, /ai--> api.supero.dev (auth, data, services, AI)

The container runs with a project-scoped API key that Supero resolves server-side at deploy time — it is never part of the bundle you download. Each app container is provisioned with 1 vCPU and 512 MiB, and serves on a single instance.

Preview and Live Are Two Separate Deployments

This is the single most useful thing to know about Supero Cloud. A preview and a published app are not two stages of one pipeline — they are two independent services, with two hostnames, two status records, and two lifecycles. One project can have both at once, neither, or either alone.

One project produces two parallel lanes: an ephemeral preview service and a persistent live service, each with its own URL and its own teardown path — Two lanes from one project. Nothing that happens to the preview lane can reach the live lane.

	Preview	Live (published)
Service name	preview-{domain}-{project}	live-{domain}-{project}
URL	https://preview-{domain}-{project}.supero.live	https://live-{domain}-{project}.supero.live
Started by	Launch preview, from App Studio	Go Live
Lifetime	30 minutes, measured from the moment the app becomes reachable	Permanent — no expiry
Idle behaviour	One instance is kept warm for the whole lease	Scales to zero; the next request wakes it
Stopped by	Stop preview, or the sweeper when the lease runs out	Take offline — nothing automatic
Purpose	A quick look while you are iterating	A permanent URL to share with real users

The live service name is derived from the preview name by swapping the prefix, rather than being computed again from scratch. That is deliberate: it keeps long, truncated names consistent between the two lanes so routing resolves identically for both.

💡 Stopping a preview cannot take your live app down

Three independent guards keep the sweeper and the Stop action away from a published app: the sweeper only ever lists services whose name starts with preview-, so a live- service is structurally invisible to it; a published service carries a permanent marker that is a hard skip; and the Stop path refuses outright to delete a service that reads as permanent, failing closed if it cannot determine that. Only Take offline removes a published app.

How Long a Preview Lasts

A preview lives for 30 minutes. The clock starts when the app actually becomes reachable, not when you clicked Launch — so a slow build does not eat into your lease. A sweeper runs every 15 minutes and deletes previews whose lease has run out, which means a preview typically disappears somewhere between 30 and 45 minutes after it came up.

⚠️ This is a fixed lease, not an inactivity timeout

A preview you are actively clicking through expires on exactly the same schedule as one nobody has touched. Traffic does not extend it. If you need an app that stays up, publish it with Go Live — that is what the live lane is for. If you see a different lifetime quoted elsewhere in the product, 30 minutes is the number the sweeper actually enforces.

•Relaunching a preview after it expires is fine and gives you a fresh 30-minute lease. It rebuilds, so it is not instant.
•A domain can have at most 5 previews running at once across all its projects.
•On a free or trial plan you get one running preview per project. Launching a second returns a quota response rather than starting a build.
•Launching a preview on a project that is currently published returns a conflict rather than quietly demoting the live app.

Prerequisites

•A plan with a live-deployment allowance. Live deployments start at Starter — Trial and Basic are preview-only. See Plans & Billing. Going live with no allowance left returns a 402 upgrade prompt instead of starting a build.
•A Supero login with permission to update the project (project_admin or domain_admin). Non-admin callers are pinned to their own project.
•An app that has already been generated in the project — at least one completed build. Go Live publishes a specific bundle, identified by its generation and file id.

💡 No cloud account needed

Unlike deploying to your own AWS or GCP, going live on Supero Cloud has no connect step and nothing to authorize — you do not need an AWS, GCP, or any other cloud account. The app runs in infrastructure Supero owns and pays for.

Going Live

From a project with at least one completed app build:

1
Open Go Live
From the app card in App Studio, click Go Live.
2
Choose Supero Cloud
Three targets are offered — Supero Cloud, Amazon AWS, and Google Cloud. Pick Supero Cloud. A project that has already been deployed is pinned to its original provider, so you do not accidentally leave an orphaned service running in another cloud.
3
Confirm
Publishing counts against your plan's live-deployment allowance.
4
Wait for the panel
The deploy starts in the background and the panel polls every few seconds until the app is serving, then shows the permanent URL.

Once the URL is live, a plain HTTP check confirms the container is up and serving:

bash

curl -s -o /dev/null -w "%{http_code}\n" https://live-{domain}-{project}.supero.live/

A 200 means the container is serving the page. It does not by itself confirm data is loading — see Verifying Your Live App below.

How a Deploy Progresses

Go Live is asynchronous. The request returns as soon as the build has been queued — it does not wait for the app to come up. If a build was started you get a 202 with a poll URL; if the service was already running you get a 200 with the existing URL. The panel then polls that URL until the app settles.

Status	What it means
none	No deployment has ever existed for this lane.
launching	The build is running. This is written before the work starts, so it appears immediately.
running	The service is serving and its URL is set.
failed	Something in the pipeline failed. A reason is recorded with the status.
stopped	Explicitly torn down — Stop preview, or Take offline.
expired	A preview whose 30-minute lease ran out and was swept.

The pipeline behind launching is: download the bundle, sanitize it, hydrate it, validate it, build the image with Cloud Build, deploy to Cloud Run, then grant public access. The background worker never raises — every failure is written onto the status record with a message, so a failed deploy always ends in failed rather than in silence.

•The build is capped at 8 minutes for a web app, and 15 minutes when mobile output is included. Past that the build is abandoned and the deploy is marked failed.
•After the image is built, the Cloud Run rollout has its own 6-minute budget with a further recovery poll and two retries for transient errors.
•The last step is making the service publicly invocable. That permission takes 30 to 90 seconds to propagate, so the platform polls until the URL genuinely answers an anonymous request before reporting the deploy done.
•Status is reconciled against the real service on every poll. A launching record whose service never appeared is flipped to failed rather than spinning forever, and an expired lease is flipped to expired.

Verifying Your Live App

A live URL that returns 200 is not by itself proof the app is working — the container can serve the page while the app underneath is still blank. Check all of the following:

•The page loads with your app's real branding, not a blank shell or an error banner.
•Any catalog, feed, or listing page shows real records, not empty cards.
•You can sign up or log in as an end user.
•A create action (add a record, place an order) persists after you reload the page.

💡 The panel checks the version, not just the state

The dashboard does not treat running as finished on its own — it also confirms that the version now serving is the bundle you just published. That is why a redeploy can sit in an in-progress state briefly even though something is already answering at the URL: the old version is still up while the new one builds.

Viewing Deploy Logs

When a deploy fails or an app crashes on startup, the logs from the running container are the fastest way to find out why. The dashboard has a Cloud Deploy Logs page in the sidebar, available to anyone with deployment read permission, which reads recent logs for your app.

•It returns 200 log lines by default, up to a maximum of 500 per request.
•It looks back one hour by default, up to a maximum of 24 hours.
•You can filter by severity.
•Responses are cached for 8 seconds, and queries are rate limited to 30 per minute per domain — a burst past that returns 429 with a Retry-After header. Auto-refresh is off by default for the same reason.

ℹ️ This is Supero Cloud only

The log reader covers apps published to Supero Cloud. For an app deployed into your own AWS or GCP, the logs live in your own account — CloudWatch or Cloud Logging — and Supero does not proxy them. See Deploy to Your Own AWS or GCP.

Taking an App Offline

Take offline is the only thing that removes a published app. It appears alongside Go Live and Publish update on the app card in App Studio.

•It deletes the live Cloud Run service, which stops the app answering and ends its cost.
•It clears the project record: the project returns to dev, the live URL is cleared, the deployment provider resets, and the app is de-listed from the public directory.
•Returning the project to dev is what lets you edit and rebuild again — see Managing a Live App below.
•It does not touch data. Schemas, records, tenants, and users are untouched by publishing and by unpublishing.

💡 The result is honest

Take offline reports what actually happened rather than assuming success. If the teardown could not be confirmed, you are told the app was not stopped — so a failure surfaces immediately instead of leaving you believing an app is down while it is still serving. Re-run it if that happens.

⚠️ It will not clear a record pointing at your own cloud

If the project was deployed to your own AWS or GCP, this path deliberately refuses to clear the deployment record — that record holds the only pointer to a service still running and still billing in your account. Tear those down from the AWS or GCP deploy panel instead.

Managing a Live App

•Redeploying: publish new changes with Publish update, or by going through Go Live again. It builds and replaces the running app in place — the service name and URL do not change.
•Protecting the running app: while a project is in live mode, destructive rebuilds are blocked. Return the project to dev to edit and rebuild, then publish again.
•Removing a deployment: Take offline, as above.

⚠️ The build lock is a separate toggle from the deployment

The dev/live build lock is a flag on the project, and the dashboard is what flips it — it sets the project to live when you publish from the UI and back to dev when you take the app offline. Publishing through the API or an MCP tool deploys the app but leaves the project in dev, so the rebuild protection is not applied. If you drive deploys programmatically and want the lock, set the project mode explicitly.

Troubleshooting

What you see	Likely cause / fix
Upgrade prompt instead of a deploy starting	Your plan has no live-deployment allowance left. Trial and Basic are preview-only; live deployments start at Starter. See Plans & Billing.
Preview vanished while you were using it	Previews run on a fixed 30-minute lease from the moment they became reachable, and a sweeper reclaims them every 15 minutes. Traffic does not extend the lease. Relaunch for a fresh one, or publish with Go Live if you need it to stay up.
The panel never leaves an in-progress state	Check Cloud Deploy Logs for the build. A build that exceeds its cap (8 minutes web, 15 with mobile) is abandoned and the status flips to failed. A launching record whose service never appeared is also reconciled to failed on the next poll.
Deploy reported success but the URL 403s for a few seconds	Public access is granted as the last step and takes 30 to 90 seconds to propagate. The platform waits for the URL to answer anonymously before reporting done, so this should be brief. If it persists, redeploy.
App loads but pages are empty	The project may not have been seeded, or the build did not finish generating. Confirm the app build completed, then publish again.
First request after a while is slow	A published app scales to zero when idle, so the first request after a quiet period cold-starts the container. This is expected. Previews behave differently — they keep one instance warm for the life of the lease.
The panel will not let you rebuild	The project is in live mode. Return it to dev from the dashboard before making destructive changes, then publish again.

Driving It Programmatically

Everything the deploy panel does is a REST call. Authentication is a JWT bearer token; launching, publishing, and stopping require permission to update the project, and reading status or logs requires read permission.

text

POST   /api/v1/preview/project/{domain}/{project}/launch    -> 202 {status, service_name, ttl_minutes, poll_url}
GET    /api/v1/preview/project/{domain}/{project}           -> preview lane status
DELETE /api/v1/preview/project/{domain}/{project}           -> stops the PREVIEW only

POST   /api/v1/preview/project/{domain}/{project}/go-live   -> 202 {status, public_url, service_name, poll_url}
GET    /api/v1/preview/project/{domain}/{project}/go-live   -> live lane status
DELETE /api/v1/preview/project/{domain}/{project}/go-live   -> {stopped} — unpublish

GET    /api/v1/preview/project/{domain}/{project}/logs      -> recent container logs

The body for both POSTs is {generation_uuid, file_id, project_uuid} plus an optional app_type of "web" (default) or "all". The project name in the URL must already be lowercase and match [a-z0-9-] or the call is rejected. Publishing returns 202 when a build was started and 200 when the service was already up.

🚨 Poll the poll_url you were handed, not the bare project path

A go-live 202 returns the /go-live poll URL. The bare project path reports the preview lane, which is a different service — poll it after publishing and you will watch the preview forever while your published app comes up unnoticed. This changed when the two lanes were split into separate services; anything written against the older single-lane behaviour needs updating.

•402 — plan gate. No live-deployment allowance left.
•409 — launching a preview would conflict with a live deployment on this project.
•429 — log queries only, when the per-domain rate limit is exceeded. Honour the Retry-After header.
•401 on unpublish — the token carries no session. Unpublish deliberately refuses to run as a bare platform-admin token; call it as a signed-in user.

From an MCP client

The same operations are exposed as MCP tools, so you can publish and tear down from an AI editor: build_deploy and build_deploy_status for an ephemeral preview, build_go_live to publish, build_teardown to remove both lanes, build_logs to read logs, and build_set_project_mode for the dev/live build lock. build_deploy targets local and cloud previews only — there is no AWS or GCP target over MCP. build_teardown deliberately refuses projects deployed to a customer cloud. See the MCP Tools & Protocol Reference.

Next Steps

•Choosing a Deployment Option — a side-by-side comparison of Supero Cloud, your own AWS or GCP, and self-hosting the platform.
•Deploy to Your Own AWS or GCP — publish the same app into your own cloud account instead.
•On-Premise Deployment — self-host the platform for data-sovereignty or air-gapped requirements.
•Plans & Billing — how live deployments count against your plan.
•Contact — production launches and capacity questions go to [email protected].

← PreviousChoosing a Deployment Option Next →Custom Domains

On this page