Ask HN: Alternatives to GitHub
Github has been down consistently over the last few months - does it make sense to switch to alternatives?
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: GH is nowhere near Enterprise-ready and it feels a downgrade across the board. GL has better access granularity, better docs, better integrations, and you can clearly see the UI received a lot of attention (although it does take 10m with a new account to pin the proper items in the maze of sub-menus that is the sidebar). You can also look at the code and help out if needed, and/or simply provide a patched version to your image via a docker mount.
If you're really looking at self-hosting GitLab for a smallish team (up to 50-100 ppl), prepare at the very least a 16GB machine (best 32GB) with 4 cores and a decent SSD, and at least a small team (1-3 people) that can maintain it properly or jump at it at any moment. For runners, a small k3s cluster is ideal to make use of all the resources you can throw at it without worrying about managing the runner state/configuration.
The worst part about the github runner setup is that there is no built in support for using your own cache if you are using github.com and want to run your own runners. In order to use your own cache store for your runner jobs, you have to patch the runner image because the cache location is hard coded. Gitlab lets you choose your cache location as a standard feature.
(So far I used this cloud.init script to spin up and upgrade GitLab-Runner instants: https://gitlab.com/21analytics/gitlab-runner-cloud-init/-/bl...)
> Grants complete read/write access to the API, including all groups and projects, the container registry, the dependency proxy, and the package registry.
Even more so just to stay informed about updates.
We wanted to make the onboarding as simple as possible so that we can:
0. Log you in through your existing GitLab.com or GitLab self-hosted account 1. List all your groups and projects to decide where to install the runner 2. Disable GitLab.com's own instance runners (otherwise our Runners are not picked up) 3. Install the Runner 4. Optionally: When installing an agent runner, we are able to reply to read and reply to all your issues where you tag us via `@Rocket` -- this runs completely on your machine that we host for you! It doesn't run on our infrastructure and we only access your runner machine for auto-cleaning its caches.
That's really all the RocketRunner does with you granting us permissions when logging in.
We are looking into ways how to possible scope access better! Thanks for your feedback!
P.S.: With AdBlockers enabled I cannot navigate on your site at all on Safari mobile. Seems like your navigation uses to much JS to provide a link.
(Sorry for posting this twice, but we'd really love to get more user feedback)
Maybe running on Kubernetes or some autoscaling solution is more painful.
When you fork a project, it's really not clear in the UI why it's stalling (because it uses your configured runner, i.e. none, not the project's).
When a runner fails, it's not really clear why. gitlab-runner logs are mostly useless in terms of connectivity to the gitlab instance, displaying what projects/repos it's effectively associated with. And i don't think it even has a simple test command to test the docker setup, you just have to trigger jobs until it fails in the middle of hundreds of lines of logs.
CI should not be any different from regular programming
That DSCI is not a forge - it's a task runner attached to gitweb frontend. There are _none_ of the forge-like features like user management, pull requests, etc... Even in CI area, most of the features are missing: from the quick perusal of the doc, even something as basic as "have runner on remote machine" or "run two jobs at once" is not implemented.
My first job I was in ~10 people robotics/hardware startup, and we had CI cluster of about 4 workers, later extended to ~10 machines (managed by buildbot, those were the times...). And the parallel jobs happen all the time in commercial developments, no one likes to wait for a long time when they could wait for a short time. This is not done for various OS'es, instead one machine might be testing service A, while other tests service B, while the third one tests integration.
That said, there is nothing wrong with "Dead Simple" niche - I am sure that there are some users who could use it. Although those would probably want something with less lock-in, your current approach is pretty weird: the jobs which _look_ like they are written in regular bash/python/etc.. but actually they have extra functions ("run_task", "task_var" etc..) magically injected, so you cannot run the file directly nor can you run linters on those. I'd much prefer pretty much anything else which can run unmodified code.
- jobs do not look like, they are indeed written on gp languages, no magic here
- run_task / task_var are just SDK functions - you may or may not need them. They simplify pipelines development ( conditional tasks , getting task variables ) but you don’t have to use them if you don’t need them. There is no absolutely magic in dsci / it’s just normal programming languages
- you can run pipelines locally if you really need to, however this is rarely needed and the point of having gp language for ci code is ability to use standard programming techniques, running locally is not main focus here
- the main advantage is using programming languages not YAML. You can apply linters / refactoring / libraries decomposition - all standard techniques one has in gpp languages , this is always pain with YAML
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.
> (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 "*".
Well fair, but we had been using it for 4+y at the time before running into that, and the rails-based migration scripts basically never failed once despite being migrated across 6 majors and countless minors/patches. Being a small company, from that PoV it gave us very little downtime for essentially zero security work to maintain it. Of course we had daily (and tested) backups too, just in case, but we never had to use them.
Overall, the downtime of GL, even with auto-upgrading and the issues above, was perhaps 1.5 work-days across 6+ years. GH exceeded that budget in the first 2 months after migrating this year...
Just to make it clear: it wasn't pinned to `latest`, we created a small script that would probe the docker registry and enumerate all the tagged images (e.g. 15.3.2, 16.4.1, ...), sort, pick the latest of those tagged, and apply it. It was probably 1-3 updates per week. Still, it was a really good run despite the couple hiccups mentioned above.
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.
It's a bummer because they had so much potential to dethrone GitHub a few years ago but really missed the opportunity to position themselves as a viable alternative. That said I still use gitlab.com for my personal projects over anything owned by Microsoft.
1. Do you want something that works and feels like GitHub? -- Forgejo and Gitea are good for this.
2. Do you want a place to host git repositories with minimal hassle? -- GitLab, CodeBerg, and others are available.
3. Do you have your own hosting infrastructure? You could use gitolite and CGit/GitWeb on that hosting platform or local hardware.
4. Do you just want to host repositories? -- Gitolite can be used to help with SSH/auth/repository creation, and CGit or GitWeb for the frontend.
5. Do you need something like GitHub Actions? -- GitLab, Forgejo, and Gitea offer CI, or use external CI infrastructure.
6. Do you need issue tracking and management? -- GitLab, Forgejo, and Gitea provide these. There are alternatives from Jira to Kanban (including Trello) to Markdown (Obsidian and others) and more.
> Forgejo is self-hostable free software for software development, built on top of Git. Codeberg is powered by Forgejo, which is in turn a hard-fork of Gitea. Compared to Codeberg, Forgejo is not one service, but free software to help you build your own. Everyone can install their own Forgejo instance to host their own projects. There are also public Forgejo instances as well as Codeberg you can use, but make sure you find a site that is actively maintained and updated, and that you trust the provider.
https://docs.codeberg.org/getting-started/what-is-codeberg/#...
I hate to admit it, but GitHub has a massive community. I’ve personally seen a project leave it and then contributions dropped significantly.
It is mostly all AI agents, bots and spam anyway, not to mention most projects are now vibecoded slop on there.
You're better off going to a different forge or hosting one yourself.
Codeberg has a no LLMs policy which is very attractive for many.
I do agree on the fly by night agents, especially since so much is actually just agents acting on behalf of folks who just spam whatever permissions are requested in Claude/Codex.
If every project requires its own username/password just to report a bug, I may do that for the first 2 or 3, but not for every project. I'm also unlikely to create accounts on hosting platforms I don't intend on using outside of reporting the single bug.
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.
It was a bit of a pain to configure firecracker with k3s.
It really can’t be understated how much easier hosting CI is with microvms as the security boundary.
Their v15 release (apr 16) really enabled k8s native runners. They added an ephemeral runner API and a bunch of APIs to get jobs. That's what im using to do k8s autoscaling
The concept is marvelous, but i'm 100% not trusting slop near my infra, and i'm 100% not trusting people who are not upfront about vibecoding in their README and raise my hopes for nothing.
I suspect most sysadmins, like me, will not trust LLM-generated code within a 10-foot-pole-reach of their servers. You still might be able to convince clueless managers suffering from AI psychosis to go for your solution. But if you'd like to make actual software engineering with a human team, i'm 100% convinced there's actual desire and market for a solution like this to easily get ease the transition path out of Github.
an ssh connection and
git --bare init
We were using it until we grew tired of not having a web view to comment and review patches so we switched to gitea.
ssh server git --bare init myrepo.git
git clone server:myrepo.git
or if your local repo existed first:
git remote add server server:myrepo.git
git push -u server @https://sgringwe.com/2019/10/10/Please-just-stop-saying-just
I don’t do pull requests to myself, and I don’t need a bug tracker or CI.
If they do, then migrate to a provider that offers what you need at that time. It's not like adding a new remote is hard.
https://blog.codeberg.org/protecting-our-floss-commons-from-...
You may agree with this. And if so, you have found your home. For those who just want to host, and not buy into this particular perspective, you should probably look elsewhere. I find a lot of people in the States promoting CodeBerg also have illusions about Europe, of the sort that are likely to be radically tested in the next decade, if not the next few election cycles alone.
Happy to answer any questions.
What’s the monetization plan? My biggest concern would be using this and it losing support in a few years
Self hosting will be free forever. That is not a threat to monetization plans because most people would pay a reasonable price ($10 month) to avoid dealing with infra. Remember that hardware is cheap so margins can get pretty high and 1000 paying customers at the lowest tier is probably enough to pay for a full time engineer. 10,000 and you can have a small team (plus unpaid open source contributors). You don't need Amazon scale and growing profits to be successful.
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.
One thing with GitHub for open source projects is that the CI is free (and included macOS runners). The other is that many people have a GitHub account and would refuse to contribute to a project on another forge if it means that they must create a new account.
The federated design of Tangled solves the latter problem, so there's that.
Also if everybody moved to Tangled, I would have to somehow interact with it, wouldn't I? I dislike the social network aspect of GitHub, but it doesn't mean I don't need GitHub.
Which seems totally reasonable, as per the Founder/CEO of Tangled: https://news.ycombinator.com/item?id=49335338.
> Use what you want.
Then don't tell me to use something other than Tangled, I guess?
Edit: I really like that one-click "watch logs via SSH" copy button. Maybe those could be attached to the top of the top, as it stands the pipeline just pushes them further and further down. Find the UI and UX overall very pleasant.
A better web UI for the queued jobs on my spindle would be great btw!
Additionally (and optionally for Tangled use), I'm also hosting my own PDS which is my personal data server. This is the home for my AT proto profile, which contains all of my AT proto activity like Bluesky comments and likes. Tangled does look at the PDS for identity but the code is in the parallel structure of the knot. I suspect this is cause AT proto wasn't built for code so the PDS isn't sufficient for an entire git repository but don't quote me on that.
Finally I'm running a spindle, which is just a CI runner, and that's registered with Tangled very similarly to how a self-hosted GitHub or Gitlab action runner would be.
And atproto isn't really something I'd want to be around; it's really associated with the wrong crowds.
But Forgejo does have a GH like CI/CD. If you really care about good CI/CD then you should try some of the alternatives out and decide what works best for your needs.
However, Codeberg offers hosted Woodpecker CI.
It's also free for private repos, and I have both. Codeberg doesn't like private repos, so unfortunately I cannot just move everything to Codeberg. I'll probably set up a Forgejo VPS somewhere.
If you have advanced use cases you might be more frustrated, but I’m not aware of any off the top of my head. I think my biggest complaint is that they haven’t exposed action logs over the API, so I can’t build tooling around them at the CLI level, feed them to an LLM, or more quickly diagnose problems that arise without using the website.
I found in the current version of Forgejo the most secure way to set it up was just to put the runner on a different host. There's a Docker in Docker setup [2] that was challenging to get working correctly but still didn't quite feel secure...
After setting it all up, I'm convinced GitHub actions as a concept is flawed. I wish the community would make a simpler git-defined CI/CD that didn't have the crazy surface area that actions does... Named shell scripts that can call out to other stuff in the runner Docker image and report it to the UI would be a nice start.
[0]: https://github.com/nektos/act
[1]: https://forgejo.org/docs/v15.0/user/actions/github-actions/#...
[2]: https://forgejo.org/docs/v15.0/admin/actions/docker-access/#...
Self host both of them on my internal network. Technically old version of gitea which is forgejo pre-fork
Just set up a CI pipeline for PHP projects with a forgejo runner last week. Tried many approaches, ended up with a simple debian VM. Runner works well with docker images inside the VM, quite a flexible setup. Found this easier and better than my last tries a few years ago with gitlab, which always felt quite bloated.
I also published a blog post today about this whole journey: https://sarah-robin.com/blog/we-just-wanted-to-deploy-a-webs...
Using Github at work is painful in comparison. (Also literally just this morning we’ve had to delay a release due to Github being down.)
A big plus is that it also has an open-source Community Edition that you can self-host
In addition I spun up forgejo at a server at home for very critical stuff and it's awesome.
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.
Personally I have never had a single issue with Codeberg's uptime. Are you trying to argue that GitHub's is better for some reason (when it objectively is not)?
If you look at github's uptime for that past 24 hours they're way below 1 nine.
In all seriousness, the amount of time you amortize over matters - if you look at the status account here https://social.anoxinon.de/@codebergstatus the downtime is not bad overall even though recently it was rough.
that's not true, only if the project consists mostly of AI generated code
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.
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.
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 not happy about the fact that GH doesn't show my when new issues or PRs are filed against projects I maintain despite the notification settings implying I should be getting notifications, but at least it's not Atlassian.
I was working on major architecture shifts for a couple of libraries, to fix early mistakes or improve performance. I noticed that of them used a tool A that was dead, built on another tool B that was even deader.
I found someone who was building a new B, and I made a new A and offered to swap in it on the one project. That went well, so then I integrated it to the other projects I was contributing to. Which I'm now also a maintainer on.
And also the 'new B', because I pushed the intent of his library farther than he had been thinking about, contributing about 20% of the public facing API and about 5% of the internals.
One of those projects is a monster, of which I'm just on a subproject. I'd never be able to get them all to move off. And any mix of GitHub and ^GitHub results in the amount of busy work I have to do to keep on top of issues and PRs more than doubles.
And that's how the getcha.
I worked around it to some extent by having an organisation per category, but that doesn't work at scale. For example, you can't group Text-to-Speech projects around the different libraries (coqui-ai, Qwen3, parler, etc.), or language tooling installation scripts by programming language. -- Those have a group/subgroup/repository style structure.
The other related feature is having organisation or group-level issues and corresponding tracking features.
Gitolite doesn't impose/enforce a structure on the user. GitWeb/CGit have a free-form category (e.g. "lang/python") that the project can be assigned to. That works, but I'd like it to support multiple tags/labels for that.
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/
What you can't do is "share projects that mostly consist of code written by 'generative AI'-tools". <https://codeberg.org/Codeberg/org/commit/71149c7fc95ccfeae36...>
I have not written more than maybe 10 lines of code in the last year so it seems I am prohibited from hosting on codeberg?
Or is the key word "share" and that's somehow different from "host"?
Good luck with that.
1. I am not Codeberg.
2. Turning away people doing unwanted things is the whole purpose of Codeberg's new policy. Why you present this as a undesirable side effect rather than exactly what the policy was designed to do is the only difficult thing to comprehend in this thread.
1. created by LLM agents -- any vibe-coded projects;
2. mainly written and maintained by LLMs -- this would cover the recent changes to the rsync project;
3. tied to the LLM ecosystem -- this covers pytorch, llama.cpp, cursor, SillyTavern, AI skills repositories, and a whole host of other projects.
You can read it yourself - https://blog.codeberg.org/protecting-our-floss-commons-from-...
No, they didn't. That's not what the blog post says.
> You can read it yourself
I didn't fail to do the reading beforehand. I posted a direct link to the change in the TOS and which is currently linked at the top of all Codeberg pages. Can you read it yourself?
[1]: https://codefloe.com
[#1]: https://her.esy.fun/posts/0031-how-i-protect-my-forgejo-inst...
I configure my local repositories to push on both Github and my forgejo instance. I am not using the CI much for my private projects (local tests are enough in my case).
- lightweight ( single binary written on golang ) - ci runner embedded ( podman / docker ) - pipelines are written on general programming languages - no YAML craziness - Perl/Python/Bash/Raku/Powershell/Php/Golang support - code editor
- It isn't git - Works best with smaller teams - You need to be ok self hosting (single binary, easy to do)
The first point is really the killer. It is revision control, it is as good as git (maybe better), but it is different. Git = branches are easy, was built to support Linux's lieutenant development model, and a massive, loosely connected team. Fossil = branches are intentionally hard, built to support a small, tight knit team (SQLite).
Most teams I've been on are closer in size to SQLite than they are to Linux, but everyone already knows git at a gut deep level. YMMV.
If you'll entertain me for a moment...
My dream "forge" would just be nice-looking frontend for displaying repos on the web, a public issue tracker (with per-issue permissions), a public way to submit issues, and essentially a single canonical root for repositories that users on the team work on. I don't want individual user repos or pages, organizations, or any social stuff. I definitely don't want open registration.
It really looks like fossil is actually what I've always wanted.
How limiting is the custom theme support? It looks like you can just straight up write your own HTML/CSS for everything. If I really want a custom design, will I be disappointed in the long run?
Also, it looks like it follows that user model I want, where it's "repositories with users" instead of "users with repositories". Is that correct?
And here I was trying to hype myself up to write my own git web frontend.
> My dream "forge" would just be nice-looking frontend for displaying repos on the web, a public issue tracker (with per-issue permissions), a public way to submit issues, and essentially a single canonical root for repositories that users on the team work on.
Fossil will get you the frontend (for some value of nice-looking) for displaying repositories on the Web. It will also get you the issue tracker, which can optionally be public[0].
For products you're developing that involve multiple repositories, it's possible to use a "meta repository"[1] to establish what's called a login group in a way that's vaguely reminiscent of using, say, Kerberos as an adjunct to /etc/passwd. You still have to ensure that the users exist in the user information table on the joined repositories[2], but the password information will at least be synchronized.
> I don't want individual user repos or pages, organizations, or any social stuff. I definitely don't want open registration.
There's some social stuff if you find later that you want it. Fossil development moved from a more traditional mailing list to a self-hosted forum a while ago, but it isn't enabled by default.
You can use tech notes as a sort of micro-logging facility in the same vein as snippets if you're familiar with how Silicon Valley companies sometimes have cultures of personal status updates. I'll admit that I've gotten a fair amount of use out of this.
I'm honestly not sure if open registration is possible. I've never had an excuse to try it.
> How limiting is the custom theme support? It looks like you can just straight up write your own HTML/CSS for everything. If I really want a custom design, will I be disappointed in the long run?
If you stick just to HTML and CSS, you should be fine. The functionality is pretty spartan.
> Also, it looks like it follows that user model I want, where it's "repositories with users" instead of "users with repositories". Is that correct?
Yep. The repository itself is what has the user information.
--
0: This is governed by the capabilities assigned to a user. See https://fossil-scm.org/home/doc/tip/www/caps/ and the therein linked https://fossil-scm.org/home/doc/tip/www/caps/ref.html for details.
1: At least, I tend to name mine "meta."
2: Funnily enough, it shares the same pain as administering Plan 9's fossil(4) fileserver. See https://fossil-scm.org/home/doc/trunk/www/caps/login-groups.... for details.
> For products you're developing that involve multiple repositories, it's possible to use a "meta repository"[1] to establish what's called a login group
Gotcha; that makes sense considering how users are handled.
> There's some social stuff if you find later that you want it. Fossil development moved from a more traditional mailing list to a self-hosted forum a while ago, but it isn't enabled by default.
That all sounds reasonable (this + the tech notes you mention next). I generalized a bit too wide when I said "social stuff". I was thinking more along the social media angle (GitHub stars, follows, etc.); but with the way it sounds, that wouldn't make sense given the user model anyway!
I currently run a Forgejo instance for a small team, and I can disable some of those features, but it just feels a bit messy with so many UI elements that don't have a purpose.
> If you stick just to HTML and CSS, you should be fine. The functionality is pretty spartan.
I think I'll have to try it out to see what is possible on this front!
> This is governed by the capabilities assigned to a user. [...]
Between this and login groups, it actually looks quite reasonable to manage a set of repositories in the way I'd like! I really dig everything being so tightly coupled to a given project, actually. Makes me a bit bummed I never gave Fossil a look all these years.
> 2: Funnily enough, it shares the same pain as administering Plan 9's fossil(4) fileserver.
Reading that over, I can see how that requires some due diligence. I already foresee the inevitable "why weren't the changes propagated to the other repositories?" moment.
I think this will be my weekend project!
Most welcome!
> I generalized a bit too wide when I said "social stuff". I was thinking more along the social media angle (GitHub stars, follows, etc.)
I figured given the context, but I wanted to cover this base too just in the off chance that the intention was different. I overcorrected a little perhaps. (:
> I already foresee the inevitable "why weren't the changes propagated to the other repositories?" moment.
It's something of an ironic "What manages the configuration of the software configuration management system?" moment, really. My suggestion is to have a sensible chuckle at it.
> I think this will be my weekend project!
I hope to read more about it!
it's fast, has a great API for bots and automations to use, just a Go project so we've been able to make some tweaks to the runner. Very easy to setup and admin
[0] sr.ht
[1] codeberg.org
I'd guess the technically correct answer to this question is "yes". But sourcehut has very good mailing list support, that is essentially equivalent to github pull requests.
Still, I find the wording of your question a bit prejudiced... as if I asked "does github still require pull requests via a proprietary interface instead of just sending the patches?"
Is there?
Compare that with GitHub where the workflow is push changes to fork, select branch, click to create a PR, write the description in a convenient web form and submit. Less friction and less opportunities to mess up. The solution to a centralized forge is a decentralzied forge, not no forge.
The email workflow has features that GitHub doesn't have. Most people do without them and don't really feel a need to learn about them, and that's fine. But would Linux be better off with GitHub? Not sure.
Newer app is moving to Google Cloud Secure Source Manager (because we are on Google Cloud and using backbone auth so it made more sense and less involved to manage)
On more detailed level, it allows forgeless issue management, cross-forge PRs, git-native discussions, and much more.
It has not dependencies, just git itself. Happy to answer any questions!
GH beat them on UI/UX and the PR workflow I think. Really nothing more than having a better ~$120k Product Designer working there. Kinda funny what actually makes people stick with 1 choice over another. Very often it’s just having better UI/UX, or offering something useful for free.
I use it at work alongside GitHub (patchwork of merged companies).
There are random little things I like about it better than GitHub, especially in an enterprise setting.
And it has never gone down in my entire tenure at this company, while GitHub is like a weekly outage nightmare these days.
Atlassian is doing a whole lot of strange and desperate stuff lately including some pretty insane UI changes in Jira and their other products, but Bitbucket seems like it’s been neglected the exact right amount for it to be a pretty decent choice.
GitHub has alternatives, but no replacement
https://news.ycombinator.com/item?id=49135365
Why developers are ditching GitHub for Codeberg and self-hosting alternatives
I self host Lore for my gamedev projects.
https://reticulum.network/manual/git.html
I don't think moving to another forge is much of a solution, at most it is buying a bit of time. We've seen this happen with SourceForge, with Tigris, and now with GitHub.
I'd hate to see a move to forge balkanization lose this functionality. But this would not be heavyweight data to federate. So are there any forges with a good story for federation?
Also, unified dashboards/notifications are so useful (even though Github's notification UI is a bit mediocre, imho).
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.
Yes, you could feasibly split off the CI from the git+PR service, but you'd still want it to be federated.
If you can use or make a GitHub action you will be just fine in GitLab, CircleCI, Jenkins, or a couple of shell scripts hacked out over pizza and beer on a weekend.
There's no pipeline moat, to put it another way.
For me it's usually a green-flag, since it automatically means they optimized for high-scalability first, as their userbase is gargantuous!
Which GitHub alternatives have anything like it?
It’s my go to now for all my private projects
I've blogged about it too: https://news.ycombinator.com/item?id=48978707
All of these are free (if you ignore electricity cost of hosting your own git server), and each one is a backup of sorts.
I don't necessarily recommend starting with GitLab though unless you want advanced CI capabilities, but you're already used to GitHub so you should consider self hosted gitea, which uses the same Actions syntax and even has some interoperability with its action modules I think.
But yeah, my recommendation is just to push to as many (free) git hosts as you can. Why not take advantage of free code storage if it's available. Plus if any one host goes down you can still retrieve your code from the others.
To me, still, at a scale of 250 contributors (which we hit), Gitea solved all the problems. The fact that there's a command line tool (tea) that mostly works, means that it is beyond good enough for my use case, out of the box. It misses all sorts of things and depending on how important they are, you then invest in looking to close we they'll gap. That in turn creates its own maintenance and frustration costs.
In other words, there's no one shot. There's a good enough depending on need.
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.
With Amsterdam[0], I've put it back on GitHub, but only as a mirror to increase visibility of the code. My erbosoft.com Git server will always remain the "source of truth" for the project.
[0] https://git.erbosoft.com/amy/amsterdam and https://github.com/amysoxcolo/amsterdam
I know I can self-host forgejo but would be nice to have something like forge.eu (even paid!)
It's also self hostable, but I'm on the $2 tier and damn is it good.
What I want is a system that doesn't define functionality. I want something protocol-less. The larger system design prescribes only loose i/o channels between components, so (for example) you know you can interrogate something Git-ish. But what language or protocol they speak, what functionality they contain, isn't prescribed by the design. This allows them to have any functionality.
You might think I want something like microservices. But microservice interfaces are too prescriptive and not interoperable with other services. Everyone writes their own custom incompatible API for the same basic functionality. What's needed is something so simple, so loose, that people naturally copy the first one they see for their own implementation.
Example: Pull Requests. They're basically just a git diff, that can be approved, blocked, rejected, and comments are attached to them. You could implement that a hundred different ways. But what's the simplest possible thing? It already exists: patches in e-mail. You e-mail a diff to a mailing list, people reply (comment) on pieces of the diff, and eventually somebody commits and merges some form of the diff and pushes it to their repo. You didn't really need a DAG, or objects, or CRDTs, or protocols. You already had everything you needed. So how to implement this, in a system with no protocols? Just feed e-mails into an app; the app reads the e-mails, it accesses a clone of a Git repo for operations, it sends e-mails out, and displays comments etc in a web interface of the diff.
Next example: Issues. This one is pretty simple: use any ticketing system you want, the rest of the system has no idea. Reference an issue's URL in a comment or commit message with either the bare url, or markdown ([issue #123](uri://somehost/issuetracker/view?i=123)). Use OIDC to allow logins, or read-only for anonymous.
Want to "copy" data from one system or component to another? Each system can do this differently, but if you make it simple enough, they'll all do the same thing. Simplest solution? For each service's HTTP endpoint (I'm just assuming they would all use HTTP to communicate, but don't have to), prefix the endpoint with "/zipmime", and the result is a ZIP file of MIME files (so "uri://somehost/issuetracker/view?i=123" becomes "uri://somehost/zipmime/issuetracker/view?i=123"). Now you can export any data from any service in a standard way that supports any kind and amount of content (because it's URI-based and HTTP-based, the service doesn't even have to support this natively! you can implement a reverse proxy and microservice to bolt the functionality on later).
At no point in any of these designs are they dependent on other designs. They just "do what they do", and other designs naturally coalesce around simple standard methods.
Gitea is a fork of Gogs.
Forgejo is a fork of Gitea.
Codeberg folks forked Gitea to create forgejo.
disclaimer: I'm one of the project leads of Gitea
Also back in the day, you needed a paid account to make private repos on GitHub, but Gitlab made them free.
Anyway I haven't heard anyone complaining about Gitlab going down constantly, maybe just a function of not being the default slop-forge in the AI era, but still, they've been a long time friend to my constant hackery.
Also, Microsoft sucks.
[0]: over the years the UI has gotten a good bit more cluttered and annoying, so there's probably slicker stuff out there. But it's fine.
[1]: some of this is definitely vibe-coded LLM-vomit but I mean a more general type of slop in this case - random throwaway code, half baked ideas, etc.
I joined a company that was using hosted gitlab. I really liked it, apart from it had the same uptime as github has now.
Features wise its about the same as github now, apart from organising repos is far simpler. Its not a flat list in an org, you can have sub teams in an org with thier repos neatly owned.
However the security story around them is not great, so I'm not really sure that I'd want to host a public instance of gitlab.
Opensource, decentralized and agent friendly I just asked my agent to do a git push in seconds no human involve
At work, we have repos on GitHub and Azure DevOps. Today, GitHub went down, but our repos (including PRs, CIs) worked as normal on Azure DevOps
A complete DevSecOps platform: Git forge, CICD pipelines, Private Registry, Issues/Planning, self-hosted or cloud.
Our team consists of long-time members from GitLab and DataRobot.
We are looking for design partners: ceo@branchyard.com
I think ultimately any company that goes this route will start benefiting from an IT team again though - instead of just pushing everything off to SAAS providers.
it gives you the obvious gitHub alternative: open-source, community-owned, privacy-respecting, non-corporate, and not built around turning your development workflow into a Microsoft-owned platform.
For self-hosted forges: forgejo is great but also cgit is pretty good for exporting repos.
With the recent GitHub fiasco I've split my repos across multiple forges. Git was always supposed to be decentralised so why store everything in one place?
Files of any size, centralized, and easy to use.
Hopefully forgejo gets federation in the near future because öets face it, opening an issue on Github is easy because you have an user there but you wont get one on my private forgejo instance. Also, a tool like gh for forgejo would be nice.
If you want to have an easy way to setup, have a look at https://yunohost.org/ that also offers lots of other nice stuff in its "app store" -> https://apps.yunohost.org/
I self-host using my own read-only, FOSS, pure PHP Git repository reader for personal projects.
Then all the GitHubs and Gitlabs of this world would be limited to just providing UI and would be unable to hold our data hostage by design.
There's no rebase, on principle. Branch names are permanent attributes of commits. Even abandoned branches remain visible forever. Code review is post-hoc.
People who are extremely accustomed to Git workflows may find the paradigm alienating.
1. batteries included single-file functionality (fossil binary + sqlite file and I have everything!)
2. Hosting them is super easy, I have a lighttpd server configured to do cgi-bin, and i just pop the project.fossil file onto the server and I have a project.
In the end though, I intend to use it for all of my personal projects from here out.
I have a pipe dream of turning a fossil repo into a portable distributed more-async-friendly slack clone, where the "chat", "wiki" and "forum" functionalities are all used as the back-end for a responsive UI that basically does the same thing that slack does, but lives in a single sqlite file + binary. It could run mostly offline in a kind of scuttlebutt/limited connectivity pattern (when online push/pull messages, get latest chats/files/etc, go back offline. As you go through the content, make your responses locally, then go back online, push/pull again, repeat.)
I have another pipe dream of making a RedBean APE fossil UI. I think it would be cool to have a single file universal executable that is my project repo.
Have never regretted the switch + I love the no AI policy.
If you only need git hosting, do whatever wherever you want.
i dont wanna get too crazy i just dont trust github with my code anymore
^1: in my recent experience, for my particular use cases
Would love for anyone to check it out!
Any recommendations?
For me it's action and PR history.
I was wondering when reading their sovereignty docs why I wouldn’t just use OVH as it is a French company instead of a USA based company, and lo and behold they are just reselling OVH.
I have used OVH personally and it has pretty good prices, but over aggressive DoS protection. Some of my workloads were shut down because OVH internal tools decided that what I was doing must have been a DoS.
As a Canadian I welcome a Canadian owned cloud provider, but it is a huge endeavour to build that platform up from scratch.
It does seem kind of weird that they are building both a CI system and a cloud, seems like they should pick one.
I haven’t the slightest clue why they didn’t use rook/ceph (they run on k8s) for this which not only is a very reliable block storage system, but also offers a S3 compatible API, and is proven at other cloud providers like Digital Ocean.
I wish them the best but there is no way I would put my data into there.
edit: I'll take their engineering culture over MS.
It made sense 6 years ago as I said before [0], today it makes even more sense to self host with GitLab, Gitea or Forgejo.
...Or we can repeat the same issues again with Cursor Origin [1].
- 1. your central code review (and hosting), which is the critical choke-point on team collaboration.
versus
- 2. the ever-expanding ick of testing, building, deploying it etc... because failure modes of software construction infra are concentrated here.
---
Use Gerrit if you care about code review.
Code review workflow is the nub / hub of collaboration, and should never be blocked on anything else failing, including itself. Maintaining robust in-house code review infra. is work, yes, but it is quite manageable. Simple "single-box with full point-in-time snapshot recovery" designs will remain good for a long, long time... Think; workloads of teams of up to a few hundred programmers and bots, who would be pushing and pulling updates against multiple repositories at a time on a single, well-endowed, Gerrit box.
2. CI/CD: Use whatever works best economically.
Be it one giant in-house box running Jenkins, or a clever way to use github and gitlab's job infra as fallbacks for each other.
These systems fail often because pretty much all the ick of software construction is concentrated here. Be it simple test runners, or fancy end-to-end auto-deploy to rollback pipelines.
The mind-numbing ick of software supply chain dependencies, test run jobs, build jobs, failures / retries, bursts of high contention (lots of people / bots needing their test runs passing NOW), pulling and pushing artefacts, and so forth.
This is a true pain to manage, particularly in organisations that are laissez-faire about their software ecosystem ("best tool for the job" mentality etc.).
And on a personal note...
--- <begin rant> ---
As if trusting enterprise chat SaaSes with all your company secrets wasn't bad enough. At least that has some contractual defensibility.
Had. Had... Now? Something is deeply wrong with people who aren't completely spooked by the current fad of letting hyperscalers steal literally everyone's data to make content and code re-production autobots. Based on how those companies have behaved from the get-go, and factoring in the overwhelming pressure the LLM industry has created to "become the biggest, no matter what, because biggest wins"; their "terms of service" are as good as their high-flying CEO's mood on a given day.
No thanks.
Besides, it's only been a hot minute since I adjusted to that other fait acompli of 21st century computing.
They who controleth thy hypervisor, controleth thy destiny.
--- Ye Olde Graybeard Wisdom
--- <end rant> ---
They do have a bunch of value adds, it just depends on which you use
I bet you could do it with like 10 prompts.