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.

> 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.

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.