What Is GitHub Actions? CI/CD Explained With Pricing

GitHub Actions is GitHub's built-in automation platform for continuous integration and continuous delivery (CI/CD). It lets a repository build, test and deploy its own code — or run almost any other automated task — using workflows written in YAML and stored right alongside the source in .github/workflows. Instead of wiring up a separate CI server, a workflow fires automatically when something happens in the repository, such as a push or a pull request, and runs on a virtual machine (a "runner") that GitHub provisions and tears down for you.

What Is GitHub Actions?

According to GitHub's own documentation, GitHub Actions is "a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline," directly inside a GitHub repository. That makes it different from a bolt-on CI tool: there's no separate server to connect, no webhook to configure by hand, and no third-party account to link. The automation lives in the same place as the code.

GitHub first showed Actions publicly at GitHub Universe in October 2018 and officially launched it on November 13, 2019, alongside the GitHub Marketplace for sharing reusable automation. In the years since, it has become the default way most GitHub projects run their tests, build their packages and ship releases — and it has expanded well beyond classic CI/CD. Because workflows can respond to almost any repository event, teams also use Actions to label new issues, triage pull requests, close stale conversations and run scheduled jobs, not just to run test suites.

How a GitHub Actions Workflow Works

A workflow is the automated process itself: a YAML file that lives in a repository's .github/workflows directory and defines what should happen and when. A single repository can hold several workflows, and one workflow can even call another. Inside that structure, GitHub's documentation breaks things down into a small set of building blocks:

• Event — the trigger. GitHub defines an event as a specific activity in a repository that starts a workflow run, such as opening a pull request, pushing a commit, opening an issue, or a schedule firing on a timer.
• Job — a set of steps that execute together on the same runner. Jobs run in parallel by default, though you can make one wait on another, and a "matrix" strategy can run the same job repeatedly across different OS or language versions.
• Step — a single task inside a job: either a shell command or an action. Steps in the same job run in order and can share data, since they execute on the same machine.
• Action — a reusable, packaged piece of automation that cuts down on repetitive workflow code. You can write your own custom action or pull a pre-built one from the GitHub Marketplace.

Put together, a typical workflow might trigger on every pull request, run a job that installs dependencies and runs a test suite, and then, only after tests pass on the main branch, run a second job that builds a release and deploys it. Anyone who has containerized an application before will recognize the pattern — Actions workflows frequently build and push Docker images as one of their steps, in much the same way a team might package an app into containers for deployment.

What Is a GitHub Actions Runner?

A runner is the server that actually executes a workflow's jobs, one job at a time. GitHub offers two kinds:

• GitHub-hosted runners — Linux, Windows and macOS virtual machines that GitHub provisions on demand. Per GitHub's documentation, each workflow run executes in a fresh, newly provisioned virtual machine, so there's no leftover state between runs. GitHub also offers larger hosted runner configurations for heavier workloads.
• Self-hosted runners — machines you manage yourself, in your own data center or cloud account. Teams reach for these when they need a specific OS, particular hardware (like a GPU), or tighter network access to internal systems that a GitHub-hosted VM can't reach.

Because self-hosted runners behave much like any other server you control, teams that already orchestrate infrastructure with containers sometimes run their self-hosted runners as pods on a cluster — a use case that overlaps with how Kubernetes schedules containerized workloads more generally.

Actions, Reuse and the GitHub Marketplace

Search engines often shorten this to the "Actions Marketplace," but GitHub's own naming is simply the GitHub Marketplace — a catalog of pre-built actions anyone can drop into a workflow instead of writing automation from scratch. A GitHub for Beginners guide on GitHub's blog notes you can use actions published there to publish a package, greet a new contributor, build and test code, or run a security scan, all with a few lines of YAML referencing someone else's maintained action. You can also publish your own actions to the Marketplace for other repositories to reuse. This reuse model is a big part of why Actions adoption grew so quickly after its 2019 launch — most common CI tasks (checking out code, setting up a language runtime, caching dependencies, uploading build artifacts) already exist as official, maintained actions.

GitHub Actions Usage: How Minutes and Billing Work

GitHub Actions is completely free to use with standard GitHub-hosted runners on public repositories — there's no minutes cap for open-source projects running on GitHub's own VMs. Private repositories are different: every account gets a monthly quota of free minutes and storage for GitHub-hosted runners and Actions artifacts, based on its plan. Usage is deducted by the minute (rounded up), and different operating systems consume the quota at different multipliers, since Windows and macOS runners cost GitHub more to provide than Linux.

