I’ve moved to self hosted gitea a year ago running in my homelab and not publicly accessible. No https, registrations disabled and repos are not public.

I’m thinking about making public instance and use it with https, but minimize the attack surface, any recommendations especially about gitea/forgejo?

▲

eblume 3 hours ago | parent | next [-]

Yup, I’ve done this. I use a fly.io proxy that runs nginx, fail2ban, and that forwards to my tailnet where Caddy resolves to the actual instance. It’s critical that you disable local registration - I have authentik (only available on the tailnet) as an IdP but you can also just disable reg after making your own account of course. I also have a robots.txt that disables some stuff like all the individual rendered git commit views otherwise scrapers get stuck in an endless loop and also I strictly forbid access to the forgejo package repository since I have some private packages and the permission granularity there is not what I want it to be, still dialing that in. I’m keeping an eye on it and so far nothing terrible has happened. docs.eblu.me if you would like details… I could also link straight to the infra code if you like.

▲

import 3 hours ago | parent [-]

Hey thanks for the answer and link to docs. I don’t use tailscale, it’s running in a NUC, accessible with wireguard for now. (Docker + 4 runners)

I try to keep things simple in the homelab and thinking only using fail2ban and caddy reverse proxy and expose it.

Package registry isn’t private by default and accessible with PAT. Or am I mistaken?

	▲	eblume 3 hours ago \| parent [-]
		You’re welcome! I only ran in to this last week and I might not have this straight yet because I haven’t had time to sit and untangle it. I have a private repo that has a release workflow that publishes a Python package to the forgejo package repository using my public user profile. I mistakenly assumed that because the repo was private the package would be as well but that link is not enough to set public/private and it is instead fully public. Listable and everything, no PAT needed. This is where I’m less clear: I think I could make my user profile private and this would hide the packages, but I want my profile public. So I just black-holed the entire packages api outside of the tailnet.

▲

embedding-shape 3 hours ago | parent | prev | next [-]

> I’m thinking about making public instance and use it with https, but minimize the attack surface, any recommendations especially about gitea/forgejo?

I've done this too in the past, I'm still running the internal/lan Forgejo instance, but not any public instance at the moment. But in the past, I've setup a public read-only instance, which mirrors my internal one, then one reverse-proxy connection from the internal to the public instance, which the public one uses for getting the git data. Then it mostly just kept on working by itself, whenever I changed anything in the internal Forgejo, the public one got updated, yet I could keep all issues, CI and more completely private and on lan.

▲

lloydatkinson 2 hours ago | parent | prev [-]

When I adopted Foregjo I did so because I didn't like the sound of some political arguments across threads about some alleged security issues Foregjo raised with Gitea who allegedly ignored them.

What keeps you using Gitea? I'm wondering if I should try it over Foregejo now.

	▲	import an hour ago \| parent [-]
		Nothing special. I am aware of the discussions for so long. I mostly spend my time making music with modular synths and migration to forgejo is not a priority right now, I don’t want to touch the setup. If you’re on forgejo I don’t think there’s any reason to try the gitea.