DEV.co
Open-Source DevOps · nektos

act

Act is a tool that lets developers run GitHub Actions workflows locally on their machine using Docker, eliminating the need to commit and push code repeatedly to test CI/CD changes. It mirrors GitHub's environment and filesystem, making local testing faster and more convenient for workflow development and debugging.

Source: GitHub — github.com/nektos/act
71k
GitHub stars
2k
Forks
Go
Primary language
MIT
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
Repositorynektos/act
Ownernektos
Primary languageGo
LicenseMIT — OSI-approved
Stars71k
Forks2k
Open issues344
Latest releasev0.2.89 (2026-06-01)
Last updated2026-07-03
Sourcehttps://github.com/nektos/act

What act is

Act is a Go-based CLI tool that parses .github/workflows/ YAML files, uses the Docker API to pull or build container images, and executes workflow jobs in Docker containers with GitHub-compatible environment variables and filesystems. It determines execution paths based on workflow dependencies and replicates GitHub's runner environment locally.

Quickstart

Get the act source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/nektos/act.gitcd act# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Rapid GitHub Actions Development & Testing

Developers can iterate on workflow files (.github/workflows/) without repeated commit-push-wait cycles. Test logic changes, environment variables, and job dependencies locally in seconds instead of minutes per CI run.

Local CI/CD Validation Before Merge

Engineering teams can validate entire workflow execution on developer machines before pushing to main branches, reducing failed CI builds and merge queue bottlenecks in high-velocity teams.

Workflow Documentation & Onboarding

Teams can use act to document and demonstrate CI/CD workflows as executable local tasks, replacing or supplementing Makefiles. New developers can understand and test workflows without GitHub infrastructure access.

Implementation considerations

  • Docker daemon must be running on the developer machine; requires Docker Desktop or equivalent Docker installation.
  • Workflow execution may be slower than native GitHub runners due to container overhead; plan for 30-60 second startup per job in typical scenarios.
  • Environment replication is close but not perfect—some GitHub-specific context variables (e.g., github.server_url, runner metadata) may require manual mapping or stubbing.
  • Action versions and container images must be available locally or pullable at runtime; offline workflows require pre-caching of Docker images.
  • Permissions model differs: local containers run with the developer's user context, not GitHub's isolated runner permissions—test security-sensitive workflows carefully.

When to avoid it — and what to weigh

  • Workflows Require GitHub-Only Secrets or APIs — Workflows that depend on GitHub environment secrets, branch protections, PR statuses, or GitHub API calls may require workarounds. Local environment variable substitution is possible but not transparent.
  • Complex Multi-Runner or OS Matrix Builds — Workflows using windows-latest, macos-latest, or specialized runners may not fully replicate on a single developer machine. Docker-based runners are well-supported; native runners require additional setup or emulation.
  • Workflows with External Service Dependencies — If workflows depend on external databases, APIs, or cloud services not available locally, act cannot simulate those environments. Integration tests may fail without service mocking or Docker Compose setup.
  • Production CI/CD Pipeline Replacement — Act is a local development tool, not a replacement for GitHub Actions in production. It does not integrate with GitHub's PR, branch, or deployment contexts; use it for local validation only.

License & commercial use

MIT License (OSI-approved). Permits commercial and private use, modification, and distribution with proper attribution and no warranty.

MIT License explicitly permits commercial use. No commercial restrictions identified in license terms. However, verify your internal policies regarding dependency vetting and support expectations for open-source tools in production development workflows.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceActive
DocumentationAdequate
License clarityClear
Deployment complexityLow
DEV.co fitGood
Assessment confidenceHigh
Security considerations

Act executes arbitrary Docker containers and workflows defined in .github/workflows/. Workflow files can run untrusted code; review workflows before local execution. Docker container access required—verify Docker daemon security configuration on your system. No explicit security audit or penetration test data provided; review code or security advisories for details on handling of secrets and sensitive environment data.

Alternatives to consider

GitHub Actions (cloud/native)

Official platform; full fidelity with production environment, integrated PR/branch context, no local setup required. Trade-off: slower feedback loop, requires push to test.

Local task runners (make, just, taskfile)

Simpler, language-agnostic task execution without Docker overhead. Trade-off: no GitHub Actions syntax reuse, manual environment setup, less feature parity with CI/CD.

GitLab CI (.gitlab-ci.yml local runner)

GitLab Runner + gitlab-runner exec for local CI testing. Trade-off: GitLab-specific; different workflow syntax, requires separate runner setup.

Software development agency

Build on act with DEV.co software developers

Use act to test CI/CD changes locally, reduce deployment cycles, and validate workflows before pushing to production. Contact our DevOps specialists to integrate act into your development pipeline.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

Related on DEV.co

Explore the category and the services that help you build with it.

act FAQ

Can I run act workflows without Docker?
No. Docker API is required to execute workflows in containers. Act does not support native process execution; Docker Desktop, colima, or equivalent is mandatory.
Do I need to modify my .github/workflows/ files to use act?
Not typically. Act reads standard GitHub Actions YAML syntax. Some workflows may need environment variable stubs for GitHub secrets, but no code changes are required.
Is act safe to run on production or CI agents?
Act is designed for local development. Running it on production or shared CI agents requires careful security review—workflows can execute arbitrary code in Docker containers with system access.
Why is my act workflow slower than GitHub Actions?
Docker container startup, image pull/build, and lack of GitHub's optimized runner hardware account for overhead. Typical jobs see 30-120 second additional latency; caching helps.

Work with a software development agency

DEV.co helps companies turn open-source tools like act into production software. Our software development services cover the full lifecycle — architecture, web development, integration, and maintenance — delivered by software developers and web developers who ship. Engage our software development agency to implement or customize it for your open-source devops stack.

Accelerate Your GitHub Actions Workflow Development

Use act to test CI/CD changes locally, reduce deployment cycles, and validate workflows before pushing to production. Contact our DevOps specialists to integrate act into your development pipeline.