> 4. Do you just want to host repositories?

an ssh connection and

    git --bare init

Hopefully a good spot to plug my own project, preloop, which is a drop-in replacement of Github actions(both the runners and control plane) that runs locally or self-hosted in isoalted microvms, and supports debug-on-failure. You can also push to the server, run CI and then optionally create a draft PR. Not quite production-ready yet(for the self-hosted part), but the local part works well. We implement the official runner protocol 100% unlike act/gitea/forgejo, so your workflows are more likely to work out of the box with preloop(forgejo has the closest compatibility with Github Actions though so it's a good off-Github option) and we use microvms so no DinD issues. I'm working on getting the official runner vm image up to reduce any environment incompatibilities. Feel free to try it out: https://github.com/preloopdev/preloop

I'm quite partial to SourceHut as well but tbh I don't care about contributors and I like it because it is deliberately low-tech.

Maybe the CI could be a bit better (secrets management will sting you if you don't read the docs first), but that is also pretty no-nonsense and gets the job done.

If you like no-frills and an expectation that you know what you're doing, it's pretty sweet.

Would probably scare off most collaborators though but that, IMO, is part of the appeal. If you want to contribute then it's more likely you're invested and not driving by.

Also I like that it has a concept of projects so you can group repos together (which on GH would normally require creating an organisation account). And a repo can be public but unlisted, so it's open but not drawing attention.

7. Do you want the most contributions?

I hate to admit it, but GitHub has a massive community. I’ve personally seen a project leave it and then contributions dropped significantly.

*Forgejo

and you can stream your commits into any of these to improve deployment and commit availability when github is down.

Forgejo == Codeberg

Setting up custom GitLab runners can be cumbersome in the beginning! We faced that multiple times with various customer projects for which we were using GitLab.com managed repos. That's why my colleague and I recently built a "GitLab Runners as a Service" [0] -- simply use your self-managed GitLab or GitLab.com account to login, adding pipeline runners is a 1-click operation! Under the hood we provision a Hetzner machine for you runners and automatically connect your GitLab group or project to it. Happy to hear your feedback!

[0] https://rocketrunner.io/

I also self-hosted GitLab for some years, eventually ended up moving over to Gitea + WoodpeckerCI + Nexus (with Nexus for a while). Well there was DroneCI in the middle for a bit there as well, but Woodpecker is perfectly okay and more free in regards to what you can do. Only thing is that not that much other software out there supports Gitea, for example Kepler only knows about GitHub, GitLab, Jira, Trello and Linear.

> That said, I wish we hadn't migrated to GH, our self-hosted instance had WAY less downtime despite being perhaps a bit slower (mgmt saving money) and required a bit more toil

The key thing that drove our decision to self host gitlab was that WE were the ones in control of when things happened. We didn't do upgrades during times where we really needed our git infra up, and we were in control of our response time to incidents. We were not at the mercy of some other company's upgrade schedule and incident resolution process.

Of course, it comes with added workload and responsibility, but as the above comment says, it was not that onerous. While we paid for Gitlab Enterprise for a long time, we eventually switched to the free tier as that company was winding down (for reasons unrelated to our choice of git hosting), and the free tier actually has pretty much everything we needed.

I'd also say that gitlab runners are the biggest failure point in gitlab and take some work to micro-manage. If I was setting up from scratch I would consider gitlab for source control, but some hosted service for CI

Yeah, it's mind blowing to me that GH still doesn't have a branch viewer in each repo.

We did tun our own installation at work, supporting ~120 developers.

A single vm, 8 cpu cores and 64gb memory, using ssd disks on a local vmware cluster.

It worked okay but:

1. Was only exposed to the corporate network and some vpn connections

2. We did the upgrades late at night once every like six months, taking a snapshot of the whole thing from vmware side before touching anything

It worked pretty well and was relatively low maintenance. Frankly a very pleasant experience.

I’m using github and bitbucket at work nowadays and frankly i miss that experience, both as an user and as an administrator.

Edit: btw i left that job and that gitlab installation in 2022, no idea how things changed in the meantime.

> To all of those proposing self-hosted GitLab: ... it's not always a smooth sailing.

> (we pinned to major afterwards)

I mean OK. But also, if I want a reliable service in my business, I wouldn't typically auto-upgrade docker images nightly to "*".

Ok, with DSCI as monolith application where git and CI are the same server, 32GB RAM VM is more then enough , no need to host runners, no need in k8s cluster, no need in dedicated maintain team, so no extra costs on devops tasks ... Also with general programming languages for CI pipeline you are in full control and simplicity ...

The whole "social coding" angle is highly off-putting. List of "X followed Y" on the front page, and the large "social coding" reminds of facebook, social manipulation, developer burnout and all the negative things about social networks. It also brings up the questions about project's long-term direction - is this going to focus on the code part or the social part?

Which is a pity - as I think most projects just need a git host + web UI + easy pull requests + a way to clone other's repos, and tangled seems to do this pretty well.

What's the monetization pathway here? No private repositories (because everything is on ATProto) so near zero commercial use potential - CI is free, everything is free, no pricing page... Am I the product if I use this service?

I think the main thing I'm waiting for in the atproto space, for _most_ applications, is private data solutions. And the recent RFC on private data spaces (I forget the terminology) is a start, but has a ways to go.

Are you guys working on jj support?

This looks pretty cool. I like the idea of a federated option

What’s the monetization plan? My biggest concern would be using this and it losing support in a few years

[flagged]

Is their CI and CD workflow robust like gitlab/github ?

"Forget Joe", not the best name for a git repo host

Note: If you use any form of AI-assisted coding tools, your project breaks Codeberg TOS

Codeberg for open source and Forgejo for private (and slop, if you're into that kind of thing) is what winners do

Note: if your reason for switching is purely uptime, you will be sorely disappointed with codeberg

Their own site reports the 2 week uptime at 1 nine https://status.codeberg.org/status/codeberg and I suspect if you use the (really terrible) across-all-product-offerings uptime methodology that people love to post for github it would be a 0 nines overall service.

What is there to learn? It uses Git. What you think it feels like, it is not.

First I've heard of this, but they seem to be a young, smart and energetic team on a great trajectory. The atproto choice is interesting, fits their social-minded goal.

How easy is it to set up and run this for private repos?

It looks like it has so many cool features -- stacked PRs, jujutsu support, CI in Nix VMs. But I've never tried it because it sounds like (at least by default) it's some sort of decentralized, peer-to-peer public thing

I'm one of the project leads of Gitea. I'd be interested in knowing which features you are missing from Gitea compared to Gitlab? We are doing some backlog grooming right now, and input is very appreciated:)

Oh, it’s really simple why this happened:

1. People do not like email-based patch processes.

2. GitHub made everything dead simple, and free. Lots of Open Source projects have flourished because GitHub is both easy to use and makes collaboration across repository painless.

3. Very few people actually care about decentralization. As long as you have a full copy of your repo on your own machines as well as GH, it’s hard to argue you’re gaining anything with decentralization.

4. Most people also don’t want to self host a git server.

> How people managed to put all their eggs in one intermittently available service is beyond me.

It's beyond me how people on HN can be ignorant to why GitHub gained so much market share. It's because for most dev teams, the things they add to the easily decentralized git core is *very valuable.* Arguing it's not valuable or ignoring that value doesn't help anyone.

If decentralized is really going to win, then you have to have the features and DevX to match the basics GitHub provides. Because that's what people need/want. And not just the candy-ass-not-as-good-as-the-kernel-devs devs. Lots of very talented people and very well engineered projects use GitHub because it's better for what they need. Even with all the outages, people are still there. If it was so easy to move away, people would. The fact that they aren't says something important. Please consider not ignoring it.

> depending on what you’re developing it may or may not be a good fit for you

I think if your project is free / open source (edit: and you don’t use LLMs/AI), Codeberg is the a good starting point at least. You can move on to a self-hosted instance if you feel you’ve outgrown it, but even for larger projects I think you can get away with self-hosting just the CI runners.

And don’t forget to donate! https://donate.codeberg.org/ / https://join.codeberg.org/

Codefloe[1] is another forjego (with some custom patches, I believe) hosted instance.

[1]: https://codefloe.com

It seems and was launched with "deeply integrated with Cursor" and I'm not really sure how this is supposed to drive new adoption away from GitHub. The first thing I see in their video is an agents tab.

I'm not necessarily thinking our team needs a place just to push new code. We need reliable CI infrastructure and want to feel integrated to the rest of the industry. That's what GitHub offers us _sometimes_. We are exploring new CI infrastructure though for sure. Things like buildkite.

Anything with Tencent on it is a no for me.

I like bitbucket too, it's been really awesome and clean. No idea why everyone favored GitHub, but I had to have accounts on both for university and work

I really liked bitbucket, it's my favorite git management system I've used for real production work and it allows for self hosting. Self hosting is also way faster than gitlab from what I remember

Does sourcehut still require patches via email instead of "pull requests"? That was the deal breaker for me last time I looked at it.

You may consider dsci as its ci is baked in and it uses general programming languages directly as the first class citizens

Best of luck! I'm one of the project leads of Gitea, and if you run into any issues please feel free to hop into our chat:)

Yes! And for those complaining that gitlab CE selfhosted is resource hungry: It can be tuned to only use 2 GB memory in total and run perfectly fine for a single developer or limited concurrency. Gitlab CI is awesome.

All of that is good except if you also have a lot of private repos at GH, you cannot move them to Codeberg.

You mean Gitea [0], a community-driven fork is Forgejo. There was some drama, have to admit is still don't really understand it (ask an llm I'd say). Codeberg [2] uses Forgejo and offers it as a hosted service.

[0] https://about.gitea.com/

[1] https://forgejo.org/

[2] https://codeberg.org/

Gitee is Chinese. If you're in the US, it's considered a risk because it's Chinese. But people outside the US will not care.

Disappointed to see only one mention of this.

With Radicle you can continue to work locally with all issues etc intact, even if your “main” host is down. You can also sync through other hosts in the network.

I'll second Worktree. I'm US based and have been using it for over a year. Very, very happy with their service.

I started using fossil recently and have been quite pleased with this aspect of it. I miss a few things from the git world (mostly magit and its magical ability to stage individual hunks of a diff) and there are a few rough edges, but I totally agree that having a wiki and issue tracking inside the repository makes so much sense. fossil‘s simplicity is a breath of fresh air for anyone who has to use git from a CLI. Well worth a try for anyone on the fence.

I've used git-bug[1] for issues and it works pretty well. The web-ui is lagging behind and PR support would be everything you'd need to ditch a central-hosted web instance.

[1] https://github.com/git-bug/git-bug

Hopefully a good spot to plug my own project, preloop, which is a drop-in replacement of Github actions(both the runners and control plane) that runs locally or self-hosted in isoalted microvms, and supports debug-on-failure. You can also push to the server, run CI and then optionally create a draft PR. Not quite production-ready yet(for the self-hosted part), but the local part works well. We implement the official runner protocol 100% unlike act/gitea/forgejo, so your workflows are more likely to work out of the box with preloop(forgejo has the closest compatibility with Github Actions though so it's a good off-Github option) and we use microvms so no DinD issues. I'm working on getting the official runner vm image up to reduce any environment incompatibilities. Feel free to try it out: https://github.com/preloopdev/preloop

Classic CI vendors like Semaphore, Circle, etc are options.

That's great to hear! I'm one of the project leads of Gitea, and if you ever run into any issues please feel free to hop into our chatroom:)

Very interesting, I missed your original post[0], will definitely look into it further. What's new since you've posted?

[0] https://news.ycombinator.com/item?id=48631726

Hopefully a good spot to plug my own project, preloop, which is a drop-in replacement of Github actions(both the runners and control plane) that runs locally or self-hosted in isoalted microvms, and supports debug-on-failure. You can also push to the server, run CI and then optionally create a draft PR. Not quite production-ready yet(for the self-hosted part), but the local part works well. We implement the official runner protocol 100% unlike act/gitea/forgejo, so your workflows are more likely to work out of the box with preloop(forgejo has the closest compatibility with Github Actions though so it's a good off-Github option) and we use microvms so no DinD issues. I'm working on getting the official runner vm image up to reduce any environment incompatibilities. Feel free to try it out: https://github.com/preloopdev/preloop

no; gitea and foregjo both support actions-style CI/CD and both serve mostly GH-compatible APIs and have GH-style apps. it's not 100% compatible (forgejo is a little more compatible than gitea [^1]), but many of your workflows might "just work" without even renaming the .github folder.

^1: in my recent experience, for my particular use cases

Buildkite has built a GitHub Actions adapter... a good first step out of the GitHub Actions supply chain attack trap.

Woo! Thanks for the shoutout. I'm one of the project leads of Gitea, and if you ever run into any issues please feel free to hop into our chat:)

Try dsci / it’s super simple

We already have a vibe-coded forge, it's called GitHub

My previous org’s GHE went down all the time. It couldn’t handle the CI and automation tooling hitting it as often as an org of our size needed it to. So I can totally see cloud not being able to handle the new AI scale

I'm assuming you mean Enterprise Server (non-cloud), because my GitHub Enterprise Cloud is down right now.

Your first concern is not the reliability of GitHub (lost $$$) or any dark patterns they push, or their security, but the network effect?

Source repository should be its own thing.

Artifacts repository arguably should be its own thing.

PRs, own thing.

CI, own thing.

The Balkanization has always existed. Lot of stuff that isn't on GitHub.

There was some work to address this issue with federation in Gitea, but I haven't kept up with how well that went. Our practical solution was to just mirror our Gitea repos into GitHub. That way they're discoverable, releases can be downloaded, and so on. Not a perfect solution because users get confused as to why they can't open issues, etc.