How to Deploy an App Built With AI Step-by-Step

A live app should do more than load its homepage. It should run with the right configuration, protect its data, and let you verify the flows people will use. To deploy an app built with AI, start with a working version you can run yourself, access to its code, and an account with the hosting service you intend to use. Follow these steps before sharing the live address.

Your AI coding tool can help investigate errors along the way. Keep the final decisions about credentials, permissions, and release timing in your hands.

Step 1: Review the code you are about to release

Open the changes since the last version you tested. Look beyond the feature you requested. AI-generated edits can touch configuration, dependencies, shared components, or database access while solving a seemingly small task. Ask the tool to explain unfamiliar changes, then check its explanation against the diff rather than accepting the summary alone.

For a fuller review of unexpected changes, use this checklist for reviewing AI-generated code before shipping.

Pay particular attention to authentication, data writes, and destructive actions. Make sure no credentials have been copied into source files. When you can describe the important changes and the app runs in your development environment, you have a sensible release candidate.

Step 2: Configure the live environment

Set the environment variables the app needs in your hosting service's configuration. Database connection details, API credentials, and application secrets belong there rather than in committed code. An app that works locally can fail after deployment because its live environment has different values or lacks a required variable.

Use the host's documentation for its configuration process and double-check which environment each value applies to. Keep secret values out of prompts and screenshots you share. A successful build is encouraging, but it does not prove the app can connect to the services it uses. You will check those connections through the live flows later.

Step 3: Back up the data the release could affect

If the app writes to a database or stores uploaded files, make a backup before a release that could change them. A rollback of the code may not reverse a database migration or restore a deleted record. Check that you know where the backup lives and how you would restore it before making the live change.

For a new app with no user data, record that there is nothing to preserve yet. This step still prompts you to notice whether a test database, a production database, or an external storage service is involved. It is much easier to make that distinction before an AI-generated migration runs.

Step 4: Deploy the reviewed version

Use your hosting service's deployment flow to publish the version you just reviewed. Point it at the intended code revision and environment, then watch the build output and runtime logs. If the build fails, work from the specific error instead of asking an agent to rewrite the deployment setup broadly.

When requesting help, share a sanitized error message and identify what command or deployment stage failed. Never paste a secret to provide context. Once the service reports a successful release and gives you a live address, move on to behavior testing. A green build only confirms that the build completed.

Step 5: Test the live app as a user

Open the live address in a fresh browser session. Try the main path, then a failure path. For a small SaaS app, that might mean creating an account, signing in, saving a record, refreshing the page, and checking that another account cannot access it. Test a destructive action with safe test data before real users depend on it.

Watch the logs while you test. If something fails, note the exact action, the result you saw, and the relevant error without exposing private data. Fix and redeploy the specific issue, then repeat the affected test. Share the address only when the flows you intend people to use behave as expected. If you plan to use your own domain, connect it only after these tests pass on the host-provided address.

Leave yourself a release note

Record the code revision, the flows you tested, any unresolved issues, and how you would return to the previous version. Your future self needs a recovery path more than a transcript of every prompt. This is especially useful when you return after a few days and cannot remember whether a failing screen was tested before release.

Keep your release notes and next actions in VibeCrumbs so you can resume the build without reconstructing the deployment from chat history.