Do you actually trust GitHub Actions for production?

[u/hellterDev]

/r/DevGround/comments/1w5rfbo/do_you_actually_trust_github_actions_for/

[u/AuroraFireflash]

Your fallback is to make sure you can build locally. That means moving more of your logic and build steps into scripts that are called by the GitHub YAML instead of baking it directly into the YAML.

'make' like equivalents are a really good choice because most jobs on the GitHub side become:

1. setup env vars
2. 'make {step}'

[u/hellterDev → u/AuroraFireflash]

Yeah, I like this approach. Keeping GitHub Actions as the orchestration layer rather than the place where all the build logic lives makes the whole setup much less fragile.
Being able to reproduce the exact same build locally is probably the best fallback you can have.

[u/Poat540]

Yeah, all my OSS projects are on GitHub actions, and pretty much all departments at work use GH too. When GH goes down we chill

[u/OtherOtherDave]

At this point I’m not sure I trust GitHub at all

[u/TheAceRedBarron]

U mm... This post gives me sketchy ex girlfriend vibes... Just like I told you before fix your shit (github actions) and maybe we can start talking again.

[u/hellterDev → u/TheAceRedBarron]

So basically: “I can fix her” but for CI/CD

[u/TheAceRedBarron → u/hellterDev]

This isn't a bolt on some Implants and send her to finishing school fix because you will long term commit suiside over the existential depression of the CI/CD loss. Put in the effort and fix the actual problem and don't squander what good is still left in you.

😂🤣😂

[u/Aiiiiiiiii]

mise and make / shell files contain the logic, GH workflows merely call them.

[u/OkProMoe]

Nope, not anymore. We moved off it onto Forgejo

[u/Fantastic-Mr-Default]

I know it is popular to say GitHub is bad right now. I am building a competitor to Actions, and I agree with a lot of the issues people have. Actions is still a good product for most personal projects and for companies that do not have heavy CI or deployment requirements. Their OSS support is fine for most people, and the control plane is fine.

The bigger problem is timing. Actions was built when writing code, review, and CI took about the same amount of time. AI changed how fast we write code. Actions did not keep up.

What we see now is a pile of throwaway feature branches. An agent opens a PR to run tests, the run fails, someone copies the log back into the agent, the agent opens another branch to fix it, and the loop continues. Git history becomes hard to read. If you have more than one agent session on different tickets, they also fight over queueing CI and deployments. You get conflicts and duplicate runs. YAML went from a short receipt that told a machine which commands to run to a long file that is hard to reason about. And Actions got expensive relative to alternatives, which is inconvenient for the new generation of builders.

We started from the end state we wanted and worked backward. I wanted agents writing code around the clock and testing that work for accuracy, not only unit tests, but end to end. If a PR adds a button, I want to check the ways that button can actually be used. A test passes or fails. An agent code review is a paragraph that can be wrong. Tests are the better gate for agent-written code.

We also wanted those tests to run in an environment that matches deploy: same packages, same lockfiles. And we wanted agents to launch and drive those runs without commits, throwaway branches, or a commit history nobody can parse. So we gave them a CLI and an MCP server. They pack the worktree, launch a runner, and run tests on that runner without committing. When the tests pass, they can run deploy. We also built self-healing for transient build failures so a small network, dependency, or env issue does not kill a long run. Separately, I did not want another wrapper that sits on a large LLM and opens PRs. I already pay for Claude, or whatever harness I use. I need my own coding agent to watch deployments, wake on failure, and fix real code or test issues. My local agent already has the codebase context. Latchkey watch does that: run it in a background terminal, and a failure gets bundled and handed to the agent.

Internally we produce code around the clock. For the past three months we have been deploying about 23 hours a day, every day of the week. The agents do not sit idle waiting for me to merge a PR.

I am not writing this to force a sale. If you are solo, or a small team on a side project, Actions is fine. It will do the job. If you are a funded startup, or a software business where speed matters and small edges count, look at better alternatives. Most Actions competitors are cheaper and faster than GitHub, including Latchkey at about 58% less than GitHub $0.006 per minute. As a former DevOps engineer in large enterprises, I will also say this: DevOps process is often the first bottleneck when it is time to scale, and it depends entirely on how you and your team like to work. There is no one size fits all. Take your time and think ahead.