How GitHub Auto-Deploy Works

GitHub auto-deploy connects your repository to a hosting platform so new code can be built and published automatically after you push an update. Your live site changes only after the deployment process succeeds.

What happens after you push to GitHub?

1. You change your project and commit the update. The commit records a new version of your code in Git.
2. You push the new commit to the connected GitHub repository — to the branch your hosting platform deploys from, usually main.
3. The connected hosting platform detects that the repository has a new revision and starts a deployment.
4. It prepares or builds the new deployment: installing dependencies, running the build or preparing the server code — whatever your project needs.
5. If every step succeeds, the new version becomes ready. If one fails, the deployment stops there, and a failed build never becomes your live website.
6. The live website begins serving the new deployment. Pushing alone never changed it — this is the moment it does.

The main pieces

Your project — The website or web app on your computer, where you make and test changes. It can be React, Next.js, a Node.js app, a static site or anything else — the workflow is the same. A change here is invisible to everyone else until it is committed, pushed and deployed.

Commit & push — Two separate steps. A commit records a version of your code in Git, on your own computer: which files changed, with a short message. A push sends your new commits to the remote repository on GitHub. Until you push, the hosting platform has nothing new to see.

GitHub repository — The remote copy of your project, with its full history — every commit, on every branch. In this workflow it is the source your hosting platform watches and takes the code from. It stores and versions your code; it does not run your live website, so receiving your push is where its part ends.

Hosting platform — The service connected to your repository. When a new revision arrives on the branch it deploys from, it detects the update through its Git integration and starts a new deployment. It is also what runs and serves your live website — the part GitHub does not do. Hosting providers such as Hostinger can deploy from a connected GitHub repository; the idea is the same on any platform that supports it.

Install & build — The platform prepares the new version: it installs the project's dependencies, runs the build, produces the files to serve or prepares the server code to start, and reads the production configuration. The exact steps depend on your project and its settings. If one of them fails, the deployment stops here.

New deployment — The result of one successful build: a complete version of your site, tied to the commit it came from. Each deployed push creates a new one, and most platforms list them with a status — so this is where you check whether an update worked. Only a deployment that is ready goes live.

Current live site — The version your visitors are getting right now, from the last successful deployment. Pushing to GitHub doesn't change it, and neither does a build that is still running. If the new deployment fails, it does not become the live version, and on most platforms this one simply stays in place.

Updated live site — Your site at its public address, now serving the new deployment. This is the only point where the update reaches visitors — not the push, and not the build. Exactly how the switch happens depends on the platform, and a browser or cache can show an older copy for a while, so reload before deciding nothing changed.

Does GitHub host my website?

In this workflow, no. GitHub stores your code and keeps its history — every commit, on every branch. It is the source your hosting platform watches and takes the code from.

The hosting platform does the publishing. It builds or starts your project and serves the live website to visitors, which is why a push that reached GitHub has not, on its own, changed your site.

GitHub does offer hosting for some cases — GitHub Pages can publish a static site, for example. That is a separate product, and not what this workflow uses.

In a Git-connected deployment workflow, GitHub is the code source and the hosting platform serves the production application.

What triggers an automatic deployment?

Once a repository and a branch are connected, the hosting platform watches that branch for new revisions through its Git integration. When a new commit lands on it, the platform can start a deployment automatically.

How it finds out depends on the platform. Some are notified by GitHub the moment you push — through a webhook or an installed app — and others check the repository for changes. Connecting the repository sets this up; you don't build it yourself.

The platform normally watches the branch you connected for production, usually main. A push to a different branch may not update your live site at all, although some platforms build other branches as separate previews.

What happens during the build?

It depends on the project. Depending on what you built, the platform may install the project's dependencies, run a build command, produce static files, prepare and start server code, and load your production environment configuration.

A static site may only need its files built. A Node.js or Next.js app usually also needs a server process started. Not every project goes through the same steps — the platform follows the build and start settings configured for your project.

Why did my push succeed but my website not update?

Because a successful push only proves that GitHub received your code. Your website changes only after a deployment finishes, and several things can stop that.

Common causes: the deployment or build failed; you pushed to a branch the platform doesn't deploy from; an environment variable or setting is missing; the build or start settings are wrong; auto-deploy isn't connected or is switched off; or the deployment worked and you are seeing an older cached copy of the page.

Start with your hosting platform's list of deployments: it shows whether your push started one, and its log shows where it stopped. Some platforms also keep previous deployments, so you can restore an earlier working version while you fix the problem.

Where do environment variables fit?

A deployment often needs production values that are not in your code — API keys, database connection details, your site's own URL. Those normally live in the hosting platform's environment settings, where the build or the running app reads them.

They are not meant to be committed to your repository so the deployment can find them: anything in GitHub becomes part of your code's history. And after you change one, many platforms need a new deployment before the change takes effect.

Auto-deploy or manual deploy?

With auto-deploy, updating the repository starts a new deployment: push to the connected branch, and the hosting platform builds and releases the new version by itself. With a manual deploy, someone starts it on purpose — uploading files, pressing a deploy button, or redeploying from the dashboard.

Neither is right for every workflow. For a web project you update often, Git-connected auto-deploy is convenient because your code and your deployments stay connected. The trade-off is that anything pushed to that branch goes live, so push only changes that are ready.