Running Forgejo privately only really works if the access model stays practical.

That means two things have to feel normal:

  • opening the web UI,
  • and using Git over SSH.

I did not want a "secure" setup that became annoying every time I needed to clone, push, or inspect a repository.

Why SSH Tunnels Fit Well Here

If the service binds locally, SSH tunneling becomes the obvious access method.

That gives a good compromise:

  • the service is not publicly exposed,
  • only people with SSH access can reach it,
  • and the web UI still behaves like a normal local service once the tunnel is up.

That is exactly the kind of tradeoff I wanted for an early-stage private forge.

Git Access Was The More Interesting Part

Web access over a tunnel is straightforward. Git access gets more interesting once repositories and users are not perfectly aligned.

The problem is not only authentication to the remote service. It is also local ownership.

Sometimes a repository lives under a different Unix user than the user who owns the SSH agent.

That is where a brokered Git workflow becomes useful.

Why A Broker Pattern Helped

The broker idea is simple:

  • run the Git operation in the context of the target local user,
  • keep repository ownership correct,
  • but still use the right authentication path for remote Git access.

That solves a very specific operational problem:

how to keep Unix-user boundaries intact without turning Git usage into manual credential juggling.

The Real Value

The combination of:

  • private local binding,
  • SSH tunnels,
  • and brokered cross-user Git commands

turned the setup from a neat concept into something I could actually live with.

That matters more than it sounds.

Self-hosted Git is only worth it if the secure path is also the path you are willing to use every day.