Once an account's free minutes for the billing cycle run out, usage is billed per minute at GitHub's standard rates for additional GitHub-hosted runner time, unless spending limits are set to zero. According to GitHub's billing documentation, per-minute rates for standard runners currently include $0.002 for a 1-core Linux x64 runner, $0.006 for a 2-core Linux x64 runner, $0.010 for a 2-core Windows runner, and $0.062 for a macOS runner — reflecting how much more expensive macOS infrastructure is to run at scale.

GitHub Actions Pricing by Plan

The free minutes allowance for private repositories scales with GitHub's account plans. Here's what GitHub's billing documentation and pricing page currently list:

^*GitHub's pricing page lists the Team and Enterprise figures as introductory rates "for the first 12 months," with further terms not spelled out on the page itself — check GitHub's current pricing page before budgeting for a specific seat count. Public repositories, regardless of plan, continue to use standard GitHub-hosted runners for free, and self-hosted runners are always free since you supply the hardware. Minutes reset at the start of each billing cycle and don't roll over.

GitHub Actions vs Jenkins: What's the Difference?

Jenkins predates GitHub Actions by well over a decade. It's an open-source automation server, written in Java and released under the MIT license, that started life in 2004 under the name Hudson. The project was renamed Jenkins in 2011 after a dispute with Oracle over the Hudson trademark; Oracle's own Hudson fork was later donated to the Eclipse Foundation and declared obsolete in February 2017, leaving Jenkins to develop independently. Jenkins joined the Continuous Delivery Foundation in 2019 and reached "graduated" project status there in 2020.

The practical difference comes down to who hosts it and how it's extended. Jenkins is a server you install and run yourself — commonly inside a servlet container like Apache Tomcat, or standalone with its bundled Jetty server — and you extend it almost entirely through its large plugin ecosystem, which covers everything from version-control integrations to test reporting and credential storage. GitHub Actions, by contrast, is a managed service: GitHub hosts (or lets you host) the runners, workflows are defined directly in YAML inside the repository, and reusable logic comes from actions in the GitHub Marketplace rather than installed server plugins.

Neither is strictly "better" — they solve the same CI/CD problem from opposite directions. Jenkins gives a team total control and an enormous plugin catalog built up over two decades, at the cost of having to run and secure the server yourself. GitHub Actions trades some of that flexibility for near-zero setup: if your code already lives on GitHub, a workflow file is often all it takes to get a working pipeline.

What Is GitHub Actions Used For?

Beyond the classic "build, test, deploy" loop, common real-world uses include:

• Continuous integration — running a test suite, linter or type-checker on every pull request before it can merge.
• Continuous deployment — automatically shipping a merged change to staging or production, including building and pushing container images to a registry.
• Release automation — tagging versions, generating changelogs and publishing packages when a release is cut.
• Repository housekeeping — auto-labeling issues, greeting first-time contributors, closing stale threads, and running scheduled maintenance jobs on a cron-like trigger.
• Security checks — running dependency and vulnerability scans as part of the same pipeline that builds and tests the code.

Recent Changes to GitHub Actions

GitHub Actions continues to receive frequent updates through GitHub's changelog. Recent additions highlighted there include a REST API endpoint that reports when support for a given self-hosted runner version is ending, so administrators can plan upgrades ahead of a deadline, and a new, narrower vulnerability-alerts permission for the automatically generated GITHUB_TOKEN, which lets a workflow read Dependabot alerts without broader repository access. Reusable workflows also picked up additional job context properties that identify which workflow file actually defines the running job — useful for debugging pipelines that chain several reusable workflows together.

What's Next for GitHub Actions

GitHub has been steadily narrowing the gap between Actions and standalone CI platforms on permissions, auditability and runner management, while continuing to expand what a workflow can automate beyond pure CI/CD — including early, policy-gated work on agentic and AI-assisted workflows. For a team evaluating it today, the practical starting point is still the same: check the included minutes on your current GitHub plan, read GitHub's own documentation for the exact YAML syntax, and browse the GitHub Marketplace before writing a custom action, since the task you need probably already exists as a maintained one. Developers already using GitHub's other tooling — including GitHub Copilot's free plan — will find Actions sitting in the same repository settings, with no separate account or billing relationship to set up.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage