How to deploy from GitHub

To deploy from GitHub, prepare your application repository for production, connect it to a hosting platform, select the branch you want to publish, and configure the platform’s build settings for deployment.

We’ll use Hostinger Web Apps Hosting to put this process into practice with a React and Vite application, from connecting the repository to getting the app live and keeping it updated through GitHub.

1. Prepare your GitHub repository

First, run the application locally and test its main functionality. A working local version makes deployment problems easier to isolate. An error that already appears locally isn’t caused by the hosting environment.

Next, check that your project includes the configuration files required by its framework. Our React project uses Vite and includes a package.json file that defines its dependencies and available scripts.

Make sure package.json includes the production build script your application needs. Before pushing the project to GitHub, run the production build locally to check that the application compiles successfully. For our Vite project, use:

npm run build

A successful build should generate a dist directory containing the production files. If the command fails, resolve the reported errors before continuing with deployment.

Hostinger doesn’t let you type a build command. Instead, you select it from a dropdown of the scripts defined in this file, so you can’t select a script that isn’t there.

In our Vite project, the relevant script is:

"scripts": {
  "build": "vite build"
}

This makes npm run build available as the build command when configuring the application on Hostinger.

For a project that isn’t already tracked with Git, open its directory in the terminal and initialize a repository:

git init

Before staging the project files, open the .gitignore file in the project’s root directory. Check that it lists files and directories Git shouldn’t track.

In our Vite project, node_modules is already listed in .gitignore, so locally installed dependencies won’t be added to the repository.

The entries you need depend on your framework and development environment. Many project setup tools automatically create a .gitignore file. Create a file named .gitignore in the project’s root directory if your project doesn’t include one.

Place it alongside files such as package.json, and list each file or directory Git should ignore on a separate line:

node_modules/
dist/
.env
.env.*
!.env.example

Check your framework’s documentation for its recommended exclusions before committing the project.

Keep sensitive values such as API keys and credentials out of the repository as well. You’ll add the values the deployed application needs as environment variables during deployment.

Once you’ve confirmed which files Git will include, stage the project and create a commit:

git add .
git commit -m "Initial commit"

This commit is the version you’ll push to GitHub. As you update the application, managing commits, branches, and remote repositories becomes part of your regular workflow.

Next, create an empty repository on GitHub. Don’t initialize it with files such as README.md or .gitignore if those files already exist in your local project.

Connect your local repository to the GitHub repository:

git remote add origin https://github.com/USERNAME/REPOSITORY.git

Replace USERNAME and REPOSITORY with your GitHub username and repository name.

Push the branch containing the production-ready application to GitHub. For the main branch, run:

git push -u origin main

Your branch may be named master or something else. Check the name with git branch, then replace main in the command above with your branch name.

Remember which branch you push because you’ll select it as the production branch when configuring the deployment.

When you run git push with an HTTPS GitHub URL, GitHub asks you to verify your identity. You can’t use your normal GitHub password for this. Authenticate with a supported method instead, such as a personal access token (PAT).

Finally, open the repository on GitHub and confirm that the latest project files are present.

2. Choose a deployment method

Choose a deployment method that supports your application’s framework, runtime, and resource requirements.

For this tutorial, we’ll use Hostinger Web Apps Hosting to deploy the application directly from its GitHub repository. Hostinger retrieves the code, builds the application, and runs it on managed infrastructure, so you don’t need to configure a server or create a custom continuous integration and continuous deployment (CI/CD) pipeline.

Applications that run server-side code require a specific runtime and often additional server resources. Account for these needs when choosing the right environment for your app.

3. Connect your GitHub repository to Hostinger

In the Hostinger dashboard, go to Websites → Web Apps. This opens the Web Apps deployment area, where you can connect a GitHub or GitLab repository or upload the application as a ZIP file.

For a GitHub deployment, click Get started.

Before connecting the repository, choose the web address you’ll use to access the deployed app.

