One of the clearer decisions in the Forgejo work came from failure rather than design purity.

I wanted to run the Forgejo runner in a container at first. That sounds symmetrical and neat.

In practice, it kept fighting the same class of problem:

  • rootless container engine access from inside another container,
  • socket visibility without reliable usability,
  • and permission behavior that looked close to correct but still broke actual jobs.

Why The Containerized Runner Was Awkward

The basic problem was not "runner starts" versus "runner does not start."

The real question was:

Can the runner reliably control the rootless container engine needed for job execution?

That is where the containerized approach became fragile.

You can make sockets visible. That does not automatically make them usable in a way that stays predictable under real workloads.

Why The Host Runner Was Simpler

Running the runner directly on the host as its own dedicated user removed a whole layer of complexity:

  • no extra container/socket boundary,
  • no awkward nested permission path,
  • and a much more direct relationship between the runner and the rootless container engine.

That is not automatically the right answer in every environment. But for this one, it was the more honest answer.

The Design Principle Underneath It

This was another reminder that "more containerized" is not always "cleaner."

Sometimes the better design is the one that reduces invisible permission translation and keeps the control path shorter.

For rootless container jobs, a host-installed runner fit that principle better than a runner container pretending to be a normal client of the same engine.

What I Kept From This

The useful lesson was not just "host runner works."

It was:

  • treat the runner as infrastructure, not just another app container,
  • give it a dedicated user and a clear execution model,
  • and choose the placement that matches the job engine instead of forcing a more aesthetic layout.

That gave me a runner setup I could actually debug and trust.