Why I Started Forgejo as a Private Service
When I started thinking seriously about self-hosting Forgejo, I did not want the first step to be "put another public service on the internet."
I wanted the first step to be operationally boring:
- keep the web interface private,
- use SSH or VPN for admin access,
- let a public forge stay the outward-facing mirror,
- and only expose what actually needed to be exposed.
Why I Took The Private-First Route
This was mostly about reducing the number of things I had to solve at once.
If Forgejo starts life as a public service, you immediately inherit questions about:
- public reverse-proxy hardening,
- registration policy,
- bot traffic,
- login exposure,
- and how much trust you place in a brand-new service layout.
By keeping the web side local at first, I could concentrate on:
- repository management,
- internal workflows,
- runner behavior,
- and Git access.
That is a much cleaner starting point.
The Practical Model
The operating model I wanted was simple:
- the Git service runs on the VPS,
- the web UI is reachable only through private access methods,
- repositories can still be mirrored outward when needed,
- and automation can still run locally on the same host.
That gave me most of the benefits of self-hosting without forcing immediate public exposure.
Why This Fit The Rest Of My Infrastructure
This decision also matched the rest of how I was already building services:
- narrow exposure first,
- explicit user boundaries,
- and infrastructure that becomes public only when the operational model is clear.
Forgejo did not need to be special. It could follow the same pattern as the rest of the stack.
What I Liked About This Decision
The biggest advantage was psychological as much as technical.
A private Forgejo instance is easier to iterate on because mistakes stay inside your own operating boundary.
That makes it easier to test:
- config changes,
- SSH behavior,
- runners,
- mirrors,
- and backup flows
without every change also being an exposure decision.