CI/CD for solo developers: the smallest pipeline worth having
Filed under Guide
By Gerald · 15 September 2026
Do you need CI/CD if you work alone? Yes, but not the version most guides describe. You need a type check, a build, and a deploy that can roll back. That is close to the entire list. Everything else in a typical team pipeline exists to coordinate people who are not you.
I run Flow's entire pipeline in under two minutes, and it catches nearly everything that would otherwise reach production broken. Here is what earns its place and what does not.
A pipeline's job is to catch what you would have caught anyway, just before it matters instead of after.
What CI is actually protecting you from when you work alone
Team CI protects against a specific failure mode: one person's change breaking something another person did not know about, discovered too late because nobody looked at the whole picture before merging. Alone, that failure mode barely exists. You wrote the change. You know what else touches that file. The coordination problem CI solves for a team is not really your problem.
What CI still protects you from, solo, is a much narrower and more mundane set of mistakes: a type error you did not notice in an editor tab you were not looking at, a build that works locally because of stale cached artifacts but fails clean, and a deploy that goes out with something broken because you forgot to run the build before pushing. These are real, and they happen to solo developers constantly, but they do not require the ceremony a team pipeline carries.
The three checks worth running
Type checking. If you write TypeScript, run a full type check on every push. This catches the class of error that unit tests often miss entirely: a function signature changed somewhere and three call sites were not updated. npx tsc -b --noEmit (or your language's equivalent) takes seconds and catches mistakes that would otherwise surface as a runtime error in front of a user.
Build. Run the actual production build, not just a dev server boot. Dev servers are forgiving in ways production builds are not, tree-shaking, minification, and strict mode can all surface errors that never appear locally. A build that fails in CI and would have failed in production is the single most valuable check in the whole pipeline.
Deploy with rollback. The deploy step matters less as a check and more as the actual point of the pipeline: get the build to production reliably, and make sure a bad deploy can be undone in seconds, not by SSHing into a server and guessing.
That is genuinely the list. Linting is worth having if your editor is not already running it live, but it duplicates what a good editor setup does for free, so it earns a much lower priority than the three above.
Keeping the pipeline under two minutes
A slow pipeline gets ignored, which defeats the purpose of having one. Two minutes is a reasonable ceiling for a solo project: fast enough that you wait for it before moving on, slow enough to actually run a real build.
Cache dependencies aggressively. Most CI providers, GitHub Actions included, support caching node_modules or the package manager's store between runs, and skipping a full reinstall on every push is usually the single biggest speed win available.
Run checks in parallel where they do not depend on each other. Type checking and a build can often run as separate jobs rather than sequential steps in one job, since one does not need the other's output to start.
Do not add a test matrix across multiple runtime versions unless you are shipping a library other people install into unknown environments. If you control the runtime version because you are the only one who deploys it, testing against versions you will never actually run adds minutes for a scenario that cannot occur.
Preview deployments and rollbacks
A preview deployment, a live URL generated from a branch or pull request before it merges, is worth having even alone, because it lets you look at a real deployed version of a change before it is live for actual users, catching environment-specific issues a local dev server hides.
Rollback matters more than almost anything else on this list. Vercel, Netlify, and most modern platforms keep previous deployments available and let you promote an older one back to production in seconds if a new deploy breaks something. Confirm this works before you need it, not during an incident. A pipeline that ships fast but cannot revert fast is more dangerous than no pipeline at all, because it gives you false confidence.
The stages that only make sense with a team
Required reviewer approval on pull requests exists to make sure a second set of eyes looks at a change before it merges. Alone, there is no second set of eyes, and requiring your own approval on your own PR is theater, not a check.
Staging environments that mirror production and require a manual promotion step exist so a team can validate a release together before a release manager pushes the button. Alone, a preview deployment already gives you the same visibility with less process, since you are the one who would be validating it in either setup.
Large test matrices across multiple OS and runtime combinations exist because a team does not control what environment every contributor or user runs. If you are the only person deploying your own code to your own infrastructure, most of that matrix tests configurations that will never occur.
Branch protection rules requiring multiple approvals or specific reviewers assume a review chain that does not exist when there is one contributor. A single required check (the pipeline passing) is enough; requiring approval from a person is not meaningful when that person is always you. This is consistent with keeping a Git workflow for solo founders light: pull requests as a self-review tool, not a coordination mechanism.
When to add more
Add a reviewer requirement the day you bring on a second contributor, even a part-time one. Add a staging environment when you have customers whose usage patterns you cannot safely test against in a preview deployment alone, typically once you have enough real traffic that synthetic testing stops resembling actual use. Add a broader test matrix only if you ship something other people install into environments you do not control, like an open source library or a CLI tool.
Everything on this list should be added in response to an actual new constraint, not preemptively because a team-oriented guide said so. See my GitHub review and Vercel review for how those two tools specifically fit into a minimal pipeline, and my Sentry review for the monitoring half of this equation, catching what slipped past the pipeline once it is already live. If your runtime choice affects any of this, see Bun compared with Node for how that decision changes build and test speed. And if the total pipeline cost is part of a bigger budgeting question, see what a small SaaS costs to run, since CI minutes are one of the smaller line items on that list, not the largest.
Frequently asked questions
Do solo developers need CI/CD? Yes, in a minimal form. A type check, a build, and a reliable deploy with rollback catch most of the mistakes that actually happen to a solo developer. The team-oriented parts of CI, required reviewers, staging approvals, wide test matrices, solve coordination problems that do not exist with one person.
Is GitHub Actions free for personal projects? Yes for public repositories, which have no minute limit on standard GitHub-hosted runners. Private repositories on the Free plan get 2,000 minutes a month, per GitHub's documentation in July 2026, which is generous for a two-minute pipeline running on typical solo push frequency.
Should I have a staging environment on my own? Usually not. A preview deployment per branch or pull request gives you the same ability to look at a real build before it goes live, with less process than a full staging environment that requires a manual promotion step designed for a team handoff you do not have.
How long should a pipeline take? Under two minutes is a reasonable target for a solo project. Faster than that and you might be skipping a real build step; slower and you will start ignoring it, which defeats the point of having one at all.
What is the easiest way to roll back a bad deploy? On platforms like Vercel or Netlify, promoting a previous successful deployment back to production takes seconds through the dashboard or CLI. Confirm this works and that you know the exact steps before you actually need it during an incident.
Related reading
My verdict
Run a type check, a build, and a deploy that can roll back in under two minutes, and skip everything else until you actually have a team to coordinate with.