You can use a domain you already own or enter a new one. Select Use temporary domain if you’re not ready to connect a domain. This gives the app a Hostinger-provided address so you can deploy and test it first, then connect your own domain later.

Next, choose how Hostinger should access the application code. Since our project is already on GitHub, we’ll select Continue with GitHub.

Connecting the account gives Hostinger access to the repositories you authorize and sets up the connection used for future deployments.

You can also enter the GitHub URL directly without connecting an account if the repository is public. We’ll use the account connection to test automatic deployment when new changes are pushed to GitHub.

After connecting to GitHub, select the repository that contains the application you want to deploy.

4. Configure the deployment settings

Review the deployment settings Hostinger detects from your repository, starting with the framework and branch. The branch should contain the version of the application you want to publish.

In our case, Hostinger correctly detected Vite and selected the main branch. It also selected Node.js 22, the default version, and set the repository root (./) as the application directory.

For our project, Hostinger detected npm run build as the build command and dist as the output directory. Build commands are taken from the scripts in package.json, so the command you need must be defined there.

These settings match our Vite project, so we can keep them unchanged. A different React setup may use another command or output directory, so confirm the detected values against your project when configuring a React production build.

The settings also vary depending on the type of application you’re deploying. Front-end applications typically use a build command and output directory, while back-end applications require an entry file that Hostinger uses to start the application. Full-stack applications, such as Nuxt, use both.

A Node.js back end, for instance, might use src/server.js as its entry file, so verify how your application starts when preparing a Node.js project for production.

Next, review the environment variables Hostinger detected in the project. Variables that don’t yet have a value are marked Action required, so you’ll need to complete them before deploying. Enter the values individually or use Import .env to import them from a .env file.

Hostinger accepts environment variable names containing uppercase letters, numbers, and underscores. For example, VITE_API_BASE_URL is a valid variable name for a Vite application, while API_KEY is a valid name for a server-side variable. Rename any variables that don’t follow Hostinger’s naming requirements before deploying.

For our React and Vite project, variables accessed in the frontend through import.meta.env must use the VITE_ prefix by default. For example, VITE_API_BASE_URL can store the public URL of an API that the application needs to contact.

Never store secrets in variables prefixed with VITE_. Vite includes these values in the production JavaScript bundle, making them accessible to visitors. Private API keys, database passwords, and authentication secrets must remain on the server side. If your frontend needs to access a service that requires a private key, handle that request through a secure backend instead of exposing the key in browser code.

These precautions are an important part of protecting sensitive application data when deploying a web application.

5. Deploy the application and review the build logs

Review the configuration one last time, then click Deploy. Hostinger builds the application from the selected GitHub branch and publishes it to the domain shown at the top of the page. A message tells you it’s safe to leave the page if the build takes longer than expected.

When the process finishes, the Deployment completed screen confirms that the app is live and displays its address as the App at Hostinger link.

Expand Build logs to see what happened during the deployment. In our case, the log confirms that the build completed, the generated files were published, and the deployment finished successfully.

Find the first error in the build log if a deployment fails. It shows which stage caused the failure.

Select Settings and redeploy, correct the setting responsible for the error, and click Save and redeploy. This runs the deployment again without repeating the initial setup.

6. Test the deployed application

Once the deployment completes, open the app from its App at Hostinger link and test its main functionality.

Our deployed TaskFlow task management app loaded correctly, and its interactive features worked as expected. We added a new task, marked another as completed, and confirmed that the task counters updated accordingly.

When checking the app before making it public, repeat the same workflows you tested locally. This helps reveal production-specific problems, such as failed API requests, missing environment variables, or assets that don’t load correctly.

A successful build doesn’t always mean the application runs correctly. Open Runtime logs in the website dashboard if the deployment completes, but the app crashes or fails to start.

Use the error messages to identify the failing part of the application, such as a missing environment variable or an incorrect entry file. Correct the problem, redeploy the application, and test the affected functionality again.

