GitHub Actions Now Supports CI/CD — Free for Public Repositories

This article is based on GitHub’s August 2019 announcement of CI/CD support in GitHub Actions. Some details reflect the state of the product at that time.

What Is GitHub Actions?

GitHub Actions is an automation platform built directly into GitHub. It lets you orchestrate any workflow in response to any GitHub event — a push, a pull request, a release, a comment, or even a custom event triggered by a GitHub App. Workflows and the individual steps that make them up are defined as code living inside your repository, which means they can be versioned, reviewed, shared, and forked just like application source code.

When GitHub first introduced Actions, developers embraced it for general automation tasks. The most requested follow-up feature was native CI/CD support — the ability to build, test, and deploy software directly from a workflow file. That capability arrived with the beta announced in August 2019, ahead of general availability at GitHub Universe on 13 November 2019.

CI/CD Across Any OS, Language, and Cloud

GitHub Actions CI/CD runs on Linux, macOS, and Windows. Workflows execute either inside containers or on virtual machines hosted by GitHub. At launch, supported languages and ecosystems included Node.js, Python, Java, PHP, Ruby, C/C++, .NET, Android, and iOS — covering the vast majority of typical development stacks.

Multi-container application testing is supported through Docker Compose. By adding a docker-compose configuration to your workflow file, you can spin up a web service alongside its database and run integration tests against both as part of the same CI pipeline.

Matrix Builds: Test Multiple Configurations in Parallel

Matrix builds allow a single workflow definition to fan out across multiple runtime configurations simultaneously. A typical use case is testing against several versions of a language runtime. The configuration is concise — a few lines added to the workflow YAML are enough to instruct GitHub to spawn parallel jobs for each combination in the matrix.

strategy:
  matrix:
    node-version: [14.x, 16.x, 18.x]

steps:
  - uses: actions/setup-node@v3
    with:
      node-version: ${{ matrix.node-version }}
  - run: npm test

GitHub manages job scheduling and parallelism automatically, so teams get faster feedback without having to manage build infrastructure themselves.

Live Logs and Real-Time Feedback

As a workflow runs, GitHub streams log output in real time to the Actions console. Logs are formatted for readability, with support for colour and emoji output from workflow steps. Each individual log line has a stable permalink, making it straightforward to link a colleague directly to a failed test assertion or a specific deployment step when discussing an issue.

Actions and Workflows Are Code

Individual Actions — the reusable building blocks of a workflow — are themselves code. You can write them in JavaScript or package them as Docker container Actions, both of which can interact with the full GitHub API and any other public HTTP API. Workflows are defined in YAML files stored under .github/workflows/ in a repository.

Because Actions are code in a repository, forking a repository also forks its workflow definitions. This gives contributors an immediately runnable CI environment that mirrors the upstream project, lowering the barrier to contribution and making it easier to reproduce build failures locally or in a fork.

Actions can also be shared publicly on GitHub Marketplace and referenced from any workflow by pointing to a repository and tag:

steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-python@v5
    with:
      python-version: '3.11'Code language: JavaScript (javascript)

Trigger Workflows on Any GitHub Event

GitHub Actions is not limited to code-related events. Workflows can be triggered across the full developer lifecycle: push, pull request, issue creation, label changes, release publication, scheduled cron expressions, and more. GitHub Apps can also register custom events, enabling third-party tools and internal platforms to kick off Actions workflows in response to domain-specific activity.

Common automation use cases beyond CI/CD include automatic issue labelling and triage, release note generation, dependency update PRs, and community management tasks such as welcoming first-time contributors.

Integration with GitHub Package Registry

Publishing build artefacts and container images is a standard step in any CI/CD pipeline. GitHub Actions integrates with GitHub Package Registry (now GitHub Packages), enabling workflows to publish and consume packages — including npm packages, Docker images, Maven artefacts, and others — as part of an end-to-end build and deployment process without leaving the GitHub ecosystem.

Suggested Workflows for Faster Onboarding

When you enable Actions on a repository, GitHub analyses the project and suggests starter workflows appropriate for the detected language or framework. This reduces the time from zero to a running pipeline, particularly for teams new to CI/CD or new to GitHub Actions specifically.

Pricing: Free for Public Repositories

GitHub Actions is free for public repositories. This applies to all hosted runner usage on Linux, macOS, and Windows for open source projects. For private repositories, GitHub uses a pay-as-you-go model based on compute minutes consumed, with a free monthly allowance that varies by account plan.

Self-hosted runners — where you supply your own machines and register them with Actions — are free to use regardless of whether the repository is public or private. This option is particularly useful for workloads with specific hardware requirements, air-gapped environments, or large build jobs where hosted runner costs would otherwise be significant.

Self-Hosted Runners and Enterprise Support

For teams running their own infrastructure — whether on-premises virtual machines or cloud instances they manage themselves — GitHub Actions supports self-hosted runners. Installing the Actions runner agent on a machine and registering it with a repository or organisation allows workflows to target that machine using the runs-on: self-hosted label.

At the time of the August 2019 announcement, GitHub also indicated that Actions support for GitHub Enterprise Server was planned for the following year, including a hybrid deployment model where source code and packages remain on-premises while GitHub.com orchestrates the workflow execution.

Getting Started

To add a CI workflow to an existing repository, create a file at .github/workflows/ci.yml. A minimal example for a Node.js project looks like this:

name: CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v3
        with:
          node-version: '20.x'
      - run: npm ci
      - run: npm testCode language: HTTP (http)

Commit and push the file. GitHub will pick it up automatically and run the workflow on the next qualifying event.

Full documentation is available at docs.github.com/en/actions.