Run your GitHub Actions locally
64 comments
·May 16, 2025ryangg
Ameo
Sounds similar to my own experiences trying to debug GH actions locally.
I've tried twice now to get it working, pulling down many GBs of images and installing stuff and then getting stuck in some obscure configuration or environment issue. I was even running Linux locally which I figured would be the happiest path.
I'm not eager to try again, and unless there's a CI that's very slow or GH actions that need to be updated often for some reason, I feel like it's better to just brute-force it - waiting for CI to run remotely.
jlongman
It’s even worse than that, it’s 20GB compressed and 60GB uncompressed. Regardless, if your VM runs out of disk space there’s no meaningful error (well 12 months ago) except a failure to start. (Possibly colima-specific I dunno I uninstalled docker-docker)
I do find that some things just work locally and fail in real actions and vice versa. For the most part it’s made it easier to move the bar forward though.
suryao
Something like this may help by letting you ssh into the running instance so you can debug with the exact context: https://docs.warpbuild.com/tools/action-debugger
larusso
I had luck with my actions I tried to debug. But I also had the issue that the runtime difference is simply too big to 100% trust it. Too bad because I think the tool is quite good.
Kinrany
Every mention of Github Actions is an occasion to start looking for the best alternative in <current_month>, let's go!
Is Dagger usable yet? Is there still hope for Earthly? Are general purpose workflow systems winning any time soon, or are we still afraid of writing code? Any new systems out there that cover all the totally basic features like running locally, unlike Github Actions?
tomrod
How's Jenkins looking these days?
h4kunamata
With Git Actions at full speed..... it is dying.
hybrid_study
nyuk, nyuk, nyuk
manx
I think we could build something on top of nix that is as easy to use and powerful as earthly, but gets all the nice stuff from nix: reproducibility, caching, just use any command from any nix package, etc
esafak
earthly is config-based, so it's in the same league as GHA in my book. https://docs.earthly.dev/docs/earthly-config
dagger is the only code-based solution. It works, but it does have some edges since it has a much bigger surface area and is constantly growing.
ed_mercer
Can’t beat GitLab
tagraves
In my experience (and as reflected by the comments on this post already), trying to run complex CI workflow locally is a fairly hopeless enterprise. If you have a fully containerized workflow, you might be able to get close, but even then ensuring you have all of your CI specific environment variables is often not a trivial task, and if your workflow orchestrates things across tasks (e.g. one task uploads an artifact and another task uses that artifact) you'll have a hard time reproducing exactly what is happening in CI. My company (RWX) builds a GitHub Actions competitor and we intentionally do not support local execution -- instead we focused on making it easy to kick off remote builds from your local machine without having to do a `git push` and we made it easy to grab an SSH session before, during, or after a running task to inspect things in the exact build environment that your workflow is running.
esafak
For local development you can use .env files and mise. https://mise.jdx.dev/environments/#env-file
I use dagger to read these .env/mise env vars and inject dummy values into the test container. Production is taken care of with a secrets manager.
nomilk
Dumb question, but why hasn’t GitHub made a solution that lets you run GitHub Actions locally? Or at the very least a solution that validates the action (giving a bit more certainty that it will succeed, a bit like a dry-run)?
(My war story:) I stopped using GHAs after an optimistic attempt to save myself five key strokes ‘r’ ‘s’ ‘p’ ‘e’ ‘c’ led to 40+ commits and seeing the sunrise but still no successful test run via GHA. Headless browsers can be fragile but the cost benefit ratio against using GHA was horrible, at least for an indy dev.
immibis
Why would GitHub (a Microsoft service) want you to be less dependent on GitHub? That just makes the extinguishing part harder.
null
timewizard
They do.
Your action can be empty and actions generate webhook events.
Do whatever you want with the webhook.
arclight_
It's important to note that this tool does not use the same container images or runtime environment that GitHub Actions actually runs. It's an approximation.
For simple use cases that won't matter, but if you have complex GitHub Actions you're bound to find varying behavior. That can lead to frustration when you're debugging bizarre CI failures.
plumeria
AWS Lambda publishes Docker images (e.g. public.ecr.aws/lambda/python:3.12-arm64), does Github Actions have something similar?
cadamsdotcom
Rather than tying CI & deployments to Github Actions, it is usually better to pull as much of it as possible out to shell scripts and call them in containers in GH actions..
There are optimizations you’ll want (caching downloaded dependencies etc); if you wait to make those after your build is CI-agnostic you’ll be less tempted by vendor specific shortcuts.
Usually means more code - but, easier to test locally. Also, swapping providers later will be difficult but not “spin up a team and spend 6 months” level.
Cloudef
Nix is in fact perfect for this.
lenova
As a non-Nix user, could you give me an example?
Cloudef
While flakes have their own "checks" thing, what I do is just have a app definition in flake with the required dependencies.
https://github.com/Cloudef/zig-aio/blob/master/flake.nix#L25...
https://github.com/Cloudef/zig-budoux/blob/master/flake.nix#...
The actual GA workflow file is pretty simple: https://github.com/Cloudef/zig-aio/blob/master/.github/workf...
jiggawatts
This is always the top comment in these kinds of threads, and I see this as an indication that the current state of CI/CD is pathetically propriety.
It’s like the dark times before free and open source compilers.
When are we going to push back and say enough is enough!?
CI/CD desperately needs something akin to Kubernetes to claw back our control and ability to work locally.
Personally, I’m fed up with pipeline development inner loops that involve a Git commit, push, and waiting around for five minutes with no debugger, no variable inspector, and dumping things to console logs like I’m writing C in the 1980s.
You and I shouldn’t be reinventing these wheels while standing inside the tyre shop.
ElijahLynn
GitHub really needs to support local development with GitHub actions. Sheesh. What a step backwards.
joshdavham
> GitHub really needs to support local development with GitHub actions.
Agreed. I’m thankful for tools like act, but there really should be an officially supported way to run gh actions locally.
brianhorakh
WARNING: act is great if you use docker. Act does not support podman.
Issues or discussions related to providing support/coverage/compatibility/workarounds for podman are closed with a terse message. Unusual for an open source project.
organsnyder
There's a long-open issue[1] for Podman support. Maybe they're just tired of dups?
joshdavham
What are some recommended alternatives for act, if any?
I’ve been a long time user, but I’ve run into tons of problems with act over the last year and am wondering if there are better alternatives out there.
samgranieri
I’ve been bedeviled by arm/intel/Mac issues with this.
I want to be able to use this project, I really do. But it’s just not yet there, and this isn’t on Nektos. Nektos is, as best I understand it, trying to approximate GHA, but it’s not easy.
jt_b
I've seen (but not used) this tool recently, which seems like it does a similar thing. Curious if it is any better experience.
notnmeyer
like a lot of folks i found nektos lacking. instead, i focused on keeping the gha workflows really light and putting any complexity in Task (taskfile.dev)—that way the meat of the workflows can be run locally, and the gha syntax is just the glue.
it works out very well.
joshstrange
Last time I looked at it, Act was a lot like the “serverless offline” options out there that try to mimic AWS services. If your use case is straightforward then I might work but if you do anything “exotic” (often the types of things I’m trying to debug in a failed run) Act doesn’t fully replicate the GHA experience.
Also, understandably, there is no macOS support and I use macOS on GHA for iOS builds (another place I have to debug that this wouldn’t cover).
Just this week I tried giving this another chance to debug some weird CI failures for ruby tests. I’m on M-series macs so there is an inherent platform mismatch. That coupled with us using depot images as action runners. I was never able to get it running past the dry-run stage. There is just a lot of differences between CI runners and my local docker images. I even gave the image from catthehacker a try. Which is like >15GB. It still wouldn’t run. Finally gave up.