act: Run GitHub Actions Locally with Docker, and What It Costs You
Run your GitHub Actions locally 🚀
At a glance
- What is it?
- act is a Go-based CLI that executes GitHub Actions workflows on your machine via Docker. It gives fast feedback on workflow edits and can replace a Makefile, but it depends on Docker and may not match GitHub's hosted runners exactly.
- Who is it for?
- Adopt act if you spend significant time iterating on .github/workflows or want a Makefile replacement that reuses your existing CI definitions. Skip it if you cannot run Docker on your machine or if your workflows depend on GitHub-hosted runner specifics that act does not emulate.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 37 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem: Slow CI Feedback Loops and Makefile Duplication
Developers who edit GitHub Actions workflows know the pain: every change to a YAML file requires a commit and a push, then waiting for the runner to spin up. act solves that by running the same workflows on your local machine. The README states two reasons to use it: fast feedback and using it as a local task runner. For the second reason, the author says they love make but hate repeating themselves. With act, you can replace a Makefile with your existing GitHub Actions definitions. This targets developers who already use GitHub Actions and want to shorten the edit-test cycle or unify their task running under one configuration.
How act Executes Workflows: Docker Under the Hood
The mechanism is straightforward. When you run act, it reads the workflow files from .github/workflows/ and determines which actions need to run. It uses the Docker API to pull or build the images defined in the workflow. Then it computes the execution path based on dependencies between jobs. After that, it runs containers for each action using those images. The README claims that environment variables and filesystem are configured to match what GitHub provides. That is a strong claim, and the reality is that matching GitHub's hosted runner environment exactly is hard. But the architecture is clear: act is a Docker orchestration layer on top of your workflow definitions.
Getting Started: Build from Source or Use the User Guide
The README gives manual build instructions. You need Go tools 1.20 or later. Clone the repo with git clone git@github.com:nektos/act.git. Run unit tests with make test. Build and install with make install. There is also a user guide at nektosact.com, which is the primary documentation. The README does not mention package managers or prebuilt binaries, so the only concrete installation path in the README is from source. If you are not comfortable building Go projects, you should check the user guide for other options. The VS Code extension, GitHub Local Actions, is mentioned as a way to run act from the editor, but the README does not give installation details for that either.
Where act Falls Short: Docker Dependency and Environment Gaps
The most obvious limitation is that act requires Docker. If you are on a machine without Docker, or in a restricted environment where Docker is not allowed, act is useless. The README assumes Docker is available. Another limitation is that act approximates GitHub's environment, not replicates it. The README says environment variables and filesystem are configured to match, but that is a best-effort. GitHub-hosted runners have specific software, caches, and system configurations. A workflow that relies on a tool preinstalled on the hosted runner may fail locally if that tool is missing from your Docker image. act is also not a full runner emulator: it does not run the actual GitHub runner software, it simulates the execution. For complex workflows with many services or matrix builds, the local behavior may diverge.
Alternatives: What Else Can You Do?
The direct alternative is to use GitHub-hosted runners and rely on the commit-push-wait cycle, which act aims to eliminate. Another alternative is to use a CI platform that runs locally, like Jenkins or GitLab CI with a local runner. Those tools have different models: they are not tied to GitHub Actions syntax. If you want to keep your CI configuration in GitHub Actions, act is the only tool in this material that does that. If you want a general task runner, you could use make, which act explicitly positions as a replacement. The difference is that act reuses the same YAML workflow files you already have for CI, while make requires a separate Makefile. That is a trade-off: act saves you from duplicating logic at the cost of a Docker dependency and potential environment mismatches.
Maintenance and License: MIT and Active Releases
act is licensed under MIT, which is permissive and allows commercial use without restriction, though you should read the license text for details. The repository is not archived, and the last push was on 2026-06-01, with a release v0.2.89 on the same day. The release cadence appears to be monthly, with v0.2.88 in May and v0.2.87 in April. That suggests active maintenance. The project is written in Go, so building from source requires Go 1.20+, which is a reasonable requirement. Upgrading act is not covered in the README, but with a monthly release cycle you will likely want to track new versions to get bug fixes and workflow feature support. The cost of maintenance is low if you install via a package manager, but the README only gives source build instructions, so you may need to rebuild periodically.
Editorial conclusion
Adopt act if you spend significant time iterating on .github/workflows or want a Makefile replacement that reuses your existing CI definitions. Skip it if you cannot run Docker on your machine or if your workflows depend on GitHub-hosted runner specifics that act does not emulate. Before relying on it, verify that your actions' container images are compatible with your local Docker setup, and test a representative workflow to see if environment variables and filesystem behavior match your expectations. act is a practical tool, but it is not a perfect GitHub runner clone.
Community notes