Hacker News Reader

Comment by Bnjoroge | Hacker News Reader

Hopefully a good spot to plug my own project, preloop, which is a drop-in replacement of Github actions(both the runners and control plane) that runs locally or self-hosted in isoalted microvms, and supports debug-on-failure. You can also push to the server, run CI and then optionally create a draft PR. Not quite production-ready yet(for the self-hosted part), but the local part works well. We implement the official runner protocol 100% unlike act/gitea/forgejo, so your workflows are more likely to work out of the box with preloop(forgejo has the closest compatibility with Github Actions though so it's a good off-Github option) and we use microvms so no DinD issues. I'm working on getting the official runner vm image up to reduce any environment incompatibilities. Feel free to try it out: https://github.com/preloopdev/preloop

View on HN

Yeah. MicroVMs make hosting runners pretty straightforward. I had codex make a forgejo runner controller which pulls forgejo actions and creates kubernetes jobs for them.

It was a bit of a pain to configure firecracker with k3s.

It really can’t be understated how much easier hosting CI is with microvms as the security boundary.

Agree. I'm always surprised Github still uses huge fat VMs. I imagine this is one of the things that make it much painful at scale. The tricky part with microvms are getting them to run cross-platform. We use an awesome project called smolvm that builds on libkrun and makes this alot easier. As an aside, how have forgejo actions worked for you in practice?

Any other recommendations for microvm ? Need to mess around with them again. Always seemed like the future

If you want something cross-platform, smolvm or microsandbox are great options(built on top of libkrun vmm)! If you are looking for linux-only, the typical choices are firecracker-based solutions.

Re Forgejo actions, I'm just toying around.

Their v15 release (apr 16) really enabled k8s native runners. They added an ephemeral runner API and a bunch of APIs to get jobs. That's what im using to do k8s autoscaling

I'm a little disappointed, because your comment made it look great, but when i look at >1000 commits in 2 months and inspect a few commits randomly, it looks like 100% slopware.

The concept is marvelous, but i'm 100% not trusting slop near my infra, and i'm 100% not trusting people who are not upfront about vibecoding in their README and raise my hopes for nothing.

I suspect most sysadmins, like me, will not trust LLM-generated code within a 10-foot-pole-reach of their servers. You still might be able to convince clueless managers suffering from AI psychosis to go for your solution. But if you'd like to make actual software engineering with a human team, i'm 100% convinced there's actual desire and market for a solution like this to easily get ease the transition path out of Github.

Much of the code was certainly written by agents, as is most of the code now. That said, there's a big difference between "vibe coding" and "agentic coding". The latter requires careful and thoughtful design and review. I've invested heavily in different kinds of guardrails to ensure conformance. An effort like this would not be reasonably feasible without agents or would take significantly longer(act has been around for 5+ years and is still maybe about 70% or so compatible with the official protocol). We'll keep improving it. I hope we'll earn your trust eventually.

The self hosting community is incredibly anti-AI for some reason. I’ve never understood why as using agents has made managing and maintaining my home lab system so much easier.

Nah, LLMs and agentic coding is a reality. It's here, it will stay here, and will only grow.

Reply on news.ycombinator.com