explaingit

nektos/act

📈 Trending70,356GoAudience · developerComplexity · 2/5ActiveLicenseSetup · moderate

TLDR

Run GitHub Actions workflows locally on your machine using Docker, without pushing to GitHub. Test and debug CI pipelines instantly instead of waiting for remote runners.

Mindmap

mindmap
  root((act))
    What it does
      Runs workflows locally
      Reads .github/workflows
      Uses Docker containers
    Why use it
      Fast feedback loop
      Debug before pushing
      Task runner alternative
    How it works
      Parses workflow files
      Pulls container images
      Replicates GitHub env
    Use cases
      CI/CD testing
      Build automation
      Linting and tests
    Tech stack
      Go
      Docker
      YAML

Things people build with this

USE CASE 1

Test GitHub Actions workflows locally before committing and pushing to your repository.

USE CASE 2

Debug CI/CD pipeline failures instantly on your machine instead of waiting for remote runners.

USE CASE 3

Use your existing workflow definitions as a local task runner for tests, builds, and linting.

USE CASE 4

Iterate quickly on workflow changes without the commit-push-wait cycle.

Tech stack

GoDockerYAML

Getting it running

Difficulty · moderate Time to first run · 30min

Requires Docker to be installed and running on your machine.

Use freely for any purpose, including commercial use, as long as you keep the copyright notice and license text.

In plain English

act is a command-line tool that lets you run your GitHub Actions workflows directly on your own machine, without having to push code to GitHub and wait for remote runners to execute them. It solves the slow feedback loop that developers face when debugging or tweaking .github/workflows/ files, instead of committing, pushing, waiting, and reading logs on GitHub, you can test your workflows instantly, locally. The way it works is straightforward: when you run act in a repository, it reads your workflow files from the .github/workflows/ directory, figures out which actions need to run and in what order (based on dependencies you've defined), then uses Docker to pull or build the container images each action requires. It then runs each step inside those containers, replicating the environment variables and filesystem layout that GitHub's own hosted runners provide. This means your local test environment closely mirrors what GitHub would actually execute. There are two main reasons to use it. First, for fast feedback during development: rather than treating every small workflow tweak as a full commit-and-push cycle, you can iterate locally in seconds. Second, as a general task runner: since GitHub Actions workflows are just structured YAML scripts, act lets you use them as a replacement for a Makefile or similar build tool, running tasks like tests, builds, or linters directly from the command line. You would reach for act whenever you're authoring or debugging CI workflows, want to test a workflow change before it touches the remote repository, or simply want to reuse your existing action definitions as a local automation layer. There is also a Visual Studio Code extension called GitHub Local Actions that integrates act directly into the editor. The tool is written in Go and depends on Docker being installed and running on your machine.

Copy-paste prompts

Prompt 1
How do I install and run act to test my GitHub Actions workflows locally?
Prompt 2
Show me how to use act to run a specific job from my .github/workflows/main.yml file.
Prompt 3
How do I configure act to use custom Docker images or environment variables for my workflows?
Prompt 4
Can I use act as a replacement for Make or npm scripts to run local tasks defined in my workflows?
Prompt 5
What are the differences between running a workflow with act locally versus on GitHub's hosted runners?
Open on GitHub → Explain another repo

Generated 2026-05-18 · Model: sonnet-4-6 · Verify against the repo before relying on details.