I personally just self-host. The project that I'm working on right now uses Gitea internally with an action runner.
I use Digital Ocean and run a Nomad cluster on top of that. Gitea and its action runner builds container images and then pushes nomad job definitions to the cluster. I have zero downtime deployment and rolling deploys. Dagger.io is in there somewhere to make local CI mirror what happens in the action runner.
Setting up Gitea was honestly just an afternoon of work. The sqlite database is backed up to Cloudflare R2 and the code is mirrored. It's unlikely that my project will take off to the point that I'll need to upgrade Gitea to something else, but it's extremely easy to setup, maintain, and build CI/CD on top of.
Codeberg runs on Forgejo (a Gitea fork) and is fairly big, so you’re in a good company. Maybe you’ll need to swap in another database, but SQLite is surprisingly powerful, too.
While there are some problems with open source projects self-hosting their forges without federation, that’s really not the end of the world IMO (but lots of love for Tangled nevertheless).
However for CI I use WoodpeckerCI (previously used Drone but migrated over), it works well with containers and is delightfully simple: https://woodpecker-ci.org/
Though I guess in my case I don't collaborate with others much outside of work, so it's just something to interact with across computers and servers.
you can self-host components of tangled too: the git hosts (called "knots") and the CI runners (called "spindles"). the only difference between tangled and gitea is that with tangled, repos on your own servers are visible and discoverable via tangled.org, and users on other instances can submit PRs/issues stars etc. nix modules for all services are provided.
It’s funny that Bluesky is nowhere nearly as federated as Mastodon btw. (I guess people looking for Twitter replacement don’t really care to run their own PDS (or even know they have the option), while developers like tinkering with that kind of stuff.)
No idea what went wrong with ForgeFed, yeah.
---
Edit:
> Cool. It's been years since ForgeFed came out but it isn't anywhere nearly as federated as Tangled is. What gives?
Just read your other comments. Sorry, but I must point out that it would be polite to disclose that you’re working on Tangled, especially when posting takes like this on a competitor technology.
I'm pretty sure the actual forge we deserve at this point is one that is a membership organisation, eg, owned by its (paying) members.
Members elect the board which chooses the CEO. A cooperative, in other words. The tech is a solved problem, with lots of open source around to do it. Enough members means paid operations and development staff, or outsourcing one or both, or grants to open source devs, etc. The possibility is there.
That's how we prevent cultural drift: by actually controlling the company.
I think Codeberg, Forgjo, GitLab (Self Hosted) and Gitea are great OSS alternatives where it is funded by the community and should be great for long term support of your (and my) dev stack.
> I'm not against VC funding everywhere, but I don't want it at the core of my development stack.
Then you should avoid and steer very clear of Tangled since it is VC funded and crypto VCs are invested in this forge.
The direction here can change at any time, and is more likely to enshittify than the others.
I really don’t see the benefit of forge federation. Why do people care that completely separate projects run in completely separate forges?
A project’s issues and pull requests are only useful for that project.
The author mentions avoiding multiple logins and searching across forges. The former is already addressed by social logins / federated identity. The latter is not very useful today, on a centralized GitHub, aside from finding leaked credentials and vulnerable code.
In fact, the tiny barrier of entry for contributing in a new forge might be a desirable quality, to filter out low-effort contributions.
On a GitHub issue page, it will show backlinks to anywhere on GitHub that issue has been referenced. This is quite helpful at times because it leads me to find how other teams have worked around an issue I'm dealing with.
There's value in related information being aggregated and linked across many projects.
> The author mentions avoiding multiple logins and searching across forges. The former is already addressed by social logins / federated identity. The latter is not very useful today, on a centralized GitHub, aside from finding leaked credentials and vulnerable code.
Absolutely not. Social logins are unacceptable and I refuse to use sites that depend on them and do not provide a normal method to make an account.
Ideally projects like this can bring us a model where you don't need to login to some other forge to interact with a project but do it by forking it onto your own forge and submitting pull requests between forges.
You can accept issues and pull requests from users of other forges without requiring or even allowing new account signups on your forge.
I'd like it if people could contribute to the projects I host on my own personal GitLab, but not enough that I'm willing to deal with open registration.
That said, I don’t think that works well in a single centralized forge today either. Usually you still need A to actually make a release with the fix, which isn’t tracked by the issue/PR system.
I'm not sure. On GitHub I see plenty of bug reports which say "this is broken" with references to other repos. Those backlins are useful when someone does figure out the fix.
That said, I'm very much in favour of people and projects moving away from GitHub.
I've switched my git projects to push their objects into IPFS and their refs to pkkarr. That feels more distributed than the sorts of HTTP servers mentioned in TFA.
Anybody who cares about my repos potentially disappearing can contribute to their hosting by re-providing those repos from their own machines. (Note that only someone with the private key can create new records for a pkarr address).
That's mostly a side-benefit though: I mostly wanted something I can `git push` and `git pull`, that is self-hosted, and self-organises across a bunch of underpowered machines with unreliable network connections, with minimal coordination.
Very timely as I just set up Forgejo yesterday. There were immediate unexpected benefits moving off GitHub. It’s hosted on an Orbstack VM on a Mac Mini M4 on my local Tailscale network and the UI is incredibly snappy and quick to browse. Because it’s located inside my tailnet with no public access I don’t need to setup authentication, so agents running inside our network can clone a repo with no fuss (I just protect master branch pushes with a config rule). Github auth is a pain to securely distribute, when you self-host the problem just disappears. Also because it’s running inside our tailnet we can use Forgejo actions for infrastructure-related tasks: Ansible scripts that provision or maintain Mac Minis or Linux servers on the same tailnet over Tailscale SSH. Much simpler than Kubernetes which would be overkill for a small homelab/startup. And the Orbstack VM is literally two clicks to backup and restore or move to another host — I setup the VM running Forgejo on my local MacBook then a few minutes later exported the VM image and transferred it to a Mac Mini server in a few clicks. Backup and restore an entire server to a single file — that is the fastest and easiest server migration I ever performed. I literally can’t think of a single reason I would want to go back to GitHub. Forgejo is a joy to use.
Tangled and Radicle are both really cool, but add too much mental gymnastics compared to just running Forgejo.
What I like about (the idea of) ForgeFed is that it lets existing forges speak to each other.
In practice I probably just need Forgejo and GitLab to be able to speak to each other.
I believe the future of GitHub, for me, is to solve two problems:
- Discoverability for public open-source projects
- Backup since self-hosting is fragile long-term
So many times when I try to visit the source code of some package uploaded to crates.io, the self-hosted git no longer exists.
GitHub repos sit stale for decades.
For day-to-day reliance, my self-hosted Forgejo and CI runners have better uptime.
Only pet peeve with Forgejo:
- It's a highly active project, RFCs, tons of PRs and issues.
- Becoming a daily user, I want to extend it, and in its beautiful simplicity, it's not highly extensible.
- So to avoid maintaining a fork of a very active project, extending it in unison is a social commitment.
What a luxury problem, but still.
I'd like to see more hosted Forgejo solutions pop up; it's very low-resource cost.
I agree, these things just seem to add too much mental complexity compared to the advantages. Even the sign-up process is wierd, e.g. I put in my username as `dave` but if you try to log in as `dave` it says "did you mean dave.tngld.sh?" What? Then when you log in it takes you immediately to a second OAuth screen where you have to put your password in again, immediately after you logged in. I'm sure they would try to justify this bad UX with technical reasons...
I think the main attractive thing about Tangled is that it supports proper stacked PRs. But on the other hand it doesn't support private repos at all, and Github is getting stacked PR support soon (fucking finally)...
It's hard to see the advantage of Tangled over Codeberg for example.
> Closing this out for the time being, as noted previously (I'm currently leaning towards designing some review refinements and shelving the stacked concept design for the moment) and to clarify that it isn't current and active work.
It seems ironic, that in the social media space, AT protocol based instances are basically centralised (Bluesky) and ActivityPub based instances (Fediverse, Mastodon) have a much healthier grade of federation.
Whereas in the "forges" space, it seems Tangled drives federation forward much faster than the ActivityPub-based federation features of Forgejo/Gitea (which are progressing really slow).
I don't think thats so clear. The forges could support multiple federation systems and if for example someone made quality PR for the ATproto version that could get meged and adopted.
Also, could you describe the current code-review process for Tangled in more detail please?
My belief is that code review should happen locally, and the unit of work being reviewed stays independent from unit of work being "submitted". The reviewer should be able - locally or in the WebUI - to specify a change-/revision-set (preferably via jj revset language), or add files to review ad-hoc, or even mark specific lines for review!
And then, assign comments to such a review unit - where changes are all being captured as a first-class object, with all the niceties that may come together, e.g.:
- comments are captured in the jj oplog as if they were code changes
- it's easy to surface (locally or in the WebUI) past code reviews
- it's easy to "untangle" and grasp which particular comment belongs to which code review
- [vague from my side] comment might belong to multiple code reviews, or might not; code review might belong to multiple revsets
I'm currently looking to piece together a kubernetes native "forge" and there are major gaps in the ecosystem. Why do we need everything in one application like every single "forge" claims to be? What about when I want something that's not supported.
How about Forge compatible components? Or forgeables? Naming is hard but hopefully you get the point...
I'm an expert, I'll go to harbor freight and weld some stuff together. It will still break down in 5-10 years but maybe I will at the very least have some control over the way I pivot.
Sourcehut supports Mercurial, if the email workflow is your cup of tea. There's also Heptapod, which I believe is a fork of GitLab with added Mercurial support. I'm not aware of any Tangled or Radicle-like initiatives supporting it though.
Yeah the email workflow is not my cup of tea. :-) Heptapod seems promising in some ways, but from what I saw it's entirely based on topics (not branches or bookmarks) which is also a peculiar workflow. Plus it doesn't have anything comparable to Github in terms of providing free hosting; in theory you can get free hosting for an open source project but you have to apply. At one point around when they launched, Heptapod said something like "we don't want to be a place for people to host their random side projects", but that's exactly what I'm looking for. I was pretty happy with Bitbucket before they dropped Mercurial support.
I am indeed aware of them! To the best of my knowledge (please correct me if I am wrong) it's not actually usable functionality today and has been WIP for a long time, so it seems somewhat hypothetical. Their Mastodon account hasn't posted in over a year.
I personally just self-host. The project that I'm working on right now uses Gitea internally with an action runner.
I use Digital Ocean and run a Nomad cluster on top of that. Gitea and its action runner builds container images and then pushes nomad job definitions to the cluster. I have zero downtime deployment and rolling deploys. Dagger.io is in there somewhere to make local CI mirror what happens in the action runner.
Setting up Gitea was honestly just an afternoon of work. The sqlite database is backed up to Cloudflare R2 and the code is mirrored. It's unlikely that my project will take off to the point that I'll need to upgrade Gitea to something else, but it's extremely easy to setup, maintain, and build CI/CD on top of.
Codeberg runs on Forgejo (a Gitea fork) and is fairly big, so you’re in a good company. Maybe you’ll need to swap in another database, but SQLite is surprisingly powerful, too.
While there are some problems with open source projects self-hosting their forges without federation, that’s really not the end of the world IMO (but lots of love for Tangled nevertheless).
Also running Gitea, pretty pleasant experience!
Moved over from Sonatype Nexus to Gitea Packages as well since administering Nexus is annoying: https://docs.gitea.com/usage/packages
However for CI I use WoodpeckerCI (previously used Drone but migrated over), it works well with containers and is delightfully simple: https://woodpecker-ci.org/
Though I guess in my case I don't collaborate with others much outside of work, so it's just something to interact with across computers and servers.
Gitea has artifact support?! We are truly blessed.
Yep, including container images!
Mmm, this is for an Etsy-lite website ( https://plukio.com ) though honestly I've used Gitea for YEARS - even back when it was Gogs.
you can self-host components of tangled too: the git hosts (called "knots") and the CI runners (called "spindles"). the only difference between tangled and gitea is that with tangled, repos on your own servers are visible and discoverable via tangled.org, and users on other instances can submit PRs/issues stars etc. nix modules for all services are provided.
I'm way more hopeful in a fully decentralized protocol like Forgefed* than some AT still-centralized thing.
* https://forgefed.org/
(OP here) I'd love to see more decentralized alternatives out there!
AFAICT there is no actually-existing ForgeFed instances that I could use today, but I'm keeping an eye on it - let a thousand flowers bloom :)
Just tried the link to Vervis, Firefox mobile yells about a SSL error, went around it and still it returned a 404...
(but what I'd know, I thought this was about typography forges - didn't know there were also software forges...)
Cool. It's been years since ForgeFed came out but it isn't anywhere nearly as federated as Tangled is. What gives?
It’s funny that Bluesky is nowhere nearly as federated as Mastodon btw. (I guess people looking for Twitter replacement don’t really care to run their own PDS (or even know they have the option), while developers like tinkering with that kind of stuff.)
No idea what went wrong with ForgeFed, yeah.
---
Edit:
> Cool. It's been years since ForgeFed came out but it isn't anywhere nearly as federated as Tangled is. What gives?
Just read your other comments. Sorry, but I must point out that it would be polite to disclose that you’re working on Tangled, especially when posting takes like this on a competitor technology.
Lack of development. Federation is really complicated, but Forgejo has some foundation now (you can federate stars).
It will likely require some grant money to become usable.
I'm pretty sure the actual forge we deserve at this point is one that is a membership organisation, eg, owned by its (paying) members.
Members elect the board which chooses the CEO. A cooperative, in other words. The tech is a solved problem, with lots of open source around to do it. Enough members means paid operations and development staff, or outsourcing one or both, or grants to open source devs, etc. The possibility is there.
That's how we prevent cultural drift: by actually controlling the company.
> I'm pretty sure the actual forge we deserve at this point is one that is a membership organisation, eg, owned by its (paying) members.
Like https://codeberg.org/? :-)
hear hear!
To me being VC funded is the opposite to "structurally resistant to the lock-in".
I'm not against VC funding everywhere, but I don't want it at the core of my development stack.
I think Codeberg, Forgjo, GitLab (Self Hosted) and Gitea are great OSS alternatives where it is funded by the community and should be great for long term support of your (and my) dev stack.
> I'm not against VC funding everywhere, but I don't want it at the core of my development stack.
Then you should avoid and steer very clear of Tangled since it is VC funded and crypto VCs are invested in this forge.
The direction here can change at any time, and is more likely to enshittify than the others.
> Then you should avoid and steer very clear of Tangled since it is VC funded
Yes, that's what I'm referring to. Could have made it clearer.
I really don’t see the benefit of forge federation. Why do people care that completely separate projects run in completely separate forges?
A project’s issues and pull requests are only useful for that project.
The author mentions avoiding multiple logins and searching across forges. The former is already addressed by social logins / federated identity. The latter is not very useful today, on a centralized GitHub, aside from finding leaked credentials and vulnerable code.
In fact, the tiny barrier of entry for contributing in a new forge might be a desirable quality, to filter out low-effort contributions.
On a GitHub issue page, it will show backlinks to anywhere on GitHub that issue has been referenced. This is quite helpful at times because it leads me to find how other teams have worked around an issue I'm dealing with.
There's value in related information being aggregated and linked across many projects.
> The author mentions avoiding multiple logins and searching across forges. The former is already addressed by social logins / federated identity. The latter is not very useful today, on a centralized GitHub, aside from finding leaked credentials and vulnerable code.
Absolutely not. Social logins are unacceptable and I refuse to use sites that depend on them and do not provide a normal method to make an account.
Ideally projects like this can bring us a model where you don't need to login to some other forge to interact with a project but do it by forking it onto your own forge and submitting pull requests between forges.
You can accept issues and pull requests from users of other forges without requiring or even allowing new account signups on your forge.
I'd like it if people could contribute to the projects I host on my own personal GitLab, but not enough that I'm willing to deal with open registration.
> A project’s issues and pull requests are only useful for that project.
I don't think that's always true. A bug in library A might be referenced in project B with a fix in fork C.
Yes, a hyperlink works to show you where to find info. But it doesn't alert you when a PR on C is merged by A meaning that B is now unblocked.
Fair point.
That said, I don’t think that works well in a single centralized forge today either. Usually you still need A to actually make a release with the fix, which isn’t tracked by the issue/PR system.
I'm not sure. On GitHub I see plenty of bug reports which say "this is broken" with references to other repos. Those backlins are useful when someone does figure out the fix.
That said, I'm very much in favour of people and projects moving away from GitHub.
I've switched my git projects to push their objects into IPFS and their refs to pkkarr. That feels more distributed than the sorts of HTTP servers mentioned in TFA.
Anybody who cares about my repos potentially disappearing can contribute to their hosting by re-providing those repos from their own machines. (Note that only someone with the private key can create new records for a pkarr address).
That's mostly a side-benefit though: I mostly wanted something I can `git push` and `git pull`, that is self-hosted, and self-organises across a bunch of underpowered machines with unreliable network connections, with minimal coordination.
Very timely as I just set up Forgejo yesterday. There were immediate unexpected benefits moving off GitHub. It’s hosted on an Orbstack VM on a Mac Mini M4 on my local Tailscale network and the UI is incredibly snappy and quick to browse. Because it’s located inside my tailnet with no public access I don’t need to setup authentication, so agents running inside our network can clone a repo with no fuss (I just protect master branch pushes with a config rule). Github auth is a pain to securely distribute, when you self-host the problem just disappears. Also because it’s running inside our tailnet we can use Forgejo actions for infrastructure-related tasks: Ansible scripts that provision or maintain Mac Minis or Linux servers on the same tailnet over Tailscale SSH. Much simpler than Kubernetes which would be overkill for a small homelab/startup. And the Orbstack VM is literally two clicks to backup and restore or move to another host — I setup the VM running Forgejo on my local MacBook then a few minutes later exported the VM image and transferred it to a Mac Mini server in a few clicks. Backup and restore an entire server to a single file — that is the fastest and easiest server migration I ever performed. I literally can’t think of a single reason I would want to go back to GitHub. Forgejo is a joy to use.
Tangled and Radicle are both really cool, but add too much mental gymnastics compared to just running Forgejo.
What I like about (the idea of) ForgeFed is that it lets existing forges speak to each other.
In practice I probably just need Forgejo and GitLab to be able to speak to each other.
I believe the future of GitHub, for me, is to solve two problems:
So many times when I try to visit the source code of some package uploaded to crates.io, the self-hosted git no longer exists.GitHub repos sit stale for decades.
For day-to-day reliance, my self-hosted Forgejo and CI runners have better uptime.
Only pet peeve with Forgejo:
What a luxury problem, but still.I'd like to see more hosted Forgejo solutions pop up; it's very low-resource cost.
I agree, these things just seem to add too much mental complexity compared to the advantages. Even the sign-up process is wierd, e.g. I put in my username as `dave` but if you try to log in as `dave` it says "did you mean dave.tngld.sh?" What? Then when you log in it takes you immediately to a second OAuth screen where you have to put your password in again, immediately after you logged in. I'm sure they would try to justify this bad UX with technical reasons...
I think the main attractive thing about Tangled is that it supports proper stacked PRs. But on the other hand it doesn't support private repos at all, and Github is getting stacked PR support soon (fucking finally)...
It's hard to see the advantage of Tangled over Codeberg for example.
It seems like Forgejo isn't actively planning to have stacked PRs:
https://codeberg.org/forgejo/design/pulls/48
Which is totally understandable.
Managing a healthy highly-popular open-source codebase requires effort to not bloat it.
Which brings me back to wanting good APIs for native Kubernetes CI runners and time-limited PATs for agentic coding.
I can vibe that in a day. But it sure as heck won't be aligned with the future of all Forgejo users.
> Which is totally understandable. > Managing a healthy highly-popular open-source codebase requires effort to not bloat it.
I would not call stacked PRs bloat. It's a super important workflow. The fact that Github hasn't supported it for so long is insane.
It’s not bloat.
The argument is maintainer bandwidth/fatigue.
From the closed issue:
> Closing this out for the time being, as noted previously (I'm currently leaning towards designing some review refinements and shelving the stacked concept design for the moment) and to clarify that it isn't current and active work.
It seems ironic, that in the social media space, AT protocol based instances are basically centralised (Bluesky) and ActivityPub based instances (Fediverse, Mastodon) have a much healthier grade of federation.
Whereas in the "forges" space, it seems Tangled drives federation forward much faster than the ActivityPub-based federation features of Forgejo/Gitea (which are progressing really slow).
That might just be your observation bias. I have not seen any Tangled instances in the wild.
The federation mechanism that will win will be the one that forgejo/gitea supports first.
Everybody is moving either to codeberg or more likely forgejo instance.
Forgejo already supports ActivityPub, albeit only for a minor use case (starring repos), so according to your definition, it's decided already.
I don't think thats so clear. The forges could support multiple federation systems and if for example someone made quality PR for the ATproto version that could get meged and adopted.
The forge we deserve is the one that is built for jj and local review.
Tangled is built for jj :) We support stacking using jj change ids: https://blog.tangled.org/stacking
Is code review a first-class concept in Tangled?
Also, could you describe the current code-review process for Tangled in more detail please?
My belief is that code review should happen locally, and the unit of work being reviewed stays independent from unit of work being "submitted". The reviewer should be able - locally or in the WebUI - to specify a change-/revision-set (preferably via jj revset language), or add files to review ad-hoc, or even mark specific lines for review!
And then, assign comments to such a review unit - where changes are all being captured as a first-class object, with all the niceties that may come together, e.g.:
- comments are captured in the jj oplog as if they were code changes
- it's easy to surface (locally or in the WebUI) past code reviews
- it's easy to "untangle" and grasp which particular comment belongs to which code review
- [vague from my side] comment might belong to multiple code reviews, or might not; code review might belong to multiple revsets
The forge we need is git-http-backend and a mailing list. KISS and focus on the actual work instead of bikeshedding.
I'm currently looking to piece together a kubernetes native "forge" and there are major gaps in the ecosystem. Why do we need everything in one application like every single "forge" claims to be? What about when I want something that's not supported.
How about Forge compatible components? Or forgeables? Naming is hard but hopefully you get the point...
I'm an expert, I'll go to harbor freight and weld some stuff together. It will still break down in 5-10 years but maybe I will at the very least have some control over the way I pivot.
> So, what’s next? There are a lot of Git forges out there.
How about some non-Git forges (like Mercurial forges)? That's what I'd like to see.
Sourcehut supports Mercurial, if the email workflow is your cup of tea. There's also Heptapod, which I believe is a fork of GitLab with added Mercurial support. I'm not aware of any Tangled or Radicle-like initiatives supporting it though.
Yeah the email workflow is not my cup of tea. :-) Heptapod seems promising in some ways, but from what I saw it's entirely based on topics (not branches or bookmarks) which is also a peculiar workflow. Plus it doesn't have anything comparable to Github in terms of providing free hosting; in theory you can get free hosting for an open source project but you have to apply. At one point around when they launched, Heptapod said something like "we don't want to be a place for people to host their random side projects", but that's exactly what I'm looking for. I was pretty happy with Bitbucket before they dropped Mercurial support.
I miss mercurial sometimes, but we have so much tooling around git these days...
I would love to see a forge that consists of composable components, self-host able with federated identities and maybe a few centralized indexers
That's Tangled! Self-host your knots, AT Protocol for identities, and an "indexer" at tangled.org (easily replaced).
Forgejo is mentioned, but its federation goals aren't. I guess the author isn't aware of them.
https://forgefed.org/
I am indeed aware of them! To the best of my knowledge (please correct me if I am wrong) it's not actually usable functionality today and has been WIP for a long time, so it seems somewhat hypothetical. Their Mastodon account hasn't posted in over a year.
I thought this was gonna be an article about Sourceforge
Anyone remember that? It used to be such an important website and went down the tubes.
> Or perhaps everyone moves to some hot-new-AI-first-forge, and then we go through the same cycle of enshittification in 10-20 years.
I don't think it would take years for an AI first platform to enshittify, it would be instant.
How do folks feel about the htmx based front-end?