Short answer: a small web project needs a minimal CI/CD setup, tests and lint on every push, automatic deploys on merge, and environment variables kept out of the codebase, not the full multi-stage, multi-environment pipeline most tutorials show.
It's easy to over-build a CI/CD pipeline for a small project: multi-stage Docker builds, a Kubernetes deployment, separate staging and canary environments, because that's what the tutorials and enterprise case studies show. For most small sites and apps, almost none of that is necessary, and building it anyway just means more infrastructure to maintain for no real benefit.
What is CI/CD actually solving?
Two problems, and only two: catching mistakes before they reach users, and removing manual steps from getting code live. That's it. If a pipeline isn't doing one of those two things, it's not earning its complexity.
What's the minimum CI/CD setup worth having?
For a small web project, this is close to the full list:
- Run tests and lint on every push. A GitHub Actions workflow that runs on
pushandpull_request, installs dependencies, runs the linter, and runs whatever tests exist. This is maybe fifteen lines of YAML and it catches the class of mistake that's easy to make and easy to miss: a broken import, a failing test nobody re-ran locally, a lint rule that would've flagged a real bug. - Deploy automatically on merge to the production branch. Vercel, Render, Netlify, and most modern hosts do this natively just by connecting the GitHub repo, no custom pipeline needed. If you're on a platform that doesn't do this out of the box, a single deploy step at the end of the CI workflow covers it.
- Keep environment variables in the platform, not in code. SMTP credentials, API keys, database URLs: set once in the hosting platform's dashboard, never committed. This isn't really a CI/CD step so much as a prerequisite for the rest of this to be safe.
That's genuinely most of what a small project needs. No separate staging environment unless there's a real reason for one (a team big enough that "test in production" isn't survivable, or a client who specifically needs to review changes before they go live). No Docker unless the app has dependencies that are genuinely hard to reproduce consistently otherwise. No Kubernetes, full stop, for anything short of a system that actually needs to scale horizontally across multiple services.
Where is it worth spending a bit more effort?
A couple of additions earn their keep even on small projects:
- A preview deployment per pull request. Vercel and Netlify both do this automatically: every PR gets its own live URL. It turns "can you review this change" into a link instead of a description, and it costs nothing extra to set up since it's usually on by default.
- A build check that actually fails the PR if the build breaks. Obvious in theory, but worth confirming explicitly. A CI setup that runs tests but doesn't run the production build can still let a broken build merge if the failure only shows up at build time, not test time.
What does overengineering a CI/CD pipeline actually look like?
The failure mode isn't usually "no CI/CD," it's disproportionate CI/CD. A five-page marketing site with a Kubernetes deployment and a multi-environment promotion pipeline isn't more professional, it's more fragile: more YAML to misconfigure, more infrastructure that can silently break, more things a solo developer or small team has to keep in their head. The pipeline should be sized to the actual failure modes of the actual project, not to what a much bigger team's pipeline looks like.
The test I use: for every piece of the pipeline, could I explain in one sentence what specific mistake it catches or what specific manual step it removes? If not, it's probably there because it looked impressive in someone else's blog post, not because this project needs it.
This is the same sizing principle I use when I set up DevOps basics for client projects: match the tooling to the team, not to the tutorial.