Yes if you’re collaborating with 10 people in the same project, otherwise non sense.

CI/CD, package registry, issue tracking in one place?

Fair enough for the formers.

Issue tracking though...

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?

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.

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?

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.

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.

I'm one of the project leads of Gitea (and am paid for some of my work on Gitea), and here are some more details around the specific incident you are talking about: We were alerted to an issue, and investigated provided a patch, and then waited until the end of the embargo to release the next version with the fix. It turns out they had sent a follow up after our response to them that, due to their usage of an email relay that gets blocked for spam often, went into the spam box for all of the maintainers on the security team (across multiple mail providers). We informed them of this and they still haven't corrected the record on their blog post. This is after previously giving us 10 and 2 day "embargoes" on "severe" issues and a multi-hundred line patch that rewrote core portions of the codebase and introduced issues in itself, we notified them of this and provided them with out patch. In our interactions with them we have also followed our documented approach, that we have followed with codeberg previously (that we were thanked and applauded), but they have changed their stance and claimed we are now acting improperly (and when we asked for how we could adjust our approach to something that works for their adjusted expectations we never received a response, even after receiving multiple emails from multiple non-company maintainers and even messages in multiple chatrooms).

Disclaimer: I was also previously an elected member of Codeberg's board (presidium), where before the company that was founded to support Gitea's community maintainers was created, I had asked for assistance with multiple matters to aid in project development and was denied.

Thanks for the write up. This makes me consider Gitea again. That sounds like a frustrating and absurd situation.

Note that Gitea has embraced AI code, and Forgejo refuses it - if that's a criterion for you.

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.

As someone who uses gitea, honestly it’s because I set it up a while ago and foregjo hasn’t offered anything compelling to force a switch, nor has gitea “enshittified” like the concerns around the fork raised.

Honestly, stay where you are

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

Did you use some sort of intrusion prevention system? I'm using cloudflare's anti ddos service + crowdsec, but I'm still getting bombarded with hundreds of thousands of requests per month

Besides rate-limiting with Caddy + fail2ban, not really. It's the public internet, anything gets bombarded almost as soon as it's public, but all requests are read-only requests so doesn't really impact anything beyond filling the access logs. Trivial to filter away when you want to do analytics too, so isn't really a problem.

It’s act runner. So you can continue using GitHub actions with minor changes

Using Claude for the same context and it’s doing really well with the glsl. since like last September

Article doesn’t really tell what fundamental problems will be solved, except fancy VM allocation. Nothing about hardware, networking, reliability, tooling and such. Well, nice, good luck.

> There’s something appealing in that idea, being independent and prepared, a male fantasy likely never coming to life

There’s still cloudflare in the middle of the everything and it doesn’t make it “independent”.

Very cool project. I am impressed by the ability of the different format downloads like Hapax. Kudos!

This is my pet feature :) There are so many cool sequencers and controllers, all with their own idiosyncratic plaintext instrument definition formats. Making little exporters for each of them is fun.

Well, the industry standard solution is correct monitoring and alerting. This doesn’t sound like “the right way”.

Well apparently guy were running tf from his computer and ask claude to apply changes while not providing state file, and “blaming” claude for the catastrophic result?