"Set up CI/CD" means different things depending on team size. A 40-person engineering org and a solo founder need very different pipelines, and copying the former's setup when you're the latter is a common way to lose a week to YAML.
What GitHub Actions is actually for
Actions shines when you need gated, auditable, multi-stage pipelines: run tests, run a linter, build for multiple targets, require a passing check before merge, deploy to staging automatically and production on manual approval. It's genuinely necessary once multiple people are shipping to the same app and you need a source of truth for "is this commit safe to deploy."
The cost: YAML that needs maintaining, secrets management inside GitHub's UI, and a pipeline that's one more thing to debug when it breaks (and it will, usually right when you need to ship a hotfix).
What git-push deploy is actually for
A workflow where pushing to a branch (or a webhook firing on push) directly triggers a build and deploy, no intermediate YAML pipeline. Simpler mental model, nothing to maintain beyond the deploy config itself, and the fastest possible path from commit to live.
The cost: no built-in gate for "did the tests pass" before deploying, though a pre-push hook or a lightweight check can approximate it. For one or two people who are the tests, this is rarely the limiting factor.
The actual decision rule
- Solo or two-person team, moving fast, you are the QA process: git-push deploy. The overhead of a full Actions pipeline is bigger than the risk it protects against at this scale.
- 3+ engineers, code review is a real gate, staging exists: GitHub Actions, with required checks before merge and an explicit staging → production promotion step.
- Somewhere in between: git-push deploy with a required status check (tests) before the push is even possible — a middle ground that doesn't need a full pipeline.
Where this fits with deploy tooling
Most modern deploy tools support both patterns: git-push (or even a poll-based auto-deploy for local/desktop tools that can't receive webhooks) for the simple case, and an Actions step that calls a deploy API/CLI for the gated case. DeployOS, for instance, auto-deploys on push by default for the simple workflow, while still exposing enough of a CLI surface to slot into an Actions pipeline once a team outgrows the simple version. Pick based on team size today, not the pipeline you think you'll need in a year — you can always add the gate later, but you can't get back the time spent maintaining one you didn't need yet.