You don't need a platform team to stop deploying by hand. You need the smallest pipeline that catches the mistakes you actually make.
Continuous integration means every change is automatically installed, built, and checked on a clean machine before it's merged. Continuous delivery goes one step further: whatever passes gets packaged and shipped without someone assembling a release by hand. Enterprise versions of this involve dedicated teams, dozens of stages, and a lot of YAML, which is exactly why small teams put it off. But the question for a team of two to ten engineers isn't whether to adopt "CI/CD" as a practice. It's how little pipeline you can get away with while still catching the mistakes that actually reach your users.
Start with one job that runs on every pull request: install dependencies from the lockfile, lint, type-check, run the tests you have, and build the thing you actually deploy. That's it. Nothing here is sophisticated, but each step removes a specific failure: the dependency that was installed globally on one laptop, the file someone forgot to commit, the type error that only shows up in the production build. Then protect your main branch so nothing merges while that check is red. A pipeline people can bypass under deadline pressure is a suggestion, not a safeguard.
The second step is where most of the value is: build once, deploy that exact artifact. The pipeline that tested a commit should produce the package (the bundle, the container image, the zip), and that same package should go to staging and then production. Rebuilding on a different machine for each environment reintroduces precisely the drift CI was supposed to remove. Keep the previous few artifacts around, too, because a fast rollback is just redeploying the last one that worked.
Finally, get credentials off laptops. Production secrets belong in the CI platform's secret store, scoped per environment, and where your cloud supports it, the pipeline should receive short-lived credentials through OIDC federation instead of holding long-lived access keys at all. That's the whole minimum: checks on every change, a protected main branch, one artifact promoted through environments, and secrets that only the pipeline can use.
Preview environments (a live, disposable copy of the app for every pull request) are one of the best upgrades available, and one of the most unevenly priced. For frontends and static sites they're nearly free: most hosting platforms create them automatically, and reviewers can click a link instead of pulling a branch. For a backend with a database, queues, and third-party integrations, each preview needs its own data, its own secrets, and its own cleanup, and the cost climbs quickly. Use them where they're cheap, and a single shared staging environment where they aren't.
Manual deploys aren't automatically wrong. A scripted deploy run by one careful person, a few times a month, for something easy to roll back, is a perfectly reasonable place to be. The real danger isn't speed; it's that a manual deploy ships whatever happens to be on someone's disk. Untracked scratch files, an uncommitted local tweak, a dependency installed months ago: all of it can end up in production, because nothing checked that the package matched version control. If you deploy by hand, at minimum build the package from a clean checkout of a tagged commit, not from your working directory. And watch for the signs you've outgrown it: more than one person deploys, the steps live in a README nobody updates, people avoid deploying on Fridays, or an incident traces back to a skipped step.
One or two people ship, and deploys happen a few times a month rather than a few times a day.
What you're deploying is static or easy to roll back, so a bad release costs minutes, not customers.
The deploy script builds from a clean checkout of version control, never from someone's working directory.
Several people ship to the same environment, and nobody can say for certain what's live right now.
You deploy more than a few times a week, or a bad deploy costs real money or customer trust.
Deploying needs production credentials on laptops, or more steps than anyone reliably remembers.
Whichever lives where your code already does: GitHub Actions if you're on GitHub, GitLab CI if you're on GitLab. The free tiers cover most small teams. Switching later is cheap as long as the real logic lives in scripts inside your repository and the pipeline file just calls them, rather than hundreds of lines of platform-specific YAML.
No. Start with installing dependencies from the lockfile, linting, type-checking, building, and whatever tests you already have. A pipeline that only proves the project builds from a clean checkout already catches a whole class of problems: missing files, undeclared dependencies, code that only compiles on one laptop. Add tests to the pipeline as you write them.
Usually the opposite. Automated deploys ship small changes often, and a small change is easy to diagnose and easy to roll back. Manual deploys tend to batch weeks of changes into one nervous release, and they add human error to every step. The safety comes from pairing automation with a fast rollback, not from a person clicking the button.
Aim for pull request checks under about ten minutes. Past that, people stop waiting for results and merge anyway, which defeats the point. Cache dependencies, run independent jobs in parallel, and keep slow end-to-end suites for merges to main or a nightly run rather than every commit.
Keep them in your CI platform's secret store, scoped per environment so a staging job can't read production credentials. Where your cloud supports it, use OIDC federation (the pipeline gets short-lived credentials from AWS, GCP, or Azure per run), instead of storing long-lived access keys at all. And never expose secrets to workflows triggered by pull requests from forks.
An honest sizing guide: what a cluster really costs a small team, and the managed platforms that cover 90% of cases.
Read the guidePay per request or pay per server: the billing model is really a decision about who does the operations work.
Read the guide