To deploy a web app, you build it into static files, put them on a host that serves them over HTTPS, give the host the secrets the app needs, and point a domain name at it. With an AI builder you can stop at step one: the builder publishes the app for you. If you want a different host, export the code to GitHub and connect the repository to Vercel or Netlify, or run it on your own server.
This guide assumes an app with a Supabase backend, which is what Cadrant, our builder, generates. Prices of third-party hosts are not quoted: they change often, so check the vendors' pages.
The three ways to deploy an AI-built web app
There are three places to host the app: the builder's own hosting, a host such as Vercel or Netlify, or a server you manage. They differ mainly in how much you do yourself.
- The builder's hosting. You click Publish and the app goes online on a URL of the builder, or on your own domain. Nothing to configure beyond the domain. Your code stays inside the builder's pipeline.
- A host after a GitHub export. You push the code to a GitHub repository, connect the repository to a host, and the host builds and deploys at every push. You control the build settings and the environment variables.
- Your own server. You rent a virtual machine, install a web server, copy the built files, and manage the certificate and the updates. This gives the most control and the most work.
| Option | How the app goes online | What you manage yourself | Limits |
|---|---|---|---|
| Builder hosting (Cadrant) | Publish button, builder URL or your domain | The domain's DNS records, the Supabase project | Tied to the builder: leaving means exporting the code, which needs the Pro plan on Cadrant |
| Vercel or Netlify | Repository connected to the host, deploy on every push | Repository, build settings, environment variables, DNS, the host's plan | The host's plan limits apply, and the code is edited in two places unless the builder pushes to GitHub for you |
| Your own server | You copy the built files to a machine you run | Everything: server, web server, certificate renewal, security updates, backups, monitoring | Time. Worth it for compliance or special requirements, rarely for a first launch |
What deploying actually involves
Deploying is four things: a build, the configuration the app needs at runtime, a database that stays where it is, and an HTTPS certificate. The first and last are automatic on any modern host.
The build
A React app is written in files a browser cannot run directly. The build step compiles them into plain HTML, JavaScript and CSS files, usually in a folder named dist or build. The host runs the build command (often npm run build) and serves that folder.
Environment variables and secrets
There are two kinds of values, and mixing them is the most common launch mistake. Public values, such as the Supabase project URL and its public (anon) key, ship inside the app and are designed to be visible. Secret values, such as a Stripe secret key or an email provider key, must never be in the app's code or in any variable the build exposes to the browser. They belong on the server side.
In an app built with Cadrant, secrets live in the Environment tab of the Database panel and are read by Supabase edge functions, so they are never part of the frontend bundle. See the environment variables documentation. If you deploy elsewhere, the host asks you to re-enter only the public values; the secrets stay in Supabase. Vercel notes that each of its environments (preview, production) can have its own variables, which is how you keep test keys away from live ones.
The database stays on Supabase
Moving the frontend to another host does not move the data. The database, the user accounts and the files stay in the Supabase project, which sits in your own Supabase account. That is the reason a host change takes minutes and loses nothing. Two things to do after any change of address: add the new domain to the Auth settings, and test sign-in. Supabase's documentation says the Site URL, which defaults to localhost, should be changed to your production URL, and that the redirect URLs form an allow list that sign-in redirects must match. Left alone, confirmation and password-reset emails point to the wrong place. The details are in Supabase's redirect URLs guide.
The HTTPS certificate
Browsers warn users away from sites without HTTPS, and sign-in will not work properly without it. Vercel, Netlify and Cadrant issue and renew the certificate for you once the domain is verified. On your own server, you install and renew it yourself, usually with a free certificate authority tool, and you must remember to keep renewal working.
How to connect a custom domain
Connecting a domain means adding DNS records at the company where you manage the domain so that the name points to your host. Each host tells you the exact records; copy them exactly rather than from a tutorial.
- Buy the domain if you do not have one. For help picking a name and an extension, read how to choose a domain name extension.
- Add the domain in the host's settings. The host then shows the records to create.
- Create those records at your DNS provider (your registrar, Cloudflare and so on).
- Wait for the host to show the domain as verified, then open the site on the domain and test sign-in.
A record or CNAME
An A record points a name to an IP address, and a CNAME record points a name to another name. Vercel's documentation says an apex domain such as example.com is configured with an A record and a subdomain such as app.example.com with a CNAME record, and that each project has its own CNAME value. Netlify's documentation recommends, for the apex domain, an ALIAS record if your DNS provider supports it, and an A record otherwise, plus a CNAME for www. The values differ per host and per project, so use the ones shown in your dashboard.
Apex domain or www
The apex (or root) domain is example.com, with nothing in front. A subdomain is anything in front of it, such as www or app. A CNAME cannot sit on the apex in standard DNS, which is why apex setups use A, ALIAS or ANAME records. Netlify strongly recommends making a www subdomain your primary domain, because an apex primary can hurt performance with some DNS providers. Cadrant's own documentation gives the same advice: prefer a subdomain such as app.mysite.com to avoid the limits of root domains. Add both versions and redirect one to the other, so that visitors reach the app either way.
DNS propagation
A DNS change can take from a few minutes to a day or more to reach everyone. Netlify's documentation says to allow up to 48 hours. Check progress with a tool such as dnschecker.org or the dig command, and look for conflicting old records on the same name: an old A or CNAME record is the usual cause of a domain that never validates.
How Cadrant publishes
Cadrant publishes from the Publish button: you choose a slug for a Cadrant URL such as your-app.cadrant.app, or you select a custom domain you added in the Domains section. HTTPS hosting and a custom domain are included in every paid plan, and a published app does not consume credits.
For a custom domain, Cadrant shows three DNS records to create at your registrar: a TXT record that proves ownership, a CNAME that validates the certificate and lets it renew automatically, and a CNAME for routing. For a root domain, the routing record needs an ALIAS or ANAME if your provider supports it. Validation takes from a few minutes to a few hours; a Refresh button updates the status. Clicking Publish again replaces the live version, and you can unpublish at any time. The full steps are in the publishing documentation.
The limit to know: this is the builder's hosting. If you want your own host, the code export and GitHub push are on the Pro plan. Pricing is on the pricing page, and the builder itself is described on the AI app builder page.
Test on a staging copy before changing the live app
A staging copy is a second deployment of the app, with its own address and its own test data, where you check a change before real users see it. Once people depend on your app, test there first.
On a host, this is built in. Vercel creates a preview deployment, with its own URL, for each branch or pull request, and lets you assign a staging domain and separate environment variables. Its documentation states that preview deployments do not use your production variables, and that a production build can also be held until you promote it. Netlify offers similar deploy previews. The point of separate variables is a separate Supabase project for staging, so a test never touches real customers.
In a builder, the simplest staging copy is a duplicate project connected to a second Supabase project, published on a second subdomain such as staging.yourdomain.com. Change and test there, then repeat the change on the live project. It costs a project slot, and the two copies can drift apart, so keep the list of changes short. Apply database changes to staging first, and check the policies as explained in our guide to Supabase row level security.
How to roll back a bad deploy
Rolling back means returning the live app to the last version that worked, and it is only quick if the previous version was kept. Decide how you would do it before you need it.
- In Cadrant. Every prompt creates a new version, kept indefinitely. You can preview any past version and revert to it. Reverting does not delete later versions, so you can move forward again. After reverting, click Publish to put that version online. Reverting restores the app, not data already changed in the database. See the versioning documentation.
- On a host. Hosts keep previous deployments and can reassign the production domain to an older one, or you revert the commit in Git and let the host redeploy.
- On your own server. Keep the previous build folder next to the current one and switch back to it.
Pre-launch checklist
Before you tell anyone the app is live, check these ten points. Most launch problems are on this list.
For the security side in more depth, see our guide to vibe coding security. To compare what the app can do before you commit to a builder, start from the list of AI app builders.