7. Verify automatic redeployment from GitHub

After the initial deployment, changes pushed to the connected production branch automatically trigger a new deployment. To verify this, make a visible change to your application and test it locally before committing it.

We’ll change the main heading in our TaskFlow app from Keep your work moving. to Plan today. Make progress. This gives us a clear change to look for on the live site after the next deployment.

Once your change works locally, commit it and push it to the production branch connected to Hostinger. We’ll push our heading update to main:

git add .
git commit -m "Update dashboard heading"
git push origin main

Hostinger detects the new commit and automatically starts another deployment. You can follow its progress in the Web Apps dashboard, where the latest deployment shows the branch, commit, and deployment status.

After the deployment reaches Completed, open the live application.

Our TaskFlow heading now shows Plan today. Make progress., confirming that the GitHub update reached the live application without a manual redeployment.

Other ways to deploy from GitHub

GitHub Pages publishes static files directly from a repository, GitHub Actions runs a custom deployment workflow you define, and Hostinger Connector offers an optional alternative for deploying through an AI coding assistant.

GitHub Pages deployment

GitHub Pages deploys static site files directly from a GitHub repository. In your repository’s Settings → Pages, select Deploy from a branch, then choose the branch and folder containing the files you want to publish.

GitHub Pages hosts static files, making it suitable for portfolios, documentation, and simple HTML websites. It doesn’t provide the server-side runtime needed by backend applications.

For projects built with Vite or another framework requiring compilation, you must publish the generated production files rather than the original source code. You can use GitHub Actions to run the build and deploy the output directory, such as dist, to GitHub Pages.

GitHub Actions deployment

GitHub Actions gives you control over the steps that run between pushing code and deploying it.

Create a workflow file in .github/workflows and define its trigger and jobs. Use the workflow to run tests or build commands first, then start the deployment only after those jobs succeed.

In our example, pushing a commit to main triggered a workflow with two jobs. The test job ran first, and the deploy job started only after it succeeded.

The workflow run shows the status of each job, making it easier to see where a deployment succeeds or fails.

Hostinger Connector deployment

Hostinger Connector brings deployment into a supported AI coding assistant, so you can deploy the project you’re working on directly from your development environment.

After installing the Connector in VS Code, connect your Hostinger account through OAuth. This gives the coding assistant access to the Hostinger tools you authorize for deployment and other hosting operations.

Deployment then starts with a prompt. We asked GitHub Copilot to deploy the project in our current workspace as a new web application with a temporary domain.

We didn’t have to configure the deployment in the Hostinger dashboard or write a deployment workflow. Copilot prepared the project and used Hostinger Connector to create the site, with VS Code asking us to approve the Hostinger tools it needed along the way.

Once the deployment finished, Copilot returned the new hostingersite.com address in the chat and verified that the live page returned an HTTP 200 response with the expected content.

Connect a custom domain to your web app

To replace the temporary Hostinger address, open your web app in the Hostinger dashboard and click Connect domain.

Enter the domain you want to use and complete the connection. The exact process for connecting a custom domain to your web app depends on where the domain and its DNS are managed. Domains hosted outside Hostinger may require additional DNS changes.

Once the domain is connected, open the new URL and test the application again before sharing it with users.

This article is a localized version of How to deploy from GitHub, originally published in English.

All of the tutorial content on this website is subject to Hostinger's rigorous editorial standards and values.

The author

Ksenija Drobac Ristovic

Add Hostinger as a preferred source on Google

Ksenija is a digital marketing enthusiast with extensive expertise in content creation and website optimization. Specializing in WordPress, she enjoys writing about the platform’s nuances, from design to functionality, and sharing her insights with others. When she’s not perfecting her trade, you’ll find her on the local basketball court or at home enjoying a crime story. Follow her on LinkedIn.

More from Ksenija Drobac Ristovic