How to Deploy a Vibe-Coded App From GitHub

Once your AI-built app is in GitHub, you can deploy it by connecting the repository to a hosting provider. The host builds a selected branch and publishes the result, often redeploying automatically after each push. This guide covers the steps that apply across platforms—preparing the repo, configuring the build, handling environment variables, and checking the live app.

1. Prepare and push a working project to GitHub

Before deployment, run the app locally and check that it builds. Review the files you plan to publish; do not commit credentials, private keys, or local environment files. A basic final check is:

git status --short
git diff --check
git diff

Commit the reviewed changes and push the branch you intend to deploy. If the project is not in GitHub yet, follow this guide to upload your project to GitHub.

2. Connect the repository to a hosting provider

In your chosen hosting provider, start a new project and authorize access to the GitHub repository. Select the correct repository and production branch—commonly main, but use the branch your project actually maintains. Confirm the repository is private or public as intended and grant only the access the provider needs.

Many hosts detect popular frameworks automatically. Review the detected framework, root directory, build command, and output directory against the project's files and framework documentation. Do not copy settings from a different stack; for example, a static site and a server-rendered app may need different build and runtime configuration.

3. Add required environment variables securely

If the app depends on environment variables, add the required production values in the host's project settings or approved secret manager. Use the exact variable names expected by the app, and configure values for the correct environment. Keep real secret values out of GitHub, source code, build logs, and screenshots.

Client-side environment variables are not private just because they are called variables: values bundled into browser code can be read by visitors. Only use client-exposed values for data intended to be public; keep privileged API credentials on the server. If a key was exposed, revoke or rotate it first. See how to respond to an API key exposed on GitHub.

4. Deploy and read the build output

Trigger the first deployment and wait for the build to finish. A successful deployment should identify the commit it built and provide a live URL. If the build fails, read the first actionable error in the build output, confirm required variables and runtime versions, then fix the project or settings and push a reviewed change. Avoid hiding errors by disabling checks without understanding them.

If the app needs a database, storage, scheduled jobs, or a backend API, configure those services and their network access separately. A successful frontend build alone does not mean these dependencies are set up for production.

5. Verify the production app

• Open the production URL in a fresh browser session.
• Test the main user flows, not only the home page.
• Check browser and server logs for runtime or configuration errors.
• Confirm forms and API requests reach the intended production services.
• Verify the deployed commit matches the branch and code you reviewed.

Once deployment is connected, later pushes to the production branch may deploy automatically. Review and test changes before pushing, and use pull requests or preview deployments when available so experiments do not go directly to production.

Keep a recovery path

Keep Git commits small and make a checkpoint before substantial AI edits. If an update breaks production, the hosting provider may let you restore a prior deployment while you repair the source branch. Learn how to restore a previous version of your app without confusing a deployment rollback with a Git history change.