The runner and the workspace.
Runnr uses nektos/act to execute GitHub Actions locally. The native Mac app brings run setup, live logs, results and retained evidence around that engine.
What runs your workflow
act is an independent open-source project. It reads GitHub Actions workflows, resolves their execution path and normally uses Docker to run them. Runnr delegates execution to act; it does not replace your steps with a different test runner.
The released native Runnr 0.4.3 app can install a managed act 0.2.89 binary in Runner & app settings. Its release archive is checked against a pinned SHA-256 digest. You do not need a global act installation to use that managed runner.
Runnr’s default engine maps Ubuntu runner labels to catthehacker/ubuntu:act-* Docker images. You can choose a Full or custom image and configure mappings for concrete runner labels. Read act’s runner image documentation when a workflow assumes tools provided by GitHub’s hosted VM.
What Runnr adds
| The task | In Runnr |
|---|---|
| Configure a run | Discover workflows, choose workflow or local-job scope, supply events and inputs, and execute static matrices. |
| Follow execution | Search live logs, inspect Results, compare measured performance and keep local run history. |
| Investigate a failure | Read supported test, compiler and runtime diagnostics with source and log links when available. |
| Repeat the right checks | Restore the previous setup for review with Run again, or request failed-job reruns through CLI/MCP. |
| Supply credentials | Encrypt saved secrets with a Keychain-protected key. Import GitHub variables and share encrypted team bundles. |
| Connect a coding agent | Use the CLI or MCP interface, with desktop approval for run requests by default. |
Runnr is a paid desktop product built on act. You can also install and use act directly if a command-line workflow meets your needs.
Using act directly
With act installed on your PATH and Docker running, the following commands list workflows for push, then run the test job from a specific workflow. Replace the path and job ID with ones that exist in your repository.
act -l push
act push -W .github/workflows/ci.yml -j testThese are act commands. The official act usage guide documents events, workflow paths, job selection and inputs. Copy Runnr’s own CLI command and MCP configuration from Runner & app settings; keep Runnr open. Its CLI supports projects, workflows, runs, run, batch, rerun-failed, status, logs, cancel and wait. Requests need desktop review by default, with deployment approvals kept separate.
Local execution snapshots
Running checks does not rewrite the repository’s workflow files. Runnr may generate a separate execution workflow for local checkouts, selected jobs, approval gates and supported container adaptations. Open the run’s Workflow tab to inspect the execution snapshot.
In Local jobs mode, unselected jobs are excluded, selected jobs’ top-level conditions are bypassed and dependencies on omitted jobs are removed. That makes a useful local build or test scope, but it changes what was verified. Step conditions and dependencies between selected jobs remain in place.
In Workflow mode, trigger conditions and dependencies are retained. Event payloads, services and actions still depend on act’s compatibility. Reusable workflows, preset/watch controls, interactive step debugging, the Electron dependency graph and automatic retries are outside the native 0.4.3 release.
What stays on GitHub
act does not reproduce the whole GitHub-hosted environment. In particular, hosted toolsets, OIDC, token permissions, environment policies and concurrency behaviour have differences. The compatibility guide explains what to check before trusting a local result.
Optional Runnr GitHub integration uses the active GitHub CLI account and can publish eligible commit statuses and redacted PR comments. It rechecks the account, clean checkout and exact PR commit before writes; dirty or divergent checkouts stay local. Separate status contexts identify partial-job scopes. Expanded Git tools are upcoming.
Moving development checks locally can reduce hosted runner usage, but Runnr does not automatically disable or cancel hosted workflows. Savings depend on your repository’s triggers, required checks and usage. Keep the hosted verification your project needs.
Try your workflow
Follow the local setup guide, then use native results and logs to investigate a failure. For the engine’s behaviour and limitations, start with the act documentation.