Deploying: Supero Cloud, your AWS, or your GCP
Three targets, one bundle. What actually moves in each — and the check that tells you the deploy really worked.
Two different questions hide under the word "deploy": where your app UI runs, and whether you self-host the platform. Almost everyone only needs the first, and it is a one-click choice between three targets.
Separate the two questions first
Mixing these up is the most common source of confusion in the whole platform, so it is worth thirty seconds:
Where does my app UI run?
A per-project choice from the deploy panel: Supero Cloud, your own AWS account, or your own GCP project. This is the question you have.
Do I self-host the whole platform?
Installing Supero itself — API, database, AI orchestration — on infrastructure you control. An Enterprise path for air-gapped or strict-residency requirements. Most teams never need it.
Three targets, side by side
| Supero Cloud | Your AWS | Your GCP | |
|---|---|---|---|
| What deploys | Your app, on a supero.live URL | The UI container, on ECS Express | The UI container, on Cloud Run |
| Who builds it | Supero — one click | AWS CodeBuild, in your account | Cloud Build, in your project |
| Cloud account needed | No | Yes | Yes |
| Who pays for the hosting | Supero (against your plan) | You — your AWS bill | You — your GCP bill |
| First deploy | One click | ~10–15 minutes | ~5–8 minutes |
| Every deploy after | One click | One click | One click |
| Works offline / air-gapped | No | No — the UI proxies to Supero | No — the UI proxies to Supero |
A fourth option exists and answers the other question: self-hosted platform, where the runtime runs on your infrastructure under an Enterprise licence with an offline signed key and no phone-home. Two things to know: you still build and generate apps in Supero Cloud — on-premise is where you deploy and run them — and the integrations catalog, connectors and AI agent are separately licensed add-ons.
Supero Cloud — the default
One click from a project with at least one completed app build. There is no connect step and nothing to authorize — you do not need an AWS, GCP or any other cloud account.
The thing to understand is preview versus permanent. While you build, your app runs on a temporary Supero-hosted preview. Going live starts a second, independent deployment on its own server — it does not replace the preview, which keeps running until it expires or you stop it. The permanent URL looks like live-your-domain-your-project.supero.live; take it from the deploy panel rather than constructing one.
# quickest confirmation that the container is up and serving
# (quote the URL — angle brackets are shell redirections)
curl -s -o /dev/null -w "%{http_code}\n" "https://YOUR-LIVE-URL.supero.live/"Your own AWS or GCP
Both follow the same four stages: connect (one-time per project), build, deploy, verify. After the one-time connect, every redeploy is a single click that reuses the same connection.
AWS
AWS deploys run on ECS Express Mode, which provisions a Fargate service, a load balancer, a managed HTTPS certificate and a public URL from just an image and two IAM roles. The one-time Connect step launches a CloudFormation stack that creates a scoped deploy identity. First build is roughly 10–15 minutes and produces a URL like https://<id>.ecs.<region>.on.aws.
GCP
GCP deploys run on Cloud Run. Because Supero itself runs on GCP, the trust model is plain GCP-to-GCP impersonation: Supero mints a short-lived token for a deploy service account you grant. No service-account key of yours is ever created, downloaded or stored — which is usually the shortest path through a security review of the three.
The deploy panel shows the build's phase as it runs. The logs themselves live in your own account: CloudWatch on AWS, Cloud Build and Cloud Logging on GCP.
Verify it actually works
A green status is not the same as a working app. A deploy can report "running" while serving a blank shell or an empty catalog, because the container returns HTTP 200 on the page shell even when it cannot reach your data. Walk this once per target:
- The page renders — not just returns 200, but paints your app rather than a blank shell.
- You can sign in as a real user of the app.
- A list screen shows rows. This is the one that catches a misconfigured data path.
- A write succeeds — create a record and see it come back.
- The customer-facing surface loads, not only the admin console.
From an AI editor over MCP, this checklist has a tool: build_smoke_test. Pass it email and password and it verifies the URL loads and reads data; without them it checks that the page returns 200 and that the served ui/app.js and namespace are the ones you published. Pass expected_app_js_sha1 — the first 12 characters of sha1sum ui/app.js — and it also confirms the deploy actually rolled rather than serving a cached build. One limit: it only reaches supero.live, supero.dev and run.app hosts, so an AWS ECS Express URL has to be checked by hand.
Cost and teardown
On your own cloud you are paying your own bill, so the useful thing to know is what removing a deployment does — and what it does not.
That cuts both ways and is worth saying out loud: disconnecting a cloud is not a data deletion, and it is not an exit. If you need data out, that is a separate export conversation.
What to plan for
- None of the three app-hosting targets is air-gapped. All of them proxy to
api.supero.dev. Only the self-hosted platform is offline-capable. - Going live needs a plan that includes cloud hosting, and a live app counts against your plan's server quota.
- Regenerating does not redeploy. Changes — generated or hand-edited — only go live when you deploy again.
- Your own cloud means your own bill and your own quotas. A first AWS deploy also means a CloudFormation stack someone has to approve.
Where to go from here
- Not built the app yet? From a paragraph to a deployed app.
- Deploying from an editor instead of a dashboard: The same app, built over MCP.
- Full deploy details, including on-premise: the deployment documentation.
Build this on Supero
Describe it and get schemas, APIs, SDKs and a governed multi-tenant backend — or point your own AI editor at Supero over MCP and build it there.