GitHub Actions

CI/CD built into GitHub: YAML workflows in the repository run on GitHub’s VMs or your own machines whenever something happens in the repo.

What it is: CI/CD pipelines
Type: Commercial product
Made by: GitHub (Microsoft)
License: Proprietary (the self-hosted runner agent is MIT)
Facts checked: 5 October 2026

What it is

A workflow is a YAML file in .github/workflows/. It names the events that trigger it (a push, a pull request, a schedule, a manual click) and lists jobs. Each job runs on a runner, and on GitHub-hosted runners every job gets a fresh virtual machine with Linux, Windows or macOS (the small single-CPU runners use a container instead). Jobs run in parallel unless one needs another; the steps inside a job run in order and share its disk.

What sets it apart is that it lives where the code already is. There’s no separate CI server or account, results show up on the pull request, and steps can be reusable actions from the Marketplace, such as actions/checkout or a cloud provider’s login action. A job can request an OIDC token from GitHub and swap it for short-lived cloud credentials, so no long-lived cloud keys need to be stored as secrets. Self-hosted runners let jobs run on your own machines or inside your network.

Why teams pick it

No extra service to run or connect: workflows, logs and status checks sit next to the code and pull requests
Free for public repositories and on self-hosted runners; private repositories get 2,000 minutes a month on the Free plan
Huge Marketplace of ready-made actions, plus matrix builds of up to 256 jobs across OS and runtime versions
OIDC federation with AWS, Google Cloud and Azure removes stored cloud keys

Watch out for

A job on a GitHub-hosted runner is cancelled after 6 hours
Third-party actions run with your job’s token and secrets; pin them to a full commit SHA, as GitHub’s security guide recommends
Workflows are hard to test locally, so debugging often means pushing commits and waiting
Tied to GitHub: moving to GitLab or another host means rewriting the pipelines

Alternatives

What all ci/cd pipelines have in common →

Argo CDOpen sourceGitOps delivery for Kubernetes: a controller in the cluster keeps what’s running identical to the manifests in a Git repository.

How it fits with other technologies

What GitHub Actions uses

What uses GitHub Actions

Run terraform plan on every pull request, with no stored AWS keys · yaml

on: pull_request
permissions:
  id-token: write   # lets the job request an OIDC token
  contents: read
jobs:
  plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/gha-terraform-plan
          aws-region: eu-west-1
      - uses: hashicorp/setup-terraform@v3
      - run: terraform init -input=false && terraform plan -input=false

See it in a real stack

No architecture uses GitHub Actions yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2018–2026

Until 2018, GitHub left building and testing code to separate CI services, which reported their results back to pull requests through its APIs. At GitHub Universe in San Francisco on October 16, 2018, while Microsoft’s purchase of GitHub was still being completed, GitHub announced Actions as “your workflow: built by you, run by us”. Sam Lambert, its head of platform, said it would “do for software development what we did for the pull request.”

The first version was a limited beta built on Docker containers. Workflows were written in HCL and could react to 26 kinds of repository events, and users could share the steps as reusable actions. It wasn’t yet a CI system, and GitHub said it got “clear feedback from almost everyone: you want CI/CD!” In August 2019 it relaunched Actions with YAML workflows, matrix builds and hosted Linux, macOS and Windows machines, free for public repositories, and stopped running HCL workflows on September 30. General availability followed on November 13, 2019.

The runner that executes jobs is a fork of the Azure Pipelines agent from GitHub’s new parent company, and GitHub hosts its Linux and Windows runners on virtual machines in Microsoft Azure. In 2021 Actions added OpenID Connect tokens, so jobs could deploy to clouds with short-lived credentials instead of stored keys.

Why it’s built this way

Live inside the repository, triggered by its events: Workflows are files in the repo and can react to many kinds of repository events, not just pushes, so automation travels with the code: fork a repository and you fork its actions too.
Reusable, shareable actions: GitHub set out to apply open-source principles to workflow automation. Any repository can publish an action that others reference in one line, which is also why pinning third-party actions to a commit matters.
Reuse the Azure Pipelines agent: Rather than writing a new build agent, GitHub forked the one behind Microsoft’s Azure Pipelines for its runner, and hosts its Linux and Windows runners on Azure.

Timeline

2018
Announced in limited beta at GitHub Universe in October
2019
Relaunched in August with CI/CD and YAML; HCL workflows retired in September
2019
Generally available on November 13
2021
OIDC tokens let workflows deploy to clouds without stored secrets
2026
Prices for GitHub-hosted runners cut by up to 39% in January

Sources7 · facts checked 5 October 2026

Improve this page on GitHub