Git Deploy Hosting - Setting Up a Clean Push-to-Deploy Workflow

Git push to deploy means your hosting platform watches a branch in your repository, and every push to that branch automatically installs, builds and restarts your app. No FTP, no SSH sessions, no "which files did I change?". Setting it up well comes down to four decisions: which branch deploys to production, what the build and start commands are, where secrets live, and how you roll back. This guide walks through each, with commands you can copy.

How push-to-deploy works

Behind the scenes, a typical flow looks like this:

1. You connect a GitHub or GitLab repository to your hosting account.
2. The host registers a webhook on the repository, so the Git provider notifies it on every push.
3. When a push lands on the production branch, the host clones that commit.
4. It runs your install command (for example npm ci) and build command (npm run build).
5. If the build succeeds, it starts the new version with your start command and switches traffic to it.
6. If the build fails, the previous version keeps running and you get the build log.

On NewHost, you deploy Next.js, Node.js, Express, Nuxt and static apps the same way: connect the repository, choose the branch, set your install, build and start commands, and each push to that branch deploys automatically.

Step 1 - Choose a branching model

Keep it simple. For most small teams:

Work on a short-lived branch, open a pull request, review it, and merge into main. The merge is the deploy. If you want a staging step, add a long-lived staging branch connected to a second app - but for many teams, preview deployments per branch replace the need for a shared staging server.

Protect main in your Git provider so nobody pushes to it directly and pull requests need at least one approval or passing checks.

Step 2 - Make the build reproducible

A deploy should produce exactly what you tested. For Node.js projects:

• Commit package-lock.json (or your package manager's lockfile).
• Use npm ci rather than npm install in deploys; it installs exactly what the lockfile says and fails if the lockfile and package.json disagree.
• Pin your Node.js version in package.json and match it on the host.

{
  "engines": { "node": ">=22" },
  "scripts": {
    "build": "next build",
    "start": "next start"
  }
}

Typical commands to configure on the host:

Your app must listen on the port the platform gives it, usually via the PORT environment variable. The Next.js deployment docs cover framework-specific details.

Step 3 - Keep secrets out of the repository

Never commit .env files with real credentials. Add them to .gitignore:

echo ".env*" >> .gitignore
echo "!.env.example" >> .gitignore
git rm --cached .env 2>/dev/null

Commit an .env.example with variable names and dummy values, and set the real values in your host's environment variable settings. NewHost stores environment variables encrypted. Remember that frameworks like Next.js inline NEXT_PUBLIC_ variables at build time, so changing them requires a rebuild.

Step 4 - Run checks before code reaches main

Push-to-deploy is only as safe as what gets merged. Add a small CI workflow that runs on every pull request - lint, type-check and tests. With GitHub Actions:

name: CI
on:
  pull_request:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint --if-present
      - run: npm run test --if-present

Then require this check to pass before merging into main. Our topic list includes a fuller guide to simple CI/CD for small teams.

Step 5 - Plan your rollback

Sooner or later a bad deploy gets through. The cleanest rollback in a Git workflow is a revert commit:

git revert --no-edit <bad-commit-sha>
git push origin main

This creates a new commit that undoes the change and triggers a fresh deploy, while keeping history intact. Avoid git push --force on main; it rewrites history for everyone. The git-scm.com documentation explains git revert in detail.

Database migrations need extra thought: a code rollback does not undo a schema change. Write migrations that are backwards-compatible (add columns before removing old ones) so that the previous version of the code still works. See connecting Node.js to MySQL with Prisma for migration workflow.

Step 6 - Get notified

Know when deploys succeed or fail without watching a dashboard. NewHost's REST API sends webhooks for events such as deployment.succeeded, which you can forward to Slack, Teams or your own tooling. See the developer docs and our webhooks guide for verifying them safely.

Common mistakes

• Building on the server with dev dependencies missing - if your build needs TypeScript or a bundler, make sure it installs dev dependencies during the build.
• Hard-coding the port - listen on process.env.PORT.
• Committing build output - add .next/, dist/ and node_modules/ to .gitignore; let the host build.
• Deploying on Friday afternoon - fine if your rollback is one command, painful if it isn't.
• Everyone using one Git account - give each developer their own access so history shows who changed what.

Frequently asked questions

Is git push to deploy safe for production?

Yes, when production only deploys from a protected branch, pull requests are reviewed, and tests run before merging. It is usually safer than manual uploads, because every deploy is traceable to a commit.

Can I deploy from GitLab as well as GitHub?

On NewHost, yes - you can connect either a GitHub or a GitLab repository. Other platforms vary, so check which Git providers they support.

What happens if my build fails?

A well-designed platform keeps the previous version running and shows you the build log. Fix the problem, push again, and a new deploy starts.

Do I still need FTP or SSH?

Not for deploying code. You may still use SSH or a control panel for debugging on some platforms, but the Git repository should be the single source of truth for what runs in production.

Ready to push to deploy from GitHub or GitLab on South African servers? See Next.js hosting or compare plans.