Documentation/Deployment/Choosing a Deployment Option

Choosing a Deployment Option

Two separate decisions hide under the word "deploy" — where your generated app UI runs, and whether you want to self-host the whole Supero platform. This page walks through both.

Two Different Questions

When people say "deploy my app," they are usually asking one of two very different questions. Mixing them up is the most common source of confusion, so it is worth separating them up front.

•Where does my app's UI run? This is a per-project choice you make from App Studio once you have generated an app: Supero Cloud, your own AWS account, or your own GCP project. It only decides which cloud serves the app's frontend. Authentication, data storage, business logic, and AI generation always stay on Supero's backend, no matter which one you pick.
•Do I want to self-host the whole Supero platform? This is a separate, much bigger decision — installing Supero itself (the API layer, the database, the admin console) on infrastructure you control, so nothing calls out to Supero at runtime. This is the on-premise path, and it is an Enterprise option most teams never need.

ℹ️ Most teams only answer question 1

If you are building and shipping apps on Supero, you almost certainly want the first decision: Supero Cloud, your own AWS, or your own GCP. The second decision — self-hosting the platform itself — is covered on On-Premise Deployment and generally only makes sense for air-gapped or strict data-residency requirements.

Where Your App's UI Can Run

Three targets answer question 1. All three run the same app against the same Supero backend — they differ in who builds the container, who hosts it, whose bill it lands on, and what the resulting URL looks like.

Target 1

Supero Cloud

One click. Supero builds and hosts the app at a live-{domain}-{project}.supero.live URL and pays the infrastructure bill. Nothing to connect. Publish your app

Target 2

Your own AWS

The UI container runs on ECS Express (Fargate) in your account, built by CodeBuild in your account. Connect once with a CloudFormation stack. Connect AWS

Target 3

Your own GCP

The UI container runs on Cloud Run in your project, built by Cloud Build in your project. Connect once with a setup script. Connect GCP

The fourth option — self-hosting the entire platform on your own hardware — answers question 2 and is covered separately on On-Premise Deployment.

Decision Matrix

A side-by-side view of all four options. The first three answer "where does my app UI run"; the fourth answers "do I self-host the platform."

Option	What actually deploys	Who builds it	Who bills for it	Works offline / air-gapped	Who manages upgrades
Supero Cloud	Your app, hosted at https://live-{domain}-{project}.supero.live	Supero — one click	Supero (counts toward your plan's live-deployment allowance)	No	Supero, automatically
Your AWS account	Only the app's UI container, on ECS Express (Fargate)	AWS CodeBuild, inside your account	You — your own AWS bill	No — the UI proxies /api and /ai to api.supero.dev	You trigger each redeploy; Supero orchestrates the build
Your GCP project	Only the app's UI container, on Cloud Run	Cloud Build, inside your project	You — your own GCP bill	No — the UI proxies /api and /ai to api.supero.dev	You trigger each redeploy; Supero orchestrates the build
Self-hosted platform (on-premise)	The Supero core platform, not just an app UI	You, on your own infrastructure	You — an Enterprise license, not usage-metered	Mostly — see the air-gap caveats on the on-premise page	You, on your own schedule

💡 App Runner is legacy on AWS

Every new AWS connection provisions ECS Express roles and deploys to ECS Express. Accounts that were connected earlier and are still on App Runner keep working, but new connections do not use it.

What Is Not Included

Three things are commonly assumed to exist and do not. Each is called out again on the page where it matters, but they belong in the decision itself.

🚨 Custom domains are not implemented on any target

You cannot point your own domain at a deployed app. There is no DNS automation, no certificate provisioning, and no domain-mapping step on Supero Cloud, on AWS, or on GCP. The address you get is the one the platform generates. The custom-domain fields you may see in workspace and tenant settings are tenant-routing text fields — their own help text says DNS is configured manually — and they do not change where a deployed app answers. If you need a branded address in front of an app, mail [email protected] and treat it as a manual arrangement, not a self-serve feature.

•No server-side deploy record on the customer-cloud path. An AWS or GCP deploy is tracked in your browser session. Close the tab mid-deploy and the build still completes in your account, but the panel loses track of it. Supero Cloud does keep a durable record.
•No app generation on-premise. App Studio, schema generation, UI generation, and deploy-to-your-own-cloud are all cloud-only. The generators are physically removed from the on-premise package, so there is no flag that turns them on.
•No Kubernetes or Helm path for customers. There is no Helm chart and no customer-facing Kubernetes manifest set for either the platform or a generated app.

What Actually Moves When You Deploy to Your Own Cloud

The AWS and GCP options are often called "bring your own cloud," which oversells how much actually moves. Only the app's UI container runs in your account — everything the app calls stays on Supero's backend.

text

