Tips & Tricks

Set up GitHub Actions free tier CI CD on private repos

2026-09-16 - ABikram Mondal

Confirm the free allowances before you start building

GitHub gives every free account 2000 Linux minutes per month on private repositories plus 500 MB of artifact storage according to the billing reference on their site.

Public repositories run unlimited on standard GitHub hosted runners with no minute count at all.

Windows jobs count double against the quota and macOS jobs count ten times so a single macOS build can wipe out a large chunk of the allowance in one go.

The allowance resets on the first day of each billing cycle and any usage beyond it bills at 0.006 dollars per extra Linux minute after the January 2026 rate cut reported by CICDCalculator.com.

Self hosted runners never consume the free minutes at all so they remain the main way to stay inside the limit on private work.

GitHub Docs also lists a six hour cap on single jobs and twenty concurrent jobs on the free plan as hard stops that apply regardless of minutes left.

Start with a public repository if your code can live there

Public repositories give unlimited minutes on standard runners so test your workflow here first before moving anything private.

Sign into GitHub and create a new repository with the public setting selected then clone it locally with the git command line tool.

Push a simple project such as a Node.js app or a static site so the first workflow has something concrete to build and test.

Keep the default branch named main because most workflow examples assume that name and changing it later adds extra edits.

Once the public version runs green you can fork or copy the workflow file into a private repository and watch the minute counter start.

Many solo developers and small Indian teams keep core open source pieces public exactly to stretch the free tier this way.

Write the workflow YAML file in the correct folder

Create a directory named .github/workflows inside the repository root then add a file such as ci.yml with a text editor.

Begin the file with a name field and an on trigger that fires on push to main and on pull requests so every change runs the checks.

Define a job that uses runs-on ubuntu-latest and add the checkout action first so the runner receives your code.

Follow checkout with a build step that runs npm install and npm run build or the equivalent commands for your language and framework.

Commit and push the file then watch the Actions tab in the repository for the first green or red run.

Each step appears with its own timing so you quickly see which commands eat the most of the 2000 minute budget.

Add caching to stretch those minutes further

Without caching every run reinstalls dependencies from scratch and that quickly adds up on the free allowance.

Insert the official actions/cache step right after checkout and point it at the node_modules folder or the language specific cache path.

Use a cache key that includes the hash of your lockfile so the cache stays valid only when dependencies actually change.

Artifact storage stays at 500 MB on the free plan so upload only the final build output and set a short retention period of seven days in the workflow.

GitHub Docs notes that cache storage sits at 10 GB per repository on the free plan and does not count against the artifact limit.

Test the cached run locally first by clearing your own node_modules and timing the difference before relying on it in CI.

Move to self hosted runners once the quota feels tight

Self hosted runners run on your own machines and never deduct from the 2000 minute pool according to every GitHub billing page.

Install the runner application on a spare Linux VPS or even an old laptop you leave on at home then register it with a registration token from the repository settings.

Label the runner with a custom name such as home-linux and reference that label in your workflow instead of ubuntu-latest.

Security matters here so keep the machine patched and limit the runner to repositories you fully control.

Many developers in India use a low cost DigitalOcean droplet or an AWS free tier instance for exactly this purpose and report steady savings on minute usage.

Remember that you still pay for the underlying server so the real catch is electricity and maintenance time rather than GitHub bills.

Watch the usage dashboard every week and set a hard stop

Go to the billing section of your account settings and open the Actions and Packages usage report to see minute consumption in real time.

Set the spending limit to zero dollars so any overage simply stops the workflows instead of generating an unexpected invoice.

GitHub sends email alerts at 90 percent and 100 percent of the included minutes so enable those notifications on the same page.

If your team routinely exceeds 2000 minutes consider the Team plan at four dollars per user per month which adds another 1000 minutes and more storage.

For teams that outgrow the free minutes quickly ABikram Mondal builds web development for exactly this kind of problem at https://abikrammondal.com/services/web-development.

Track one month of real runs before deciding on any upgrade because many small projects stay comfortably inside the free numbers with caching and selective self hosted jobs.

The short version. The free tier supplies 2000 Linux minutes per month on private repositories plus unlimited runs on public ones before per-minute charges begin.

Sources

Reported from the sources above on 2026-09-16. Figures are as published at the time of writing. If something here has moved on, the linked source is the one to trust.

From the desk of ABikram Mondal

If you got here because you are actually thinking about having it built properly once, instead of stitching six free tiers together and maintaining them forever, that is the work I do. I build for founders and small teams who want the thing to exist and work, not a deck about it.

Web Development services · everything I do · talk to me