Deploy Your First AI-Built App

An app running on your laptop is not yet a controlled release. Deployment introduces a different environment, external access, configuration, and responsibility for what happens after a change goes live.

Before choosing a hosting button, define what you are releasing, who can use it, and how you will detect and respond to failure.

Inventory the parts

Identify the frontend, server, database, storage, and any external services. A static prototype has different requirements from an app that holds private user records.

Record the build command, required runtime, configuration variables, and data dependencies. Use the current documentation for the actual hosting platform rather than assuming one provider's defaults apply everywhere.

Do not let an AI tool add a production service merely because it can generate the configuration.

Separate development, preview, and production

Use appropriate environments so testing does not accidentally modify live information. Keep preview access limited when the app is unfinished or contains sensitive material.

If your deployment platform supports environments and approval controls, configure them deliberately. GitHub Actions, for example, supports environment-based deployment workflows; available controls depend on the account and setup.

Confirm which environment a command or automated job targets before it runs.

Keep secrets out of browser code

A variable does not become secret because it is called an environment variable. Values included in frontend bundles can be visible to people using the application.

Privileged keys belong in an appropriate server-side environment or secret-management mechanism. The browser should call a server endpoint that enforces identity, authorization, input limits, and appropriate usage controls.

Use separate credentials where needed, restrict their scope, and plan rotation. If a secret was exposed, removing it from the visible file is not enough; revoke or rotate it through the relevant service and inspect the exposure.

Verify the deployed behavior

Run checks against the actual deployed environment with disposable test data. Confirm that the main workflow works, invalid requests are rejected, and separate users cannot access each other's private records.

Check configuration-dependent behavior such as callback addresses, file access, and permitted origins where applicable. A local success does not establish that those values are correct after deployment.

Confirm that failures produce understandable feedback without exposing credentials or private internal details.

Plan database changes explicitly

A release that changes data structure needs more than a code upload. Determine migration order, compatibility, and the effect on existing information.

Use backups and a tested recovery approach appropriate to the data. Rolling the application back does not necessarily reverse a database migration safely.