Act v0.2.89 runs workflow jobs before you push
Act v0.2.89 reads .github/workflows, selects the jobs triggered by an event, resolves their dependencies, and runs the required actions inside local containers. With no event argument, it uses push and runs every matching workflow. That shortens the feedback loop for a YAML edit or a locally developed action. It can also make a workflow double as a task runner, which is handy when the hosted definition already contains the commands a developer needs.
The checkout we measured was 1.4 MB with 417 files and about 34,992 source lines. Act is a Go command-line program rather than a second CI service. It obtains actions and runner images, sets familiar environment values, mounts the repository, and asks the Docker Engine API to run each job. The distinction matters: local execution is an interpretation of GitHub's format, not access to the hosted runner fleet or its surrounding service.
An ubuntu-22.04 job normally needs Docker Engine
An ubuntu-22.04 workflow normally runs in a Linux container selected through a platform mapping. The installation guide names the Docker Engine API as the standard requirement. A compatible remote engine can be selected through DOCKER_HOST, including an SSH endpoint. Podman exposes a compatible socket and may work, but the same guide says the project does not guarantee it. Teams standardized on Podman should test their exact workflows before adding Act to required developer tooling.
The official runner guide says its default images intentionally omit tools that GitHub installs on hosted runners. Its fuller alternative is documented as larger than 18 GB, and even that cannot erase every difference between a virtual machine and a Docker container. Systemd is the clearest example named in the guide. A local failure can therefore describe the image rather than the workflow, while a local pass cannot prove the hosted job will behave identically.
What happened when we ran it
Our sandbox installed 145 Go packages in 41 seconds, then completed the build in 48 seconds. The checkout at commit 4f41128 had 5 CI workflow files, no Dockerfile, and no tests directory. Those results came from an unprivileged golang:1.24-bookworm container with 3 CPUs, 8 GB of RAM, and no secrets. Installation and compilation were clean; the test stage was not.
The Go test command exited 1 after 106 seconds, with 4 passes and 3 failures out of 7 results. The failing names were TestRunActionInputs, TestRunEventPullRequest, and TestRunMatrixWithUserDefinedInclusions, all under pkg/runner. The supplied log tail showed their names and the package failure, but no assertion message or cause. The defensible finding is limited: commit 4f41128 did not pass its full test command in our fresh environment.
Local events and secrets require explicit input
Act v0.2.89 cannot receive GitHub's automatic GITHUB_TOKEN on a developer machine. A workflow that needs repository access may require a personal token passed as a secret. The guide recommends act -s GITHUB_TOKEN without an inline value, which reads the environment or opens a secure prompt. It warns that putting a secret directly in the command can save it in shell history. Variable files and secret files use an env-style format and need the same storage care as any credential file.
Event context also needs attention. A pull-request simulation may require 2 refs, head and base, in a JSON event file; a tag push needs the appropriate ref. You can narrow a run to one workflow with -W, one job with -j, or selected matrix values with --matrix. The ACT environment variable lets a workflow skip a local-only step, such as a notification. These controls are useful, though each creates another difference from the hosted path.
v0.2.89 still leaves several GitHub fields unfinished
Act v0.2.89 covers the common shape of jobs and steps, but its unsupported page names consequential omissions. Workflow concurrency and run names are ignored. Job permissions, timeouts, cancellation, and continue-on-error behavior are missing or ignored. The GitHub context is incomplete, OIDC has no URL, and deployment-environment secret scoping is unsupported. A team should scan that list against its workflow before treating a local green run as evidence for release.
Artifacts show how compatibility moves underneath a local runner. The user guide says the built-in artifact server must be enabled with a path and claims v3 and v4 upload and download support within the current run. Cross-run and cross-repository downloads are outside that claim. Open issue 6173 reports that a direct v7 upload followed by a v8 download loses the original filename because response metadata is not preserved. That is a concrete reason to keep artifact checks on GitHub.
71,959 stars coexist with 380 open issues and pull requests
GitHub showed 71,959 stars, 266 open issues, and 114 open pull requests on September 13, 2026. The last code push was August 9, while the latest release, v0.2.89, arrived June 1. Issue activity continued after both dates: an ARM64 host-execution bug was filed September 10, and pull request 6182 proposed a fix the same day. The project is receiving current reports and patches, although the combined queue is large enough that fixes may wait.
Release v0.2.89 points to the same 4f41128 commit we measured. It contains a dependency update and a version bump rather than a long feature release. Current open reports cover runner architecture, concurrent action-cache access, runner-image differences, artifacts, and newer workflow schema fields. That range fits a mature compatibility project chasing a moving target. It also explains why a version with broad adoption can still produce edge cases in ordinary workflows.
Use Act for local confidence and GitHub for the final run
Actionlint is the lighter choice when you only need static workflow checks. GitHub's official Actions Runner is the better fit when a registered machine and service-controlled execution are acceptable. Act sits between them: it can execute substantial workflow logic without a push, but it carries a local runner model you must configure and distrust in specific, documented ways. Our 48-second build and 3 failed test results support that narrower role.