Git-Push Deploys: How They Work

The promise: git push and it's live

The best deployment experience is almost no experience at all: you commit, you push, and a minute or two later your change is live — built, tested, deployed, with a URL. No SSH, no manual docker build, no copying files to a server. Heroku popularized this a decade ago; it's now the expected baseline. But "git push to deploy" hides a surprising amount of machinery. Let's open it up.

The pipeline, step by step

From your git push to a live app, here's what happens:

1. 1Push to remote. Your commit lands on the configured branch (say main).
2. 2Webhook fires. Your Git host (GitHub/GitLab) sends an HTTP webhook to the platform: "branch main just got commit abc123."
3. 3Platform validates & enqueues. It verifies the webhook signature, records a deployment, and queues a build job.
4. 4Source checkout. A build worker clones the repo at that exact commit.
5. 5Detect & build. The platform detects the project type (framework, buildpack, or Dockerfile) and builds an artifact — a container image or static bundle.
6. 6Push artifact. The image goes to a registry; static output goes to object storage/CDN.
7. 7Deploy/release. The new version is rolled out (new pods, traffic shifted) — ideally atomically.
8. 8Health check & finalize. Once the new version is healthy, traffic cuts over; the old version is drained.
9. 9Notify. Status and logs stream back to you.

Webhooks: the trigger

The webhook is the spark. When you connect a repo, the platform registers a webhook with your Git host. On each push (or PR, or tag), the host POSTs a JSON payload to the platform's endpoint. A simplified payload:

{
  "ref": "refs/heads/main",
  "after": "abc1234...",
  "repository": { "full_name": "acme/web" },
  "pusher": { "name": "ajay" }
}

The platform verifies the payload's signature (HMAC using a shared secret) so it knows the request genuinely came from your Git host and wasn't forged — then acts on it.

Build detection: how it knows what to do

A good platform auto-detects your stack so you don't configure a pipeline by hand:

• Dockerfile present? Build that image — full control, any language.
• No Dockerfile? Use buildpacks / auto-detection: recognize package.json (Node), requirements.txt/pyproject.toml (Python), go.mod (Go), etc., and apply a sensible build.
• A static framework? Detect React/Vite, Astro, Next export, Hugo, Eleventy, VitePress, plain HTML — run the framework's build and publish the output.

Most detection is overridable: you can set the install command (npm/yarn/pnpm/bun), build command, and output directory when the defaults aren't right.

Immutable artifacts and atomic releases

Two principles separate a robust git-push deploy from a fragile script:

• Immutable artifacts. Each build produces a uniquely-tagged image (often tagged by commit SHA). You never mutate a running server in place; you deploy a *new* artifact. This makes deploys reproducible and rollbacks trivial — just re-point at a previous tag.
• Atomic cutover. The new version is started and health-checked *before* traffic moves to it. Users either see the old version or the new one, never a half-deployed broken state. If the new version fails its health check, traffic never cuts over.

Together these give you safe deploys and instant rollback.

Rollbacks and deploy history

Because every deploy is an immutable, tagged artifact, "rollback" is just "re-deploy a previous artifact." A deploy history is the list of those artifacts with their commit SHAs, timestamps, and status. When a release misbehaves, you pick the last good one and roll back in seconds — no rebuild required.

Branch and preview workflows

Mature setups deploy more than main:

• Production branch → production environment.
• Pull-request previews → ephemeral environments per PR, so reviewers see the change running before merge.
• Tags → can trigger versioned/staged releases.

Preview deploys are a huge collaboration win: every PR gets a live URL.

How this looks on PandaStack

This is the core of PandaStack's "Push code. It runs." model. You connect a Git repo and on push it:

• Receives the webhook, detects your framework/build/start (override install command if you like — npm/yarn/pnpm/bun),
• Builds the image with rootless BuildKit in an ephemeral Kubernetes Job pod (static sites build in microVMs on the pandastack.ai layer),
• Pushes the image to Google Artifact Registry,
• Deploys via Helm to multi-region GKE behind Kong ingress,
• Goes live with a URL, automatic SSL on custom domains, and a connected managed database auto-wired as DATABASE_URL.

You get live build and app logs (self-hosted Elasticsearch) streaming as it happens, rollbacks, and deploy history (Helm revisions under the hood). The whole pipeline above is the thing you don't have to assemble.

Common pitfalls (even with automation)

• Unverified webhooks → anyone could trigger deploys. Always validate signatures (platforms do this for you).
• Building from a moving branch ref instead of a pinned SHA → non-reproducible builds.
• No health check before cutover → you ship broken versions to users.
• Secrets in the repo → use platform env vars, never commit credentials.
• Huge build context → slow builds; use .dockerignore and good caching.

References

• [GitHub webhooks documentation](https://docs.github.com/en/webhooks)
• [Cloud Native Buildpacks](https://buildpacks.io/docs/)
• [GitHub: securing webhooks (signature verification)](https://docs.github.com/en/webhooks/using-webhooks/validating-webhook-deliveries)
• [Kubernetes Deployments (rollouts & rollback)](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)
• [Twelve-Factor App: Build, release, run](https://12factor.net/build-release-run)

---

Want git push to build, deploy, and go live — with logs, rollbacks, and an auto-wired database? That's exactly what PandaStack does. Connect a repo free at [dashboard.pandastack.io](https://dashboard.pandastack.io).