Your users' browser --HTTPS--> UI container (your AWS or GCP account) --/api, /ai--> api.supero.dev
                                    |  serves the app UI          (auth, data, services, AI)
                                    +- built by CodeBuild/Cloud Build in your own account

•Data never leaves Supero. The container proxies /api and /ai calls back to api.supero.dev with a scoped, read-only key minted per deploy — no customer data is written into your cloud.
•No admin credential ships in the bundle. The deployed image carries only non-secret identifiers (which Supero project and tenant it points at) plus that scoped read key.
•End users sign in with their own accounts. The container forwards each visitor's own JWT to Supero — there is no shared service credential standing in for your users.
•The credential model differs by cloud, and the difference matters. On AWS, you create a scoped IAM user in a CloudFormation stack and hand Supero its access key, which Supero stores encrypted and reuses — a long-lived credential you can rotate or delete. On GCP, no key exists: Supero impersonates a deploy service account you grant it, minting one-hour tokens, and you cut it off by removing a single IAM binding.

💡 Teardown does not touch your data

Removing the deployment (from the deploy panel, or by deleting the ECS Express / Cloud Run service directly) only stops the running UI container and its cloud cost. Your app data stays in Supero either way.

Prerequisites for Your Own AWS or GCP

Deploying to your own cloud requires a small amount of one-time setup before your first click-to-deploy:

•A plan with a live-deployment allowance. Live deployments start at Starter — see Plans & Billing. A deploy attempted 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).
•An app that has already been generated in the project — at least one completed build, because the deploy ships a specific bundle.
•An AWS or GCP account you administer, with billing enabled — this is the account the UI container runs in and is billed to.
•The one-time Connect step, which is a single command: supero connect-aws or supero connect-gcp. Every deploy after that reuses the connection.

ℹ️ On build times

Build duration depends on your bundle and your cloud, and Supero does not publish a measured figure for the customer-cloud path. What is fixed is how long the panel waits: it polls for roughly 15 minutes before it stops tracking a deploy. On Supero Cloud the build itself is capped — 8 minutes for a web app, 15 minutes when mobile output is included.

When to Choose Each

•Fastest launch, no cloud account: Supero Cloud. One click, no setup, hosted by Supero, billed against your plan.
•You need the app billed to your own cloud account, running inside your own network boundary, with infrastructure logs and cost in your own console: your AWS or GCP. Connect once, then every redeploy is one click.
•Full data sovereignty or an air-gapped environment: the self-hosted platform (Enterprise on-premise). This is the only option where the backend itself runs on your infrastructure — on AWS and GCP the app still proxies to api.supero.dev.

Between AWS and GCP, the choice usually comes down to which cloud your organization already standardizes on and bills through. One practical difference: a GCP deploy keeps the same Cloud Run URL across redeploys, while an AWS deploy gets a fresh hostname every time — see Deploy to Your Own AWS or GCP.

Getting There

Every path starts from the same place: App Studio, on a project with at least one completed app build.

•Supero Cloud: open Go Live, choose Supero Cloud, confirm, and start the deploy. It runs asynchronously — the call returns immediately and the panel polls until the app is up, then shows the permanent URL. There is no expiry.
•Your AWS: choose Amazon AWS, run pip install --upgrade supero && supero connect-aws --region <region> in CloudShell (or launch the same CloudFormation template from the console), then paste back seven values from the stack outputs and deploy. Every deploy after that is one click.
•Your GCP: choose Google Cloud, run pip install --upgrade supero && supero connect-gcp --project-id <p> --external-id <from the wizard> in Cloud Shell, then paste back the six values it prints and deploy. Every deploy after that is one click.

⚠️ The dev/live build lock is a separate toggle

Publishing from the dashboard also flips the project from dev to live, which blocks destructive rebuilds while the app is serving. That flip is done by the dashboard, not by the deploy itself — if you publish through the API or an MCP tool, the project stays in dev and is not protected. Return the project to dev from the dashboard when you want to rebuild.

The full step-by-step for connecting AWS or GCP — including exactly what each setup step grants and how to troubleshoot a failed build — lives on Deploy to Your Own AWS or GCP, with a short pre-flight and post-deploy checklist on the Verification Runbook. The self-hosted platform install is a separate track on On-Premise Deployment.

Next Steps

•Publish Your App (Go Live / Supero Cloud) — the one-click path, including how preview and live differ and how long a preview lasts.
•Deploy to Your Own AWS or GCP — connecting AWS or GCP step by step, what each grant allows, cost, and teardown.
•Deploy to AWS / GCP — Verification Runbook — the short checklist to run before and after a customer-cloud deploy.
•On-Premise Deployment — self-hosting the platform for data-sovereignty or air-gapped requirements.
•Plans & Billing — how live deployments count against your plan.

← PreviousManaged Integrations & Provider Catalog Next →Publish Your App (Go Live / Supero Cloud)

On this page