Every CI platform aimed at small teams leads with a free tier, and every free tier is quoted in units that hide the thing you actually consume. A monthly allowance of build minutes sounds generous until you notice that a minute on a larger machine is billed as several, that a macOS minute is billed as many more, and that most of the minutes in a typical job are spent before a single test runs.
That last part is the one that catches teams out. A job checks out the repository, restores or rebuilds a dependency tree, provisions a language toolchain, maybe pulls a container image, and only then starts doing the work you care about. On a small project that overhead can be most of the job. Multiply it by a test matrix and the allowance disappears against work that produces no information at all.
The second thing free tiers hide is that CI compute is only one of several meters. Cache storage, artifact retention, container registry storage and egress are usually separate, and they are the ones that keep growing while your commit volume stays flat.
So the useful question for a startup is not which platform has the biggest free allowance. It is which platform’s meter matches the shape of your pipeline, how much config you have to learn to get there, and what happens on the day you outgrow the free tier, because that day arrives while you are busy with something else.
Key takeaways
- Most minutes in a small pipeline are setup, not tests. Cutting checkout, dependency restore and toolchain provisioning buys more headroom than switching vendors.
- Free allowances are usually quoted in Linux-equivalent minutes. Larger machines and non-Linux runners consume the allowance at a multiple, which is where matrices become expensive.
- Compute is rarely the only meter. Cache storage, artifact retention and registry storage accumulate independently of how often you build.
- Secrets handling is the part worth getting right immediately, because retrofitting short-lived federated credentials across a repo full of workflows is far more work than starting with them.
What a free minute allowance actually buys
Read any free tier as a Linux-equivalent minute budget rather than a number of builds, then work out how many of your builds fit into it. Four multipliers sit between the two numbers.
Machine size. Platforms price bigger runners as a multiple of the base rate, so a job that needs more memory consumes the allowance several times faster. That coefficient is often the difference between a suite that fits in the free tier and one that does not, and it can push the right answer toward optimising memory use rather than buying a bigger machine.
Operating system. Linux is the base unit. Windows costs a multiple of it and macOS a larger multiple again, because the underlying hardware is neither commodity nor virtualisable the same way. Any team shipping an iOS app should assume that macOS minutes, not Linux minutes, are the constraint that actually binds.
Matrix width. A matrix is a multiplier on job count, and each job pays the full setup cost independently. Three runtime versions across two operating systems is six jobs, six checkouts, six dependency restores. The wall-clock time looks like one job because they run in parallel. The meter disagrees.
Retries and reruns. Flaky tests are a compute cost, not just an annoyance. Every rerun pays the whole setup tax again. A suite that needs one rerun in four is quietly consuming a meaningful share of your allowance on work that produces no new information.
The practical consequence is that the highest-leverage optimisation for a small team is almost never parallelism. It is making a single job cheaper: a warm dependency cache, a prebuilt container image containing the toolchain, and a test suite that does not need to be rerun.
Needs first-hand data: On one real repository, time a cold run and a warm run of the same commit on the same platform, and break both down into runner acquisition, checkout, dependency restore, toolchain setup and test execution. Then repeat with a prebuilt image containing the dependencies. Publish the three totals. The gap between cold and warm is the size of the prize, and it is the number every free-tier comparison omits.
Where the free tier stops being free
The transition is rarely a single event. It is five separate thresholds, and most teams hit two or three before noticing.
Private repositories. Several platforms are unlimited for public repositories and metered for private ones. If you started on an open source project and later went private, your costs change without your pipeline changing at all.
Storage meters. Caches and artifacts have retention windows and size caps, and once you exceed them you are billed on storage rather than compute. This grows with time and branch count rather than with build frequency, so it detaches from your mental model of usage. Prune artifact retention early; nobody has ever needed the build outputs from six months ago.
Concurrency caps. Free tiers limit how many jobs run at once. That is invisible with three engineers and immediately painful with eight, because queueing turns a fast pipeline into a slow one without any individual job getting slower. This is the threshold that produces the “CI is slow” complaint that no amount of build optimisation fixes.
Seats. Where CI is bundled into a platform that sells seats, growth in headcount raises the bill even if build volume is flat. Check whether read-only or infrequent contributors need a paid seat, because that detail decides the shape of your cost curve as you hire.
Egress and registry pulls. Pushing images to a registry, then pulling them at deploy time, crosses network boundaries that may be metered. This one is easy to miss because it appears on a different invoice from CI. Container registries covers the choice properly, and locating the registry near the compute that pulls from it is the cheapest fix.
Secrets: the thing worth doing properly on day one
Most startup pipelines start with a cloud access key pasted into the repository secret store, because it works in five minutes. It also creates a long-lived credential with broad permissions, held by a system that runs arbitrary code from pull requests. That is an unpleasant combination and it gets worse as the repository accumulates workflows.
The alternative is federated, short-lived credentials: the CI platform issues a signed token describing the workflow, the cloud provider trusts that issuer for a specific repository and branch, and hands back a credential valid for minutes. Nothing long-lived is stored anywhere. Every major hosted platform supports this pattern against the major clouds, and the configuration is a one-time trust policy rather than an ongoing rotation burden.
Three rules cover most of the risk for a small team.
Never expose secrets to workflows triggered by forked pull requests. The default on most platforms is safe, but it is easy to break by using a trigger that runs untrusted code in a trusted context. If you need to comment results back onto a fork’s pull request, split it into two workflows so the privileged half never runs untrusted code.
Scope credentials to the repository and branch. A federation trust policy that accepts any workflow in your organisation is only marginally better than a static key.
Keep the production deploy credential out of CI entirely if you can. A pull-based deployment model, where a controller inside your environment watches a repository, means CI never holds production access. GitOps tools covers that pattern, and secrets management for CI/CD covers the cases where you genuinely need a secret in the pipeline.
GitHub Actions
If your code is on GitHub, this is the path of least resistance and usually the right default. Workflows are YAML files in the repository, triggers cover every repository event, and the marketplace supplies prebuilt steps for most third-party services. Public repositories get unmetered hosted compute; private ones draw on a monthly allowance measured in Linux-equivalent minutes with multipliers for larger machines and for macOS and Windows.
Pros
- Nothing to integrate: repository, CI, permissions and required status checks are one system
- Enormous library of reusable actions, which removes most glue scripting for common integrations
- Federated cloud credentials are well documented and straightforward to set up early
- The runner layer is replaceable later, so outgrowing hosted compute does not mean leaving the platform
Cons
- Third-party actions execute inside your build with access to its secrets, and most teams never pin or review them
- Local reproduction of a failing job is awkward, so debugging degrades into commit-and-rerun cycles
- The macOS multiplier makes mobile pipelines expensive well before anything else in the bill does
Best for: Teams already hosting on GitHub who want CI working the same afternoon and will spend an hour on action pinning and credential federation.
Pricing: Unmetered on public repositories. Private repositories draw on a monthly minute allowance with multipliers by machine size and operating system, with storage for artifacts and caches metered separately.
GitLab CI/CD
GitLab bundles source hosting, CI, a container registry, environments and security scanning into one application, which is a meaningful advantage when you are small and do not want to integrate four vendors. The pipeline syntax has genuinely good composition features, and the same product can be self-hosted later without rewriting pipelines.
Pros
- One platform covers repository, registry, CI and deployment environments, so there is nothing to wire together
- Pipeline includes and extends make shared configuration reusable across repositories from the start
- Attaching your own runner removes hosted compute metering entirely, which is a clean escape hatch
- The self-managed edition runs the same pipeline definitions, so the migration path is real rather than theoretical
Cons
- Free-tier compute minutes are a shared allowance across the namespace, so one noisy repository starves the others
- Feature tiering is aggressive and several things that feel core sit above the free tier
- The bundled registry and scanning tools are convenient rather than best-in-class, and replacing one later fights the integration
Best for: Small teams who want a single vendor for source, CI and registry, and who value a credible self-hosting path from the beginning.
Pricing: Free tier with a namespace-wide monthly compute allowance, then per-seat tiers with metered minute overage, or unmetered when you attach your own runners.
CircleCI
CircleCI is a CI specialist, not a source host, which means an extra integration but also a product where build performance is the main thing the vendor works on. Resource classes let you size machines per job, and test splitting is a first-class feature rather than something you script.
Pros
- Explicit cache, workspace and test-splitting primitives make pipeline tuning a deliberate exercise
- Resource classes mean a small job runs on a small machine instead of paying a uniform rate
- Works regardless of where your repositories live, which matters if they are not all in one place
- Orbs package common integrations without the free-for-all of an open marketplace
Cons
- Credit-based metering combines machine size and duration into one abstract unit, which makes free-tier forecasting harder than counting minutes
- A separate vendor means separate authentication, separate billing and another integration to maintain when your source host already ships CI
- Configuration has more concepts to learn than the source-host-native options, which is real cost for a two-person team
Best for: Small teams with a test suite that is already slow enough to hurt and who want splitting and caching to be supported features rather than homemade scripts.
Pricing: Free tier expressed as a monthly credit allowance, with credits consumed at a rate set by resource class and duration, then paid tiers adding concurrency and support.
Buildkite
Buildkite hosts the orchestration and you run the agents on your own machines. For a startup that sounds like extra work, and it is, but it buys two things that matter to some teams immediately: source code never leaves your infrastructure, and compute cost is whatever you can negotiate from your cloud provider rather than a per-minute list price.
Pros
- Build compute runs on your own instances, so spot pricing and unusual hardware are both available
- Source and artifacts never leave your network, which shortens security review with early enterprise customers
- Pipelines can be generated at runtime, which suits a monorepo where the job graph depends on the diff
- No compute metering at all from the vendor, so build volume growth does not change the subscription
Cons
- You own agent images, autoscaling and machine lifecycle from day one, which is real work for a team without a platform engineer
- There is no zero-effort free path: something has to be running before the first build
- Fewer prebuilt integrations than the source-host-native platforms, so more of the glue is yours
Best for: Small teams with existing cloud infrastructure and a security-sensitive customer base, where keeping code inside the network is worth owning the agent fleet.
Pricing: Per-seat subscription for the hosted control plane, with all compute appearing on your own cloud bill rather than as vendor-metered minutes.
Codeberg CI
Codeberg runs a Woodpecker-based CI service alongside its Forgejo hosting, aimed squarely at open source projects. It is community-run and non-commercial, which shapes everything about it: capacity is finite and shared, access is granted rather than self-served, and the expectation is that you are building something publicly rather than running a company pipeline.
Pros
- No commercial metering at all, which fits open source components published alongside a commercial product
- Pipeline syntax is simple and container-native, so there is very little platform-specific concept to learn
- The underlying engine is open source, so moving to a self-hosted install later preserves your pipelines
- Fully independent of the large platform vendors, which matters if that independence is a project value
Cons
- Shared community capacity means no throughput guarantees, which rules it out for anything time-critical
- Feature surface is deliberately small compared with commercial platforms, with far less prebuilt integration
- Not intended for private commercial workloads, so it is at best half of a startup answer
Best for: Open source projects and the public components of a commercial product, where independence and zero cost outweigh throughput guarantees.
Pricing: No commercial pricing model. It is a community-funded service with shared capacity rather than a metered product.
Cloudflare Workers Builds
This is CI that exists to serve one deployment target. Connect a repository, and pushes build and deploy your Workers project without you standing up a pipeline at all. It is not a general CI platform and does not try to be, but for a team whose entire backend is Workers it removes the question of what to run builds on.
Pros
- Zero pipeline configuration for the common case: connect the repository and pushes deploy
- Build compute sits next to the deployment target, so there is no cross-network artifact handoff
- Preview deployments per branch come as part of the model rather than needing separate tooling
- Removes a whole category of credential handling, because the deploy does not need an external token
Cons
- Only useful for workloads that deploy to this platform, so you still need general CI for tests, linting and anything else
- Build environment customisation is limited compared with a general CI runner, which bites as soon as your build has unusual requirements
- Ties your build pipeline to your hosting decision, which makes changing either one harder
Best for: Teams whose application already runs entirely on this platform and who want deploys to be a property of pushing rather than a pipeline to maintain.
Pricing: Metered as part of the surrounding platform subscription with an included build allowance, rather than sold as standalone CI.
Vercel
Vercel is a deployment platform with a build system attached, and for frontend work that inversion is the point. Every push produces a preview deployment at its own URL, the framework detection handles most configuration, and the build cache is managed for you. It is not where your integration tests belong, but it removes a large amount of pipeline work for the part of the stack it covers.
Pros
- Preview deployment per branch with no pipeline configuration, which changes how design and product review work
- Framework-aware builds remove most build configuration for common JavaScript stacks
- Build and hosting are one system, so there is no artifact handoff or deploy credential to manage
- Rollback is a platform operation rather than a pipeline rerun
Cons
- Build environment is opinionated, and anything outside the supported frameworks fights the platform
- Coupling build to hosting means a hosting change is also a CI change
- Team-seat and bandwidth meters run alongside build metering, so cost growth has several independent sources
Best for: Frontend and full-stack JavaScript teams who want preview environments and deploys without operating a pipeline, with general CI handling tests separately.
Pricing: Per-seat plans with included build execution, plus separate metering for bandwidth and runtime invocations.
Netlify
Netlify occupies the same space as the previous entry with a longer history in static sites and a plugin model for extending the build. The same tradeoff applies: enormous convenience for the deployment path it is designed around, and friction anywhere outside it.
Pros
- Deploy previews and atomic rollbacks are built into the model rather than assembled from pipeline steps
- Build plugins provide an extension point for tasks like asset optimisation without a separate CI job
- Branch-based environments map cleanly onto a review workflow with no additional tooling
- Configuration for common static and framework builds is minimal
Cons
- Build minutes are metered separately from bandwidth and function invocations, so three meters move at once
- Build containers are not general-purpose compute, and non-web build steps do not belong here
- Coupling deployment and CI in one vendor makes leaving a two-part migration rather than one
Best for: Static and JAMstack sites where deploy previews and instant rollback matter more than general-purpose build flexibility.
Pricing: Per-seat plans with an included monthly build minute allowance, with bandwidth and function usage metered separately.
How to choose
Start from where your code lives. If everything is on one source host that ships CI, use it. The integration savings are real and the switching cost later is lower than the integration cost now.
Separate deploy tooling from test tooling deliberately. The frontend platforms in this list are excellent at turning a push into a preview URL and poor at running an integration suite. Using both, with general CI for tests and a deployment platform for previews, is a common and sensible answer rather than a failure to decide.
Optimise the single job before buying parallelism. A warm cache and a prebuilt toolchain image usually reclaim more allowance than any plan upgrade, and the work carries over to whatever platform you end up on.
Set up federated credentials while you have five workflows, not fifty. This is the one decision that is much cheaper now than later.
| Option | Meter that binds first | Config learning curve | Where free ends |
|---|---|---|---|
| GitHub Actions | Minutes, multiplied for macOS and large runners | Low if you stay on marketplace actions | Private repo minutes and artifact storage |
| GitLab CI/CD | Namespace-wide shared minute allowance | Moderate, with strong reuse once learned | Shared allowance exhaustion and tiered features |
| CircleCI | Credits combining machine size and duration | Higher, more explicit primitives | Credit exhaustion and concurrency limits |
| Buildkite | None from the vendor, your cloud bill instead | Moderate, plus agent operations | Immediately, since you supply compute |
| Codeberg CI | Shared community capacity | Low, container-native syntax | Not applicable, non-commercial service |
| Cloudflare Workers Builds | Included build allowance in the platform plan | Very low, no pipeline to write | Build allowance and platform plan limits |
| Vercel | Build execution plus bandwidth and seats | Very low for supported frameworks | Seats, bandwidth and build execution together |
| Netlify | Build minutes plus bandwidth and functions | Very low for static and framework builds | Build minutes, bandwidth and seats independently |
Needs first-hand data: Run the same commit through two candidate platforms with identical caching configured, and record wall-clock time and allowance consumed for a cold run, a warm run and a dependency-bump run. Also record how long each took to configure from an empty repository. Setup time is a real cost for a small team and no comparison ever measures it.
Frequently asked questions
Is the free tier enough to run a real startup pipeline?
For a small team on Linux builds with decent caching, usually yes for a while. The three things that end it early are macOS builds, a wide test matrix, and concurrency limits once the team grows past a handful of engineers. None of those are about commit volume, which is why teams are surprised by the timing.
Should we self-host runners to save money?
Not at this stage, unless you already have someone operating cloud infrastructure. Self-hosted compute is cheaper per minute and considerably more expensive per hour of attention, and a small team rarely has the second kind of budget. Self-hosted CI/CD covers the maintenance arithmetic. A middle option is a third-party runner fleet, covered in CI runner providers, which keeps the operational burden with a vendor while changing the compute economics.
What is the fastest way to cut CI cost without changing platforms?
In order: cache dependencies properly, bake the toolchain into a prebuilt image so setup is a pull rather than an install, cut artifact retention, and stop running the full matrix on every push. Reserving the wide matrix for the default branch while pull requests run a representative subset is usually the largest single saving.
How do we handle secrets without a secrets manager?
Use the platform secret store for the few things that must be static, and federated short-lived credentials for cloud access so nothing long-lived exists at all. A dedicated secrets manager is worth adding when you have multiple environments and rotation requirements, not before.
Do we need separate CI if we deploy through a frontend platform?
Almost always yes. Those platforms are built to turn a push into a deployment, not to run an integration suite, a linter and a security scan in parallel. Running tests in general CI and deploys on the platform is the normal arrangement and is not a sign of a duplicated setup.
Related reading
- Best CI/CD platforms — the category map and how each billing model interacts with pipeline shape.
- Best CI runner and compute providers — changing the compute economics without leaving your platform.
- Best build caching tools — the fix that reclaims more allowance than a plan upgrade.
- Best secrets management for CI/CD pipelines — when the platform secret store stops being enough.
- Best preview environment tools — per-branch environments when your deploy platform does not supply them.