Skip to content

My deploy button is git push — and that's the point

2 min readDeployment · Workflow · Next.js

HEADGIT PUSH→VERCEL BUILDmain → production · no local builds

This website goes to production by pushing to main on GitHub. That is the entire release ritual: commit, push, read the deployment result. There is no local npm run build on my machine, no manual upload step, and no second source of truth. The machine that builds the site is the same environment that serves it — the only opinion that counts.

How the pipeline is wired

  • Push to main on the GitHub repository — that is the deploy trigger.
  • Vercel's Git integration receives the webhook and starts a remote build (npm run build on Vercel's runners, not on my device).
  • The build either shows up green or it doesn't — and if it doesn't, vercel logs <deployment-url> tells me exactly why.
  • Every commit maps to one deployment, so the error trail always points at a diff I can read.

Why not build locally

My day-to-day machine is resource-constrained. More importantly, a build that succeeds locally but fails on Vercel is a wasted afternoon; a build that fails locally but would pass remotely is a false alarm. Removing the local build from the loop removes that ambiguity. The deployment log is the only verdict I trust — everything else is a prediction.

The failure drill

When a push produces a red deployment, the recovery is boring on purpose:

# find the deployment your push just triggered
vercel ls

# read the full build log for it
vercel logs https://portfolio-xxxx.vercel.app

# fix the cause, commit, push again — never force-push main

Twice I have been tempted to reach around the pipeline — a manual vercel --prod to "just get it live". Both times the right move was the slow one: read the log, fix the actual error, push again. Emergency deploys that bypass the pipeline are how environments drift apart.

The rules I keep

  • The repository is the release button — small, frequent, boring commits over heroic ones.
  • A push isn't finished when the commit lands; it's finished when the deployment is green.
  • Logs are read before theories are formed. Guessing costs more than reading.
  • Force-pushing main is never part of the drill — history stays honest.

None of this is novel infrastructure — and that is the compliment. The best deploy pipeline is the one nobody discusses, because it never asks for attention.

Shihab Hossain — full-stack developer portrait

Written by

Shihab Hossain — Full-Stack Developer

I build thoughtful digital products — from fast web experiences to mobile apps and the infrastructure behind them.

Work with me

All notes