9

I have Forgejo working pretty well. I also have a Forgejo runner running workflows successfully using a Docker-in-Docker system running in Kubernetes. This works pretty well and I like it, but I'm starting to run into some challenges with more advanced workflow use-cases.

For example, I only have one runner so jobs stack up. I wasn't sure how to implement multiple runners given that each runner needs to save a static token. I saw some references to ephemeral runners. Does anybody use auto-scaling or multiple-instances such as with ephemeral runners?

Additionally, using docker-in-docker has some issues. The Docker daemon gets persisted across jobs so the output images stack up and I have to periodically run docker system prune inside the runner. Trying to run docker commands that require logging in inside the workflow also conflicts with Forgejo's own control of the Docker Daemon.

Does anybody else run into these kinds of issues and have a good strategy? There was this issue about using firecracker micro-vms which could have fixed the d-in-d issues, but no recent updates.

you are viewing a single comment's thread
view the rest of the comments
[-] moonpiedumplings@programming.dev 1 points 14 hours ago

Finally found this post after a few minutes of searching:

I came across this: https://github.com/cloudbase/garm , which is gitea (probably compatible with forgejo) actions using Incus containers/virtual machines, or on kubernetes directly.

It looks like it's possible to create an alternate implementation of the forgejo actions runner, which doesn't uses different methods of execution.

this post was submitted on 02 Jun 2026
9 points (100.0% liked)

Forgejo

324 readers
13 users here now

This is a community dedicated to Forgejo.

Useful links:

Rules:

founded 2 years ago
MODERATORS