Documentation: deploying a Next.js application with GitHub + Hostinger

The goal of this setup is that every change to the code gets published to the site on its own, with no manual file upload. The flow is this:

Your computer (code) ──git push──> GitHub (stores the code) ──automatic deploy──> Hostinger (runs the site)

1. You edit the code on your computer (VS Code).
2. You send the changes to GitHub with the git push command.
3. Hostinger detects the push on its own, recompiles the project and updates the live site (2 to 5 minutes).

You never have to touch the Hostinger panel to update the site.

Where each thing happens

• Git installed on the computer. Check with git --version in the terminal. If it is missing, download it at https://git-scm.com/downloads.
• A GitHub account (github.com).
• A Hostinger plan with Web Apps / Node.js support. In our case, the Cloud Startup plan, which includes 10 Web Apps and supports Next.js with Node.js 18.x, 20.x, 22.x and 24.x. The more basic shared plans lack that feature.
• A Next.js project working on your machine (it runs with npm run dev).

Done once, before anything else.

3.1 Check whether Git is installed

git --version

• Expected answer: something like git version 2.43.0.
• If "git is not recognized" appears: install Git and reopen VS Code.

3.2 Check whether the project already has Git initialized

git status

• A list of files appeared (or "nothing to commit") → Git already exists in the folder. Skip git init.
• fatal: not a git repository appeared → run git init in Step 5.

How to know whether create-next-app generated the project: open package.json and check whether "next" exists inside "dependencies". Another sign: the default create-next-app .gitignore (with # next.js, # vercel sections and so on).

3.3 Identify yourself to Git (done once per computer)

Git stamps each change with a name and an email:

git config --global user.name "Your Name"
git config --global user.email "youremail@example.com"

Use the same email as the GitHub account. No confirmation message appears; if no error came up, it worked.

4.1 The .gitignore file

.gitignore is a list of files that should NOT go to GitHub. It exists for two reasons:

1. Security: .env files hold passwords and secret keys. They cannot sit exposed in the repository.
2. Size and necessity: folders such as node_modules (libraries) and .next (the build result) get generated on their own. Hostinger recreates both on the server.

create-next-app generates the file ready to go. The minimum content required:

# dependencies
/node_modules

# next.js
/.next/
/out/

# production
/build

# env files
.env*

# debug
npm-debug.log*
yarn-debug.log*
yarn-error.log*

# misc
.DS_Store
*.pem
.vercel
*.tsbuildinfo
next-env.d.ts

Note: the .env* line blocks any file starting with .env, an eventual .env.example included. If one day the team wants to version a template file (with no real passwords), adding !.env.example to .gitignore is enough (the ! means "except this one").

4.2 Check package.json

Hostinger uses the package.json scripts to install, compile and start the site. Confirm these exist:

"scripts": {
  "dev": "next dev",
  "build": "next build",
  "start": "next start"
}

Also make sure next, react and react-dom sit in dependencies (not in devDependencies).

4.3 Test the production build on your machine

npm run build

This command compiles the project the same way Hostinger will compile it. If it fails on your machine, it will fail on deploy. The npm run dev mode tolerates errors (types, ESLint, dynamic pages) that the production build forgives in no way. Fix any error before moving on.

A repository is the "project folder in the cloud", with the history of every change.

1. Go to https://github.com and log in.
2. Click the + in the top right corner → New repository.
3. Fill in: - Repository name: a name with no spaces and no accents (in our case, zumkai). - Visibility: Private 🔒 (you alone see the code; Hostinger reaches it anyway, because it gets authorized later). - Check NOTHING under "Initialize this repository with" (no README, no .gitignore, no license). Reason: the project already exists on the computer; if GitHub creates files on its own, the first push hits an "unrelated histories" conflict.
4. Click Create repository.
5. On the "Quick setup" page that opens, copy the URL of the repository (leave the HTTPS option selected):

https://github.com/sergioarantes/zumkai.git

Commands run one at a time, with Enter after each.

6.1 git init (only if needed)

git init

It turns the folder into a Git project. Skip it if the git status from Step 0 already worked (our case).

6.2 Stage every file

git add .

Translation: "Git, stage EVERY file in the folder for saving" (the dot means "everything"). The files listed in .gitignore get ignored on their own. This command shows no response, and silence is success.

6.3 Save a "snapshot" of the project

git commit -m "First version of the project"

It saves the project's current state with the description in quotes. Each commit is a point in the history you can return to. The answer shows a summary, along the lines of 5 files changed, 28 insertions(+).

6.4 Rename the main branch to main

git branch -M main

GitHub's current default is main; older projects use master. Run it even if it is already called main (it does no harm).

6.5 Connect the folder to the GitHub repository

First, check whether a connection already exists:

git remote -v

• Nothing appears → connect with the URL copied in Step 2:

git remote add origin https://github.com/sergioarantes/zumkai.git

• A wrong URL already appears → correct it with:

git remote set-url origin https://github.com/sergioarantes/zumkai.git

Translation: "this project's remote address, nicknamed origin, is this one".

6.6 Send it for real (the first push)

git push -u origin main

• The first time, a window or browser opens asking for a GitHub login → click Sign in with your browser and authorize. It stops asking after that.
• The -u origin main is necessary on the first push alone; after that, git push suffices.

Success output (a real example from our deploy):

Writing objects: 100% (845/845), 4.52 MiB | 3.01 MiB/s, done.
To https://github.com/sergioarantes/zumkai.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

6.7 Check on the GitHub site

Open the repository page and press F5. Verify:

• ✅ The project files appear
• ✅ node_modules/ is NOT there
• ✅ .next/ is NOT there
• ✅ No .env file is there
• ✅ .claude/settings.local.json is NOT there

Configuration done once.

7.1 Start the deploy

1. Go to https://hpanel.hostinger.com and log in.
2. Side menu → Websites → the + Add Website button.
3. Choose Deploy Web App ("Deploy your app from GitHub or upload files").

7.2 Connect GitHub

1. Choose the option to import via GitHub (not "upload files").
2. GitHub opens asking for authorization → click Authorize. - If it asks between "All repositories" and "Only select repositories", choose Only select repositories and check the project repository alone (safer).
3. Back in Hostinger, select the repository (zumkai) and the branch (main).

7.3 Review the build settings

Hostinger detects the framework on its own. The configuration used in our deploy:

7.4 Environment variables

• If the project has NO .env file (our case) → fill in nothing in this section.
• If the project HAS a .env with content → register each line in the Environment variables section (Add): what comes before the = is the Name, what comes after is the Value. It is necessary because .gitignore prevents (on purpose) the .env from going to GitHub, so Hostinger knows none of those values.
• Careful: NEXT_PUBLIC_* variables get baked in at build time. If you change one in the panel, firing a new deploy is necessary for it to take effect.

7.5 Run the deploy

1. Click the Deploy → button.
2. Follow the log (install → build → start). It takes 2 to 5 minutes. Leave the page open.
3. At the end, "Deployment completed!" appears with a preview of the live site.
4. The domain (zumkai.com) already points at the application.

From here on, every push to the main branch updates the site on its own. Hostinger detects it, recompiles and publishes without help.

8.1 The 3 commands for every update

git add .
git commit -m "describe here what changed"
git push

The one-line version (the && runs the next command only if the previous one succeeded):

git add . && git commit -m "describe here what changed" && git push

8.2 Recommended routine before each push

1. npm run dev → test the change in the local browser.
2. npm run build → confirm it compiles with no error (what fails here fails on deploy).
3. git status → check what is about to get sent. git add . takes everything changed in the folder, not the last file you touched alone.
4. git add . → git commit -m "..." → git push.

8.3 How to follow a deploy

In hPanel → the Web App dashboard → the Deployments area: it shows each deploy with its status (In progress / Completed / Failed), branch, commit and date. Clicking a deploy opens the full log.

8.4 How to check whether the site updated

Open the site and reload ignoring the cache: Ctrl + Shift + R. For a 100% clean test, use an incognito window (Ctrl + Shift + N).

The deploy failed on Hostinger (status "Failed")

Open the deploy log in the Deployments area. The most common causes:

1. A build error → reproduce it on your machine with npm run build and fix it. It is cause number 1.
2. A missing environment variable → register it in the panel and redeploy.
3. A dependency in devDependencies that belongs in dependencies in package.json (the production build installs no devDependencies).

The site failed to update after the push

1. Check on GitHub whether the commit arrived (the repository page shows "X minutes ago").
2. Check the Deployments area in hPanel (the deploy may be in progress or may have failed).
3. Reload with Ctrl + Shift + R (browser cache is a frequent cause of "nothing changed").
4. If the site updated and came out unstyled or broken, see the CDN case below.

The site appears "broken" or unstyled after a deploy (⚠️ a real case that happened in this project)

Symptom: right after a push or deploy, the site loads the "naked" content alone: text and links appear, with no colors, fonts or layout. Ctrl + Shift + R fails to solve it.

Cause: a version mismatch caused by Hostinger's CDN cache. It works like this: on each build, Next.js generates the CSS and JS files with unique names (for example, 3z2vuf_k-6jbb.css) that change on every compilation. The CDN (the network that keeps copies of the site to deliver it faster) can keep serving the old version's HTML, which asks for files with old names, and those files no longer exist on the server. Result: 404 errors and an unstyled site. Ctrl + Shift + R fails to solve it because it clears the browser's cache, not the server's or CDN's.

How to confirm the diagnosis (2 minutes):

1. Open the site in Chrome and press F12 (developer tools).
2. Go to the Console tab (or Network and reload with Ctrl + R).
3. If errors like these appear, this is the problem:

GET https://yoursite.com/_next/static/chunks/xxxxx.css  404 (Not Found)
GET https://yoursite.com/_next/static/chunks/xxxxx.js   404 (Not Found)

Checking the deploy log in Deployments also pays off: in this scenario it appears Completed, with Compiled successfully, meaning the code is healthy and the problem is cache alone.

Solution (in order):

1. Redeploy: in the Web App panel, click the Redeploy button and wait for it to finish. That republishes the HTML and the static files of the same version.
2. Clear the CDN cache: in hPanel, go to Websites → [your site] → Performance → CDN and click Flush cache.
3. Wait 1 to 2 minutes and test in an incognito window (Ctrl + Shift + N), which guarantees zero interference from the browser cache.

Notes about the CDN screen: the Development mode button switches the CDN cache off for a few hours (useful during stretches of repeated testing); Disable turns the CDN off for good (not recommended, since it speeds the site up). The yellow Console warning about "resource was preloaded using link preload" is harmless and disappears alongside once the 404s get resolved.

Vulnerabilities detected by Hostinger (⚠️ a real case that happened in this project)

Symptom: the Websites → [site] → Security → Vulnerabilities panel shows vulnerabilities with a "Requires manual patching" warning, listing packages (for example, postcss, sharp), severity and the fixed version.

What it means: it is neither an intrusion nor an error in your code. They are flaws discovered in third-party libraries the project uses. The fixes already exist in newer versions; "manual patching" means "update the versions in your project" and nothing more. The fix happens in the terminal, and the automatic deploy carries it to the server.

The fix, step by step:

1. Make sure every change sits in a commit (git status), so you can back out with ease if something goes wrong.
2. See the vulnerabilities on your machine:

npm audit

It is the same database Hostinger uses. Note the packages and the target versions.

3. Try the safe automatic fix:

npm audit fix

If npm audit comes back clean after that, skip to step 6.

4. Find out whether the vulnerable package is a direct dependency or a "hitchhiker":

npm ls package-name

The command shows the tree. A real case from this project: postcss@8.4.31 and sharp@0.34.5 appeared inside next@16.2.11, meaning they were no direct dependencies and came along for the ride with Next.

5. Update the right way, according to the case:

• A direct dependency (it appears in package.json) → update it in place:

npm install package-name@^fixed-version

• A "hitchhiker" dependency (it appears nowhere in package.json) → add an overrides block to package.json, at the same level as dependencies (never inside it), and run npm install. A real example used in this project:

"overrides": {
  "postcss": "^8.5.12",
  "sharp": "^0.35.0"
}

overrides means: "no matter who asked for these libraries, Next included, use at least these versions".

6. Verify it applied:

npm ls package-name   # it should show the new version (it can appear as "overridden"/"deduped")
npm audit             # expected: found 0 vulnerabilities

7. Test before shipping (do not skip):

npm run build

Packages such as postcss (CSS) and sharp (images) touch the visual side, so running npm run dev and checking the site in the browser also pays off.

8. Ship the fix:

git add .
git commit -m "Fix dependency vulnerabilities"
git push

The commit should show 2 files changed (package.json + package-lock.json). If it shows "nothing to commit", the update never happened, so go back to step 5.

9. Check in the panel: the Security → Vulnerabilities scan is not instant; it can take a few hours to come back clean. The immediate technical confirmation is npm audit's found 0 vulnerabilities.

A preventive routine: run npm audit from time to time and follow the alerts in the Hostinger panel or from Dependabot on GitHub (the same database). New vulnerabilities in dependencies are routine in any project, and they signal no error by whoever developed it.

git push asks for a password and refuses it

GitHub accepts no ordinary password in the terminal. The solutions:

• Use the browser login when the window opens (recommended); or
• Create a token in GitHub → Settings → Developer settings → Personal access tokens and use it in place of the password.

remote origin already exists when running git remote add

A connection already exists. Correct the URL with:

git remote set-url origin https://github.com/user/repository.git

"LF will be replaced by CRLF" warnings

It is no error. It is line-ending normalization between Windows and Linux/Mac. Ignore it.

A file that should have stayed out went to GitHub

1. Add its path to .gitignore.
2. Remove it from Git's control (without deleting it from the computer):

git rm --cached path/to/file

3. Commit and push.

Commands used a single time (setup)

git --version                      # check the Git installation
git config --global user.name "Your Name"
git config --global user.email "email@example.com"
git init                           # only if git status returns "not a git repository"
git branch -M main                 # rename the branch to main
git remote add origin URL          # connect to the GitHub repository
git push -u origin main            # the first push

Day-to-day commands (every update)

git add .
git commit -m "description of the change"
git push

Read-only commands (they change nothing)

git status       # what is modified / pending
git remote -v    # which repository the folder connects to
git log --oneline  # a condensed commit history
npm audit        # vulnerabilities in the project's dependencies
npm ls package   # where and which version of a package is installed

Documentation produced from the real setup process of the zumkai project, on 23 July 2026.