To all of those proposing self-hosted GitLab: we did it for 6+ years in my company, and it's not always a smooth sailing. We had our own runners and we made it auto-upgrade across docker images daily before business start. It mostly worked really well, except those few times were a Docker upgrade had to be rolled back, or that one time the bundled pg_shared_buffers was set at 1MB by default, making schema upgrades impossible for bigger instances, or a version major would break pipeline expectations forcing to upgrade 200+ repos at a time (we pinned to major afterwards). Lately I was also receiving an almost weekly "critical patch" newsletter due to critical/high vulnerabilities, which I can only imagine are due to LLM running over the code and identifying bugs.
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.
> 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.
Never forget the sudden GitLab price-hike and flavor feature changes just a few years ago. I was literally about to go from free to paid, when the pricing doubled nearly overnight. I left for Gitea.
I did and then rolled back. Gitea is far ahead in CI/CD features, which is the main thing I want from my own git forge.
And they also seem to keep adding more meaningful features, not just refactoring to keep some federation thing working.
My gitea instance was only ~6 DB migrations beyond where Forgejo was at when I decided to switch, so I just undo‘d those and upgraded anyways. Works just fine, but I was really lucky that they weren‘t any big migrations. I guess isn‘t really as feasible anymore.
Had the same experience, but the import feature works really well (with `ALLOWED_DOMAINS = *` in app.ini). Bad news is i had to do this individually for each repo. Good news is it went great and fast, even for private repos.
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!
This is pretty cool and one of the few things I couldn't find a viable alternative to in-house hosting so far. The only thing your "GitLab Runners as a Service" is missing is ISO 27001 (and optionally SOC 2) certification. That makes it again easier for your customer to get / maintain their ISO 27001.
Ha, let us look into ISO 27001 certification and see what it takes to obtain it (and SOC 2). Thank you for this valuable pointer! If you could just sign in (accounts are free and you can even try us out for the first 48h and not be charged), then we could message you to your email address once we have an update here.
I clicked 'Get started -> Login with GitLab.com' but for my tastes it wants way too much access just to add a runner:
> Grants complete read/write access to the API, including all groups and projects, the container registry, the dependency proxy, and the package registry.
> it wants way too much access just to add a runner
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!
I find the gitlab runner registration process a lot simpler than the github process, and a lot more flexible when you are self hosting the gitlab instance. We used kubernetes runners for both, and gitlab was clearly better.
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.
Right! That's why running your owners runners is so valuable as you've got full control over the cache location which clearly makes subsequent pipeline runs super fast.
Is it? Especially if you go the K8S route, setting up a runner infrastructure can be done within a day. Based on my experience, there isn't a lot of maintenance involved. It's mostly a smooth experience.
Thank you for building this, looks like it could be really helpful. We've been running our self-hosted GitLab with almost 99.99% uptime and a few runners but the configuration and update process has been a bit cumbersome. Will take a look at rocket runner.
99.99% uptime is impressive! So far our runners are likewise very reliable! It's just a Hetzner machine with our stack on top after all. Thanks for trying us out and please drop us an in-app message for any questions or comments!
ex-GitLabber here, and yes this is a pretty common scenario. GitLab as a product is pretty good, however GitLab Inc, is not great at supporting the broader community especially the SMB-Mid tier self-hosted users. (If you're big enterprise you'll get white glove support)
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.
As someone who used to submit issues to Gitlab just to see them stagnate for 6-8 years and then ceremonially get closed after being stuck in management/release bump hell (along with many 'me toos' from both Gitlab premium support staff / 3rd party contributors) I agree with your statement 100%.
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.
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
Really? I've been very happy with how easy GitLab Runners are to manage. We were running 20,000 jobs a week on 6 bare metal boxes and we had tons of spare capacity. Simple Ansible script to deploy the runner and register it. Tags for t-shirt sizes to set the amount of CPU/memory allocated to each job container.
Maybe running on Kubernetes or some autoscaling solution is more painful.
When it works, it's great. When it doesn't, good luck figuring out why.
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.
> 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...
4 years of running production GitLab on nightly is very impressive! I would never have imagined you could last that long. Clearly the quality of GitLab releases is much higher than I imagined.
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.
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 ...
This thread is about full-featured forges like github/gitlab.
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.
- you don’t need runners on remote machines unless you you have hundreds of jobs and which never happens for small or medium size dev teams
- job matrix / parallel jobs are barely needed in commercial development , only in open source , but still not in every project
- pull requests and user management are coming soon
maybe if you only do web? But not every development is web development, you know.
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.
- long ci builds usually means bad code / architecture . CI should not be very heavy and should not take a lot of time.
- 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
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.
If all you want to do is host repositories, “just” is the appropriate word here. For lone wolf work, all I care about is having a remote that mirrors all the changes and branches I create locally. It’s just redundancy. A git bare repo and SSH are all that’s needed.
I don’t do pull requests to myself, and I don’t need a bug tracker or CI.
I hadn't read this article until now, but I started catching myself using the word at work a few years ago and I've actively been trying to avoid using it for the reasons laid out in this post.
I didn't check if this was mentioned in the article but I've heard it described as a "lullaby word". I think that is very apt, and I have stopped using it whenever I can.
I think they mean the "just" in "Do you just want to host repositories?", implying that it's never "just" hosting repositories, and the needs will continue to grow beyond what the simple solution offers.
That's what gitolite does with some helper scripts for creating/setting up the repositories, adding metadata to the configs, etc. That way your `git` user can be set to reject ssh login attempts. The projects are managed by pushing a config to a gitolite admin repository.
It is much more complex than this to get basic GitHub functionality anyone who has tried can tell you that. It feels like it should be a simple command but it absolutely isn’t
Yes it is not so straight forward to be able to push/pull from a repository over ssh especially with multiple users etc there are a bunch of additional configs required for this
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
Yeah. MicroVMs make hosting runners pretty straightforward. I had codex make a forgejo runner controller which pulls forgejo actions and creates kubernetes jobs for them.
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.
Agree. I'm always surprised Github still uses huge fat VMs. I imagine this is one of the things that make it much painful at scale. The tricky part with microvms are getting them to run cross-platform. We use an awesome project called smolvm that builds on libkrun and makes this alot easier. As an aside, how have forgejo actions worked for you in practice?
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
If you want something cross-platform, smolvm or microsandbox are great options(built on top of libkrun vmm)! If you are looking for linux-only, the typical choices are firecracker-based solutions.
I'm a little disappointed, because your comment made it look great, but when i look at >1000 commits in 2 months and inspect a few commits randomly, it looks like 100% slopware.
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.
Much of the code was certainly written by agents, as is most of the code now. That said, there's a big difference between "vibe coding" and "agentic coding". The latter requires careful and thoughtful design and review. I've invested heavily in different kinds of guardrails to ensure conformance. An effort like this would not be reasonably feasible without agents or would take significantly longer(act has been around for 5+ years and is still maybe about 70% or so compatible with the official protocol). We'll keep improving it. I hope we'll earn your trust eventually.
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.
If you want (4) and don't care about a web interface for managing repos, but do want Git-LFS, Soft Serve (https://github.com/charmbracelet/soft-serve/) works pretty well. I used it for self-hosted stuff until I started needing other features Forgejo offers.
For issue tracking you may also be interested in Epiq. It is git-native, vendor agnostic, and distributed. Comes with a command line TUI, a browser GUI, mcp, and more. Also event sourced state with replay, which is super powerful for auditing workflows.
7. Do you want to impress the old Solaris admin that still wants to live like it's 1997? Use SVN hosted on an ancient Thinkpad with everything hosted on an ancient spinning disk external hooked to eSATA
> 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.
Having people personally go out of the way for a little bit of friction tells you how valuable, and perhaps, serious these people are. I'd rather have that group of people contributing to my projects than fly by night agents that just shit all over the floor and expect treats for doing so.
Contributions aren't just commits/prs. It's also opening issues. The harder it is to provide feedback, the more likely users are going to seek a different library or tool, and depending on the actual objective of releasing or publishing code, that is not ideal.
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.
Don't think open submission feedback is worth much anymore, at least not the amount of effort it requires to curate it. Having friction still seems like a great way to get decent feedback nowadays rather than needing to manually curate 100s of issues where 98% of them are spam/garbage.
That's fine if the projects are in a single place (e.g. GitHub) as you only need to create one account.
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.
That's fine, maybe they don't want casual users like you to be part of their community. There is a reason to prefer group coherence over availability. Availability doesn't actually help the group for most online communities, it's actively a hinderance.
CodeBerg comes with the advantage that Euro social democrat style moral superiority comes for free. Never mind it has worse performance under less load and its bet for dealing with the future is treating anything LLM related as hostile.
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.
https://tangled.org! Founder/CEO here. We're a new forge building things from the ground up, and are fully federated -- you can host your git repos on your own infra, along with the CI runners. We've also got a pretty neat set of features (if I may say so myself): stacked PRs, Nix-based CI (if you want it), and a fully open protocol (https://atproto.com) to for you and your agents.
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.
Arguably the "social coding" angle is the reason why Tangled is the only actual alternative to GitHub. Otherwise there's actually plenty of other alternatives to GitHub, but none of them have GitHub's punchcard, which I'm ashamed to admit is the primary draw for me.
I'd like to know if most people use GitHub because of the social network part, or other reasons. I, for one, hate the social network part.
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.
One may want the federation ("I can use all those forges without creating multiple accounts" and "I can open a pull request from my forge into another forge") without wanting the social network angle, right?
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.
There's not a big need for federation if it's already decentralized. Either way you can do some research on other options, no one is forcing you to use one or the other.
And you can just use Tangled without the social network aspect. I don't see why you don't want me to use Tangled just because I don't like the social network aspect?!
Why would I care what you use? I just said perhaps @theamk is not the target market if they don't like the social network aspects, and then you replied to me, so I'm not sure why you're on my case specifically. Use what you want.
You're reading too much into my comment suggesting an alternative. As I said, I don't care what you use and you can take my suggestion or not, I'm not telling or commanding you to use it.
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?
Daniel Holmgren from bluesky is working on permissioned data for ATP [1]. Once that lands tangled will probably add unlimited private repos and extra CI compute on the first party servers as a paid feature.
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.
I recently got a spindle and a knot set up on my home server (along with Tranquil PDS). A few rough edges that we got ironed out but it's cool to have all of that self-hosted on my own machine yet still part of the AT proto world! I'll be honest, I'm not putting anything critical on it yet but that's my lack of trust in my own home server setup not doubt in Tangled's infra!
A better web UI for the queued jobs on my spindle would be great btw!
I'm not an AT Proto wizard (there's a lot of good text and video explainers out there) and I know that Tangled is building on it but also adding their own functionality. But from a high level, I register my 'knot' with my account on Tangled.org which is exposed through a public domain. In my case that's routed through a Cloudflare tunnel to a reverse proxy running on my server. Tangled is then running an "app view", which is basically an aggregate of a subset of AT proto activity. So my commits, PRs, releases, etc go into the app view which then points traffic back to my server. So the long and short of it is the app view is the missing piece of the AT proto system and you have to register your data with an app view provider, of which Bluesky is the most prominent. But there are open source app views, in fact the Tangled team just announced one called bobbin that's super resource light.
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.
Just signed up, so not much to report yet, but one thing I noticed is that, because the sign in is on tngl.sh rather than a subdomain of tangled.org, it might be confusing for some users, especially as the sign in page has a very different design, theme and layout to the rest of your website and tangled as a whole. Additionally, my password manager didn't show the just created password due to the URL mismatch. Perhaps this could be addressed to improve the experience.
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.
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.
I love jj and am a fan of the ideas of AT protocol, so tangled has been on my radar for a while. Last I checked though, it sounded like it was much better suited for open source code, not private repositories. Is that still the case?
I recently set this up on my homelab, not really expecting to switch to it, more out of interest. But wow, after I saw how unbelievably fast it was, I’ve moved everything over. I’ve now set it up to mirror things automatically to Github if I want to make them public.
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.)
It's based on act[0] so it's quite like GitHub actions but not completely [1].
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.
Agreed. GitHub Actions feels like someone's science project created while on a mushroom trip. Really you just want a thing that executes a shell script in a runner.
You can use any CI/CD you want. The only reason GH is popular is that it's free for public repos.
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.
> The only reason GH is popular is that it's free for public repos.
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.
For a forgejo host, check codefloe.com if what you need is a place to host personal projects or smaller teams. It’s been rock solid and it is now the default choice for anything outside of work I’ll do.
I don't have any specific recommendations other than do as little in your CI/CD as possible, instead do as much as possible in your build system or scripts that get called by CI/CD. This way you can migrate with less work or run locally when you want.
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
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.
If you know GitHub actions then you’ll immediately understand Forgejo actions. It was designed that way intentionally. There are some differences, but at least for me not enough to warrant any pitchforks.
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 migrated everything to codeberg several months ago (and created an annual donation schedule). I was never a big fan of github but what ultimately pushed me to ditch it was the way github was shoving copilot/chatgpt in my face without me ever asking. Codeberg has a clear stance on that and it's a stance I can totally get behind.
In addition I spun up forgejo at a server at home for very critical stuff and it's awesome.
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.
> Their own site reports the 2 week uptime at 1 nine
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.
The link you provided has shown a nearly perfect uptime. Your statement doesn't reflect the proof.
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)?
The reason for switching was shoving all the slop down my throat, even when just browsing. There are a couple of things I have published and a handful of others I plan on open sourcing some day so for the purpose, codeberg does a brilliant job. For work - meh i'm in a corporate environment running internal repositories on company servers so that's less of an issue still.
I strongly disagree with the assumption that GitHub's alternative is another centralized forge. Git itself is perfectly decentralized, as was the original Linux kernel development process. How people managed to put all their eggs in one intermittently available service is beyond me. Moving the eggs into another bucket is not a solution (like Microsoft is short of servers). The SPoF is the problem. There are plumbing, porcelain and "github" layers. The "github" part has to be decentralized as well. Then, using a particular forge will be a choice of convenience, not necessity. https://replicated.live/blog/crdt
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.
Why use e-mail? That was 20 years ago. I developed my own local setup that is like GitHub for me and agents, see the link. Everything is a repo, may pull and push tickets, docs, everything. That was not a major effort, unless you count 20 years of experience.
> 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.
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 screwed because I am part of an ecosystem that all lives in github.
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.
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:)
Not who you asked, but I was going to say Actions or CI/CD from when I tried out Gitea a few years ago (back when running a Jenkins instance was more normal) but looks like Gitea supports that kind of workflow now: https://about.gitea.com/products/runner/
Two of the big issues I had were around the user/repository forced structure. That works to some extent when you have multiple users with a small number of repositories. But for my personal projects I wanted more control over the structure and grouping.
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 want org-mode markup support for the wikis and readmes. Github supports this, and gitlab sorta does. You should hook up pandoc to it, and support everything it can handle.
Forgejo is splendid. Codeberg is a hosted instance; depending on what you’re developing it may or may not be a good fit for you. But the Forgejo stack itself is decently light-weight to self-host, very fast to use, and is easy to navigate.
> 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.
You've made the same exaggerated claim in two comments. Not only are you not banned from Codeberg if you have used LLMs to help you write code "in any of your projects", but you're not even prohibited from using LLMs to help you develop projects that you host on Codeberg.
I feel like you just directly contradicted yourself so there must be some nuance I am missing. Or is the key word "mostly"? Like I can use LLMs to help the work but still have to type most of the code myself?
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"?
I suspect the fidelity of your comment to your actual level of confusion is low. In any case, if you're really this confused by the information provided earlier, then the chances aren't good that there's anything that anyone could say to get you unconfused.
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.
It's not exaggerated. If you use AI at all for any code in the project it cannot be hosted on codeberg. They made that pretty clear in their blog post.
> If you use AI at all for any code in the project it cannot be hosted on codeberg. They made that pretty clear in their blog post.
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?
I personally host a forgejo instance on a private VPS ; so far almost no maintenance except protecting it from ai-crawlers[#1]. If you don't want the hassle, codeberg.org is a public instance of forgejo.
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
We switched our entire product studio to a self hosted Forgejo https://forgejo.org/ and honestly this has been one of our best decisions:
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
my favourites are sourcehut (that has excellent ci, and does not try to be a github clone) and codeberg (with slightly more straightforward migration path from github)
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?"
The specific wording sounded a bit judgy to me as well, but I think it's a totally reasonable question. They're just asking about the capability of a product.
It is prejudiced. If you like sending patches over email more power to you, but there’s a reason 99% of the world’s devs does not follow that workflow.
Email was always designed for human to human messages. Patch files need strict formatting (like anything that needs to be machine readable). That means you need to install extra tools, point them at your mail server, configure the mailing list address and proper formatting for each project, then find the right commit range and type in the description into a command line editor every time you send a patch series. The alternative is doing everything manually and that takes even more effort.
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.
Feels like you make the email workflow sound more complicated than it is on purpose. One could do that with the PR workflow as well.
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.
I don't want to ignite an argument, but this feels like Linux v Windows. You should absolutely switch because you hate dealing with it, but the less-popular choice is going to be less popular everywhere. Your next job will very, very likely not care about your personal hatred and will simply force you back into the default, popular choice. It is sometimes best to stick with what (mostly) works for everyone unless you want to go down the path of learning another tool.
Honestly a lot of the complaints about migration feel to me like the result of poor management of actions etc. If your CI etc is so inextricably tied to github you were never doing it correctly
Self hosted GitLab has been good to me forever and has scaled and has a controllable attack surface as long as you keep on top of it
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)
Creator of GitSocial here: it's a Go binary CLI/TUI that lets you store all your issues, PRs, etc. in the git itself and self-host on any S3-compatible bucket: https://gitsocial.org/.
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!
If you are frustrated with Github being down again, and just want an alternative, the other options listed are better fits. If you have the time to look at doing more than that, then check out fossil https://fossil-scm.org/home/doc/trunk/www/index.wiki
- 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.
I've sorta overlooked Fossil a lot (mostly because it's not git...), but just browsing some instances on chisel and the fossil homepage has me intrigued.
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.
I can entertain you since no one else has so far. I've been using Fossil since 2009.
> 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.
Fossil looks really cool. I like how it's all in one and includes the web interface. The only thing is it doesn't seem like anyone actually uses it outside of sqlite. I don't necessarily need to use the most popular thing out there, but some social proof is nice.
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
Bitbucket was the perfect alternative. I used it back in the day when they were the only ones who offered free private repos. Ahead of their time.
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.
It’s interesting how under the radar Bitbucket is these days.
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.
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 got to know about https://opensats.org/projects/ngit when I worked at OpenSats as a writer for some short three months. Idk much about ngit though, so I can't vouch for it. Yet, some very fascinating nostr-based github stuff. There are others, too, but I can't remember them by name. With some light surfing you can see other implementations.
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'm mostly using GitLab right now, both self-hosted and their hosted platform.
But am curious about Cursor Origin and certainly plan to try that out when it's available.
A big thing with Github its the unified functionality across most of the OSS world - that we can search across all projects, leverage pipeline actions from other projects, and easily have a single dashboard for our own contributions and interests across all projects.
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?
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.
I was one of the members who was a part of the initial grant for federation in Gitea, but sadly due to illness and other similar neither I nor my teammate were able to work on the grant (so no funding ended up being released), however the work we did start was completed, and we have continued to work on foundations since. Since spam/moderation/limitations are so significant we are focused on that portion first, since we don't want to open up another vector for it without having at least the minimum of protections in place. We have also been extremely fortunate to have experienced developers who do work on existing federated software share so much of their time, expertise, and experiences with us to help shape our work.
That would be good for following, but I'd worry about contributions. Single-sign-on would help but if you're going to ask the user to create a new username+password to log a bug you're not going to get bugs from anybody except your most hardcore users.
Also, unified dashboards/notifications are so useful (even though Github's notification UI is a bit mediocre, imho).
That's the chief differentiator you're giving up when you give up on github vs a self-hosted forge. And the network effect of the CI pipelines should not be discounted since it means actions published anywhere on GH are automatically available for use without any import or install step.
Yes, you could feasibly split off the CI from the git+PR service, but you'd still want it to be federated.
Pipelines are not magic. You want a couple of primitives in there, variable substitution, maybe lite secret management. Depending on the type and languages you work across they could also be 100% unique to each company, language, project, and industry. LLMs have also further made pipeline creation pretty trivial.
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.
I self host Forgejo on a cheap VPS with hourly borg backups to rsync.net. It's a great system and seems comparable to github, although I'm not a heavy user of actions on either platform. I do use the container registry though. It was a smooth transition and easy to install. I used the docker installation method. Forgejo is great if you don't mind hosting yourself.
I've had both self hosted GitHub (enterprise), and GitLab in the last year. It really deoends what you're trying to replace and how you structure the things you're hoping to replace. Also, the value of investing in your separation of concern or safety valve.
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.
I'm building my own - https://git.zserge.com/fierj - and for a few weeks it's hosting itself. Still working on patches workflow and CI, but it's quite usable already. I try to make it "minimally federated" - only threads (issues/discussions etc) are federated via ActivityPub, for PR there is old-school patches workflow, for CI just chroot and a shell script. A lightweight personal git forge in ~4KLOC. Can't say everyone should use it and can't recomment it, but building a personal forge is very realistic. Or you can run cgit as a frontend to your git remote on a server.
Because China is a terrifying country with no real notion of human rights. Basically all Chinese companies (including Tencent) work closely with the government and do what they want under threat of arrest. There’s no way I’m uploading my data to China where their government can get at it whenever they want.
Whatever you do, you should self-host it. Then you aren't going to be at the mercy of some third party when they start to get hammered by vibe coders doing an insane amount of traffic. Forgejo is a great option if you want something git-based. I'm personally very partial to Fossil, it works well and is dead easy to set up.
My setup is a self hosted GitLab. From there, in most of my repos I setup repo mirroring (basically it just does its own SSH-based git push whenever I push commits to it) to GitHub, GitLab, and Codeberg.
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.
https://git.cafe if you want a team focused entirely on building a better forge experience rather than a github clone and don't want to deal with hosting yourself (and yes jj support is built in)
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.
to your actual question, no, it really doesn't make sense. The problem is you are saying it is down consistently.... and it's not. You can switch if you want, but from my observations, it's not really that often, and those that do switch make a bunch of compromises when they do. I'd only consider it once you actually measure the impact to your business. Based on actual data and not feelings, then consider whether it is worth it given all the costs of switching. We use it all the time and at most, may have had 30 minutes where we were stuck.
I've been self-hosting Gitea for years, and moved everything I had on GitHub off at the time of the Micro$oft takeover.
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.
I have a pretty bad taste in my mouth from GitHub, GitLab, Forgejo, Gitea, etc. They all attempt to hijack Git itself and become a monolith and single custom interface, rather than independent components that work around the Git repo. I want the Unix philosophy applied to Git and other functions. That way I'm not forced to switch the entire kitchen sink out when some single piece of functionality or hoster ends up breaking things.
That's not really what I'm looking for. Radicle is trying to define specific functionality the system supports: a single protocol which combines multiple separate use cases into one standard.
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.
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.
"Forgejo was created in October 2022 after a for profit company took over the Gitea project. It exists under the umbrella of a non-profit organization, Codeberg e.V. and is developed in the interest of the general public."
I've been a Gitlab fan for a long time[0]. I typically default to GitHub for my repo slop[1], but if I'm doing something serious I put it in Gitlab. I like their CI setup better than GitHub and there's also self-host options if any of those "serious" projects ever needs that.
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've used github for ~12 years, and it was fine for single repos, but it sucked _hard_ for any kind of organisation. It also sucked really hard for CI.
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.
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.
I set up Forgejo on my FreeBSD home server the other week, it's been working fantastically. All the features I need, snappy, easy to install.
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.
Maybe the big cloud’s git solutions? Not to say the are good alternatives, but for teams already on the clouds, they could be a easier migration with somewhat feature complete, uptime, security promises that execs are looking for.
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
For SaaS forges there's also upd.dev launched recently.
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?
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.
Like others I migrated from github to codeberg. But since lots of my projects are coauthored with Claude I moved to self hosting Forgejo on a small Hetzner instance which also does some static hosting. So far working well. I think some cross platforms stars and search would be good.
I moved recently to Gitoro with private projects, but do not have any meaningful opinion about it yet. It works for me, it’s fast, nothing to complain about. Just mentioning it here as EU-hosted alternative.
if you want to work on personal projects and store personal data, use gitLab; if you’re working on open-source projects, use codeberg. codeberg is a nonprofit organization dedicated to open source, so their storage policies are quite strict. gitLab offers 10gb of storage with no restrictions, and their data policies are much better than gitgub’s
if you want full control and to deploy on your own, consider forgejo for an experience similar to github actions. If you’re used to gitlab’s pipelines, set up your own private gitlab instance
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.
this is our stack too, we initially ran BuildKite but switched to Woodpecker for Forgeo. Coming from Github there's a few basic things that are missing in woodpekcer that may frustrate you but it's improving regularly.
Try self-hosting Gitea with push mirror to GitLab or GitHub. Gitea is powerful and lightweight, and a push-mirror to another service is a plus as a backup location.
I have been hosting gitea for our small org (docker + sqlite) for close to 5 years now. ~50+ repos, some large. All upgrades, including major changes, have been as easy as just changing the tag and reloading the container.
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
Thanks! Yours looks good too! What would you say is the difference with Slack connect? I find slack connect to be pretty painful once you have n > 50 channels
A big difference between Probed and Slack Connect is being able to create public community channels where all your users can talk to each other. You also get a feedback system, a public roadmap, and other features to help foster that community-driven growth.
I loved the simplicity of Amazon CodeCommit. Unfortunately, Amazon decided to deprecate it, no new provisionion but existing accounts could remain. I'd love it if someone else offered a similar product.
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 love Fossil, I have been using it for all of my projects for the last couple years. Things that I love include:
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.
The biggest friction is managing users across repos. Each repo is its own RBAC, the "zhynn" user in one repo is not the same as the "zhynn" user in another repo. It would be cool to be able to sync users across repos, which should be possible with sql, but I think that it could get weird with repo-specific permissions. Currently I just add my user to each new repo, granting that user setup permissions, and removing the admin before I scp the .fossil file up to the webserver.
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.
Those two pipe dreams sound really cool! Do you have a website or something to lurk you via if you eventuality get around to those? I find it difficult to keep up, as it were, using form histories and other social media platforms.
The workflow is paradigmically different, and that may throw many people off.
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.
Yep, it’s not for everyone, and their docs are pretty clear about that. OTOH those same docs contain a variety of arguments that git isn’t really designed for everyone either and that fossil might be a better fit for projects that have just one or a handful of developers, which AFAIK is the vast majority of projects on Github. My experience is that it is certainly an adjustment but the docs are good at explaining (and justifying) the differences, and the built-in features are very useful, especially for anyone looking to reduce their dependence on a centralized host that’s become unreliable.
Epiq also solves this with a git-native backend, so it is vendor agnostic and adheres to a issue-tracking-as-code paradigm. It is therefore distributed, has a TUI + browser GUI, mcp server, and so on.
It is also event sourced, and supports state replay from beginning to end, so very powerful for auditing workflows, whether that be your own or a swarm of agents.
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.
My org self hosts the community version of gitlab and we are perfectly happy with it. Manage your own infrastructure, put the work into maintaining it and you'll have much fewer headaches.
I'd like a self-hosted primary option as the source code repository, but I'd like to mirror the code in one of the usual external options, anyone done anything like that?
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
I'm one of the project leads of Gitea and we've put a ton of work into Gitea Actions, I'd be interested in any compatibility gaps that you've run into.
oh hello, thank you for your work on an excellent product! one small difference i ran into last weekend is that foregjo forwards the FORGEJO_TOKEN in the environment to composite actions so that they don't need to have a required "token" input.
mind trying https://github.com/preloopdev/preloop? We follow the official runner protocol 100% so we should hopefully have more workflow-compat.we also run in cross-platform microvms, not docker containers.
We've added some things like CI, Windows support, and starting some work on path-based permissioning for monorepos. These are still in the early stages so not documented that great yet and need to be tested a little bit more. Should have more updates in the next couple weeks.
dunno how it works but Cursor just released its own alternative Origin and looks pretty good integrated to build agents and ship them quickly using one ecosystem, so will be worth it give it a chance
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.
What "culture"? I've seen Cursor's AI-coded web browser... which was released with parade despite not even compiling and being just millions of lines of glue code over external libraries actually doing the real work.
My org's GitHub Enterprise never goes down. The feature set is almost the same, though it lags a few months behind. At least you don't have to learn anything new.
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
Old skool is best skool... There is wisdom in keeping these decoupled:
- 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.
---
1. Code review (and hosting): Keep this in-house always.
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> ---
I strongly prefer to keep it all in-house. Proprietary software is oil - capital. Own it fully, no exceptions. This was true "back then", and it has become even more business-critical now, for obvious reasons.
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.
I wonder how hard it would be to vibe code a super basic gitea/gitlab clone (or a very stripped down version) that's designed to just have basic authentication w/ssh, some basic main branch protections, simple code review, etc... and runners with some simple YAML language.
To all of those proposing self-hosted GitLab: we did it for 6+ years in my company, and it's not always a smooth sailing. We had our own runners and we made it auto-upgrade across docker images daily before business start. It mostly worked really well, except those few times were a Docker upgrade had to be rolled back, or that one time the bundled pg_shared_buffers was set at 1MB by default, making schema upgrades impossible for bigger instances, or a version major would break pipeline expectations forcing to upgrade 200+ repos at a time (we pinned to major afterwards). Lately I was also receiving an almost weekly "critical patch" newsletter due to critical/high vulnerabilities, which I can only imagine are due to LLM running over the code and identifying bugs.
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.
> 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.
Never forget the sudden GitLab price-hike and flavor feature changes just a few years ago. I was literally about to go from free to paid, when the pricing doubled nearly overnight. I left for Gitea.
https://news.ycombinator.com/item?id=35144974
Have you looked at migrating to Forgejo? It’s a fork of Gitea though I think it has diverged significantly since the fork.
I did and then rolled back. Gitea is far ahead in CI/CD features, which is the main thing I want from my own git forge. And they also seem to keep adding more meaningful features, not just refactoring to keep some federation thing working.
Interesting, thanks for the perspective. I’ve heard about both in various ways. Obviously some people like one over the other.
I migrated my Gitea instance to Forgejo, it was pretty painless
I accidentally upgraded my Gitea instance beyond the fork which makes this more difficult...
My gitea instance was only ~6 DB migrations beyond where Forgejo was at when I decided to switch, so I just undo‘d those and upgraded anyways. Works just fine, but I was really lucky that they weren‘t any big migrations. I guess isn‘t really as feasible anymore.
Had the same experience, but the import feature works really well (with `ALLOWED_DOMAINS = *` in app.ini). Bad news is i had to do this individually for each repo. Good news is it went great and fast, even for private repos.
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/
This is pretty cool and one of the few things I couldn't find a viable alternative to in-house hosting so far. The only thing your "GitLab Runners as a Service" is missing is ISO 27001 (and optionally SOC 2) certification. That makes it again easier for your customer to get / maintain their ISO 27001.
(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...)
Ha, let us look into ISO 27001 certification and see what it takes to obtain it (and SOC 2). Thank you for this valuable pointer! If you could just sign in (accounts are free and you can even try us out for the first 48h and not be charged), then we could message you to your email address once we have an update here.
You’re on for a ride. Set at least 50k on the side for that.
I clicked 'Get started -> Login with GitLab.com' but for my tastes it wants way too much access just to add a runner:
> 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.
> it wants way too much access just to add a runner
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!
I find the gitlab runner registration process a lot simpler than the github process, and a lot more flexible when you are self hosting the gitlab instance. We used kubernetes runners for both, and gitlab was clearly better.
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.
Right! That's why running your owners runners is so valuable as you've got full control over the cache location which clearly makes subsequent pipeline runs super fast.
Is it? Especially if you go the K8S route, setting up a runner infrastructure can be done within a day. Based on my experience, there isn't a lot of maintenance involved. It's mostly a smooth experience.
Thank you for building this, looks like it could be really helpful. We've been running our self-hosted GitLab with almost 99.99% uptime and a few runners but the configuration and update process has been a bit cumbersome. Will take a look at rocket runner.
99.99% uptime is impressive! So far our runners are likewise very reliable! It's just a Hetzner machine with our stack on top after all. Thanks for trying us out and please drop us an in-app message for any questions or comments!
Looks pretty cool!
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.
ex-GitLabber here, and yes this is a pretty common scenario. GitLab as a product is pretty good, however GitLab Inc, is not great at supporting the broader community especially the SMB-Mid tier self-hosted users. (If you're big enterprise you'll get white glove support)
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.
As someone who used to submit issues to Gitlab just to see them stagnate for 6-8 years and then ceremonially get closed after being stuck in management/release bump hell (along with many 'me toos' from both Gitlab premium support staff / 3rd party contributors) I agree with your statement 100%.
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.
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.
Yeah, it's mind blowing to me that GH still doesn't have a branch viewer in each repo.
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
Really? I've been very happy with how easy GitLab Runners are to manage. We were running 20,000 jobs a week on 6 bare metal boxes and we had tons of spare capacity. Simple Ansible script to deploy the runner and register it. Tags for t-shirt sizes to set the amount of CPU/memory allocated to each job container.
Maybe running on Kubernetes or some autoscaling solution is more painful.
When it works, it's great. When it doesn't, good luck figuring out why.
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.
Maybe give https://rocketrunner.io a try? We made super easy and fully managed GitLab CI/CD runners for GitLab.com or self-hosted GitLab servers :-)
(Sorry for posting this twice, but we'd really love to get more user feedback)
> 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 "*".
> 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...
4 years of running production GitLab on nightly is very impressive! I would never have imagined you could last that long. Clearly the quality of GitLab releases is much higher than I imagined.
> on nightly
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.
Not bad resource wise at all for something serving 50 to 100 people. Don't forget a second machine for HA or at minimum DR !
gitlab.com and selfhosted gitlab in various companies in the last few years
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 ...
This thread is about full-featured forges like github/gitlab.
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.
- you don’t need runners on remote machines unless you you have hundreds of jobs and which never happens for small or medium size dev teams - job matrix / parallel jobs are barely needed in commercial development , only in open source , but still not in every project - pull requests and user management are coming soon
maybe if you only do web? But not every development is web development, you know.
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.
- long ci builds usually means bad code / architecture . CI should not be very heavy and should not take a lot of time.
- 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
Whoever downvoted this ^^ my comment I need your reasoning … I don’t know why people hate simplicity ) ( or love complexity )
it is a simpler set of services at the expense of a more complex user experience
What is more complex user experience? Writing pipelines on YAML gets complex indeed
CI should not be any different from regular programming
It depends on what you are after?
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.
> 4. Do you just want to host repositories?
an ssh connection and
on your ssh accessible server works just fine“Just” is a four letter word and a trap our industry repeatedly falls into.
https://sgringwe.com/2019/10/10/Please-just-stop-saying-just
If all you want to do is host repositories, “just” is the appropriate word here. For lone wolf work, all I care about is having a remote that mirrors all the changes and branches I create locally. It’s just redundancy. A git bare repo and SSH are all that’s needed.
I don’t do pull requests to myself, and I don’t need a bug tracker or CI.
I hadn't read this article until now, but I started catching myself using the word at work a few years ago and I've actively been trying to avoid using it for the reasons laid out in this post.
I didn't check if this was mentioned in the article but I've heard it described as a "lullaby word". I think that is very apt, and I have stopped using it whenever I can.
But sometimes it's applied properly! https://github.com/casey/just
Is that a just cause?
i used to feel the same way, but with coding agents, the Justers are surely having the last laugh
edit: totally wrong
I think they mean the "just" in "Do you just want to host repositories?", implying that it's never "just" hosting repositories, and the needs will continue to grow beyond what the simple solution offers.
> the needs will continue to grow beyond what the simple solution offers.
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.
I must be illiterate. Ofc. Sorry
It can be as brief as:
ssh server git --bare init myrepo.git
git clone server:myrepo.git
You can even support Actions with this method if you're not afraid of a little scripting. https://git-scm.com/book/ms/v2/Customizing-Git-Git-Hooks
> git clone server:myrepo.git
or if your local repo existed first:
Beautiful !
That's what gitolite does with some helper scripts for creating/setting up the repositories, adding metadata to the configs, etc. That way your `git` user can be set to reject ssh login attempts. The projects are managed by pushing a config to a gitolite admin repository.
Cool thing about gitolite is that you manage it using text files and committing to the gitolite admin git repository.
We were using it until we grew tired of not having a web view to comment and review patches so we switched to gitea.
At least in small scale, having your own git server is trivially easy. Why are organizations so eager to put a third-party layer on top of that?
It is much more complex than this to get basic GitHub functionality anyone who has tried can tell you that. It feels like it should be a simple command but it absolutely isn’t
> 4. Do you just want to host repositories?
Yes it is not so straight forward to be able to push/pull from a repository over ssh especially with multiple users etc there are a bunch of additional configs required for this
once you add multiple users, bare git stops feeling "just" pretty fast. do you need reviews/CI too, or only shared access?
Quick intro for this method: https://www.youtube.com/watch?v=iuIdBfjL62s
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
Yeah. MicroVMs make hosting runners pretty straightforward. I had codex make a forgejo runner controller which pulls forgejo actions and creates kubernetes jobs for them.
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.
Agree. I'm always surprised Github still uses huge fat VMs. I imagine this is one of the things that make it much painful at scale. The tricky part with microvms are getting them to run cross-platform. We use an awesome project called smolvm that builds on libkrun and makes this alot easier. As an aside, how have forgejo actions worked for you in practice?
Re Forgejo actions, I'm just toying around.
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
Any other recommendations for microvm ? Need to mess around with them again. Always seemed like the future
If you want something cross-platform, smolvm or microsandbox are great options(built on top of libkrun vmm)! If you are looking for linux-only, the typical choices are firecracker-based solutions.
I'm a little disappointed, because your comment made it look great, but when i look at >1000 commits in 2 months and inspect a few commits randomly, it looks like 100% slopware.
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.
Much of the code was certainly written by agents, as is most of the code now. That said, there's a big difference between "vibe coding" and "agentic coding". The latter requires careful and thoughtful design and review. I've invested heavily in different kinds of guardrails to ensure conformance. An effort like this would not be reasonably feasible without agents or would take significantly longer(act has been around for 5+ years and is still maybe about 70% or so compatible with the official protocol). We'll keep improving it. I hope we'll earn your trust eventually.
Nah, LLMs and agentic coding is a reality. It's here, it will stay here, and will only grow.
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.
Sourcehut is fantastic because you can also SSH into the CI machine.
If you want (4) and don't care about a web interface for managing repos, but do want Git-LFS, Soft Serve (https://github.com/charmbracelet/soft-serve/) works pretty well. I used it for self-hosted stuff until I started needing other features Forgejo offers.
Or just push to an S3 bucket with `gitsocial mirror <s3>`
For issue tracking you may also be interested in Epiq. It is git-native, vendor agnostic, and distributed. Comes with a command line TUI, a browser GUI, mcp, and more. Also event sourced state with replay, which is super powerful for auditing workflows.
7. Do you want to impress the old Solaris admin that still wants to live like it's 1997? Use SVN hosted on an ancient Thinkpad with everything hosted on an ancient spinning disk external hooked to eSATA
and you can stream your commits into any of these to improve deployment and commit availability when github is down.
*Forgejo
It's great for lightweight self hosting
Indeed. I've edited my post to fix the typo.
Forgejo == Codeberg
Not exactly:
> 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/#...
isn't forgejo the software and codeberg is hosted forgejo?
Codebergs has a section about that: https://docs.codeberg.org/getting-started/what-is-codeberg/#...
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.
Having people personally go out of the way for a little bit of friction tells you how valuable, and perhaps, serious these people are. I'd rather have that group of people contributing to my projects than fly by night agents that just shit all over the floor and expect treats for doing so.
Contributions aren't just commits/prs. It's also opening issues. The harder it is to provide feedback, the more likely users are going to seek a different library or tool, and depending on the actual objective of releasing or publishing code, that is not ideal.
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.
Don't think open submission feedback is worth much anymore, at least not the amount of effort it requires to curate it. Having friction still seems like a great way to get decent feedback nowadays rather than needing to manually curate 100s of issues where 98% of them are spam/garbage.
That's fine if the projects are in a single place (e.g. GitHub) as you only need to create one account.
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.
That's fine, maybe they don't want casual users like you to be part of their community. There is a reason to prefer group coherence over availability. Availability doesn't actually help the group for most online communities, it's actively a hinderance.
It's also a useful signal in the age of LLMs. A bit of hoops to jump through before a PR can now be seen as a good thing.
You don't really need GitHub's 'community'
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.
CodeBerg comes with the advantage that Euro social democrat style moral superiority comes for free. Never mind it has worse performance under less load and its bet for dealing with the future is treating anything LLM related as hostile.
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.
https://tangled.org! Founder/CEO here. We're a new forge building things from the ground up, and are fully federated -- you can host your git repos on your own infra, along with the CI runners. We've also got a pretty neat set of features (if I may say so myself): stacked PRs, Nix-based CI (if you want it), and a fully open protocol (https://atproto.com) to for you and your agents.
Happy to answer any questions.
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.
Arguably the "social coding" angle is the reason why Tangled is the only actual alternative to GitHub. Otherwise there's actually plenty of other alternatives to GitHub, but none of them have GitHub's punchcard, which I'm ashamed to admit is the primary draw for me.
Forgejo, and by extent Codeberg, has the punchcard-like feature, it‘s just hidden under „Public activity“ on the profile page
Don't think anyone uses Github to follow people
I'd like to know if most people use GitHub because of the social network part, or other reasons. I, for one, hate the social network part.
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.
The neat thing about Tangled is you can build your own frontend pretty quickly. We've got an open API https://api.tangled.org (or self-host your own API server: https://docs.tangled.org/bobbin#bobbin)
You're not the target market, there are a number of other forges as seen in this thread as alternatives.
One may want the federation ("I can use all those forges without creating multiple accounts" and "I can open a pull request from my forge into another forge") without wanting the social network angle, right?
Yes, for you there is Radicle.dev then
Radicle is decentralised, not federated...
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.
There's not a big need for federation if it's already decentralized. Either way you can do some research on other options, no one is forcing you to use one or the other.
And you can just use Tangled without the social network aspect. I don't see why you don't want me to use Tangled just because I don't like the social network aspect?!
Why would I care what you use? I just said perhaps @theamk is not the target market if they don't like the social network aspects, and then you replied to me, so I'm not sure why you're on my case specifically. Use what you want.
And my point is that they (or I) may be the target market of Tangled while not being into the social network aspect of it.
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?
You're reading too much into my comment suggesting an alternative. As I said, I don't care what you use and you can take my suggestion or not, I'm not telling or commanding you to use it.
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?
Daniel Holmgren from bluesky is working on permissioned data for ATP [1]. Once that lands tangled will probably add unlimited private repos and extra CI compute on the first party servers as a paid feature.
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.
[1] https://dholms.leaflet.pub/
I recently got a spindle and a knot set up on my home server (along with Tranquil PDS). A few rough edges that we got ironed out but it's cool to have all of that self-hosted on my own machine yet still part of the AT proto world! I'll be honest, I'm not putting anything critical on it yet but that's my lack of trust in my own home server setup not doubt in Tangled's infra!
A better web UI for the queued jobs on my spindle would be great btw!
I am curious, does your server "initiate" the connection to the "federation", or do you have to make it publicly accessible (by opening a port, etc)?
I'm not an AT Proto wizard (there's a lot of good text and video explainers out there) and I know that Tangled is building on it but also adding their own functionality. But from a high level, I register my 'knot' with my account on Tangled.org which is exposed through a public domain. In my case that's routed through a Cloudflare tunnel to a reverse proxy running on my server. Tangled is then running an "app view", which is basically an aggregate of a subset of AT proto activity. So my commits, PRs, releases, etc go into the app view which then points traffic back to my server. So the long and short of it is the app view is the missing piece of the AT proto system and you have to register your data with an app view provider, of which Bluesky is the most prominent. But there are open source app views, in fact the Tangled team just announced one called bobbin that's super resource light.
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.
Tangled feels like the future but it seriously needs private repos ASAP to capture the momentum of the current GitHub exodus.
Just signed up, so not much to report yet, but one thing I noticed is that, because the sign in is on tngl.sh rather than a subdomain of tangled.org, it might be confusing for some users, especially as the sign in page has a very different design, theme and layout to the rest of your website and tangled as a whole. Additionally, my password manager didn't show the just created password due to the URL mismatch. Perhaps this could be addressed to improve the experience.
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.
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.
Yeah I would like to try Tangled if I can set it up in a completely private configuration
I wanted to use tangled but my repo is SHA256 and you sadly don’t support it. I know SHA256 is not very usual but anyway, do you plan to support it?
Yes, it's on the roadmap.
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
I love jj and am a fan of the ideas of AT protocol, so tangled has been on my radar for a while. Last I checked though, it sounded like it was much better suited for open source code, not private repositories. Is that still the case?
We don't yet support private repos, correct. This is very high priority on our roadmap (~6-8wks out).
Is there a way to just browse hosted projects without creating an account? I couldn't find anything
Of course, just head to tangled.org/timeline :)
Are you guys working on jj support?
We already support JJ for stacked PRs, but more native integration is planned.
https://blog.tangled.org/stacking
https://forgejo.org/
I recently set this up on my homelab, not really expecting to switch to it, more out of interest. But wow, after I saw how unbelievably fast it was, I’ve moved everything over. I’ve now set it up to mirror things automatically to Github if I want to make them public.
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.)
Have been running self-hosted forgejo for a while now. Work's like a charm. Easy to use with LLM
Is their CI and CD workflow robust like gitlab/github ?
It's based on act[0] so it's quite like GitHub actions but not completely [1].
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/#...
Agreed. GitHub Actions feels like someone's science project created while on a mushroom trip. Really you just want a thing that executes a shell script in a runner.
It's like they looked at ansible and said needs more yaml templating and less idempotency.
Ask and ye shall receive, https://github.com/defunkt/cijoe
You can use any CI/CD you want. The only reason GH is popular is that it's free for public repos.
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.
> The only reason GH is popular is that it's free for public repos.
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.
For a forgejo host, check codefloe.com if what you need is a place to host personal projects or smaller teams. It’s been rock solid and it is now the default choice for anything outside of work I’ll do.
More than that, it is integrated with Github.
What can you recommend?
I don't have any specific recommendations other than do as little in your CI/CD as possible, instead do as much as possible in your build system or scripts that get called by CI/CD. This way you can migrate with less work or run locally when you want.
This one is really pleasant: https://woodpecker-ci.org/
Isn't forgejo CI based on woodpecker?
Forgejo CI is based on act, which allows running GitHub Actions locally.
However, Codeberg offers hosted Woodpecker CI.
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
Works well and is pretty straightforward.
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...
If you know GitHub actions then you’ll immediately understand Forgejo actions. It was designed that way intentionally. There are some differences, but at least for me not enough to warrant any pitchforks.
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.
A basic API to access Actions logs was added in Forgejo v16. `/api/v1/repos/{owner}/{repo}/actions/jobs/{job_id}/logs`
Nice! I was hoping they would add this in v16. Unfortunately I am still on v15 of all my instances of Forgejo
Thanks to you I’ve now upgraded to v16, and can confirm the logs API works beautifully!
Hooks directly into drone.io using SSO.
Self host both of them on my internal network. Technically old version of gitea which is forgejo pre-fork
Extremely yes
I answered this in another thread, if you're already running a large GitHub organization, GitLab is the closest alternative in terms of features
A big plus is that it also has an open-source Community Edition that you can self-host
There are also many consultancies able to provide professional support with running it in your org, including migrations.
I migrated everything to codeberg several months ago (and created an annual donation schedule). I was never a big fan of github but what ultimately pushed me to ditch it was the way github was shoving copilot/chatgpt in my face without me ever asking. Codeberg has a clear stance on that and it's a stance I can totally get behind.
In addition I spun up forgejo at a server at home for very critical stuff and it's awesome.
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.
> Their own site reports the 2 week uptime at 1 nine
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.
The link you provided has shown a nearly perfect uptime. Your statement doesn't reflect the proof.
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)?
The link provided shows "Uptime (336 hours): 98.76%". That's one nine of uptime for fourteen days.
The reason for switching was shoving all the slop down my throat, even when just browsing. There are a couple of things I have published and a handful of others I plan on open sourcing some day so for the purpose, codeberg does a brilliant job. For work - meh i'm in a corporate environment running internal repositories on company servers so that's less of an issue still.
Note: If you use any form of AI-assisted coding tools, your project breaks Codeberg TOS
> If you use any form of AI-assisted coding tools,
that's not true, only if the project consists mostly of AI generated code
Which is exactly why I started donating!
Perhaps you should stop relying on AI then...
There's a difference between relying on Ai and having any llm generated content in your repos.
?
Codeberg for open source and Forgejo for private (and slop, if you're into that kind of thing) is what winners do
I'm not into that kind of stuff honestly: in my case Forgejo is for stuff I don't feel comfortable with leaving the boundaries of my apartment.
I strongly disagree with the assumption that GitHub's alternative is another centralized forge. Git itself is perfectly decentralized, as was the original Linux kernel development process. How people managed to put all their eggs in one intermittently available service is beyond me. Moving the eggs into another bucket is not a solution (like Microsoft is short of servers). The SPoF is the problem. There are plumbing, porcelain and "github" layers. The "github" part has to be decentralized as well. Then, using a particular forge will be a choice of convenience, not necessity. https://replicated.live/blog/crdt
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.
Why use e-mail? That was 20 years ago. I developed my own local setup that is like GitHub for me and agents, see the link. Everything is a repo, may pull and push tickets, docs, everything. That was not a major effort, unless you count 20 years of experience.
https://replicated.live/blog/crdt
https://replicated.live/blog/link
> 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.
https://tangled.sh
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
Yeah, only open for public repositories until Atproto finishes their permissioned data spec.
You'll have to wait a bit for private repo support unfortunately. Once its ready setting up a knot via Nix or Docker is super easy: https://docs.tangled.org/knot-self-hosting-guide#knot-self-h...
I'm screwed because I am part of an ecosystem that all lives in github.
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've used gitlab and gitea; gitea is faster, and easier to manage and does everything I actually need though, is less feature complete.
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:)
Not who you asked, but I was going to say Actions or CI/CD from when I tried out Gitea a few years ago (back when running a Jenkins instance was more normal) but looks like Gitea supports that kind of workflow now: https://about.gitea.com/products/runner/
Two of the big issues I had were around the user/repository forced structure. That works to some extent when you have multiple users with a small number of repositories. But for my personal projects I wanted more control over the structure and grouping.
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 want org-mode markup support for the wikis and readmes. Github supports this, and gitlab sorta does. You should hook up pandoc to it, and support everything it can handle.
I tried Gitea for a while but the support mechanism was "Beg for help on Discord and hope someone replies", this left us high and dry a few times.
Forgejo is splendid. Codeberg is a hosted instance; depending on what you’re developing it may or may not be a good fit for you. But the Forgejo stack itself is decently light-weight to self-host, very fast to use, and is easy to navigate.
> 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/
if you use ai to program at all you can't use codeberg.
You've made the same exaggerated claim in two comments. Not only are you not banned from Codeberg if you have used LLMs to help you write code "in any of your projects", but you're not even prohibited from using LLMs to help you develop projects that you host on Codeberg.
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 feel like you just directly contradicted yourself so there must be some nuance I am missing. Or is the key word "mostly"? Like I can use LLMs to help the work but still have to type most of the code myself?
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"?
I suspect the fidelity of your comment to your actual level of confusion is low. In any case, if you're really this confused by the information provided earlier, then the chances aren't good that there's anything that anyone could say to get you unconfused.
Right... That's exactly the kind of nonsense that turns people away from ecosystems.
Good luck with that.
The scope of confusion expands unabated.
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.
It's not exaggerated. If you use AI at all for any code in the project it cannot be hosted on codeberg. They made that pretty clear in their blog post.
You can read it yourself - https://blog.codeberg.org/protecting-our-floss-commons-from-...
> If you use AI at all for any code in the project it cannot be hosted on codeberg. They made that pretty clear in their blog post.
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?
See also the codeberg blog post (https://blog.codeberg.org/protecting-our-floss-commons-from-...) which has more informal guidelines. That includes projects that are:
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.
Good point, I forgot they’ve recently banned it. Updated my comment.
Codefloe[1] is another forjego (with some custom patches, I believe) hosted instance.
[1]: https://codefloe.com
Forgejo is great to self host. I have an easy to use template for setting it up on fly.io with backups here: https://forgejo-fly.fly.dev/forgejo-admin/forgejo-fly
I personally host a forgejo instance on a private VPS ; so far almost no maintenance except protecting it from ai-crawlers[#1]. If you don't want the hassle, codeberg.org is a public instance of forgejo.
[#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).
DSCI - http://deadsimpleci.sparrowhub.io
- 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
We switched our entire product studio to a self hosted Forgejo https://forgejo.org/ and honestly this has been one of our best decisions:
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
my favourites are sourcehut (that has excellent ci, and does not try to be a github clone) and codeberg (with slightly more straightforward migration path from github)
[0] sr.ht
[1] codeberg.org
Does sourcehut still require patches via email instead of "pull requests"? That was the deal breaker for me last time I looked at it.
> Does sourcehut still require patches via email
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?"
The specific wording sounded a bit judgy to me as well, but I think it's a totally reasonable question. They're just asking about the capability of a product.
It is prejudiced. If you like sending patches over email more power to you, but there’s a reason 99% of the world’s devs does not follow that workflow.
> but there’s a reason 99% of the world’s devs does not follow that workflow.
Is there?
Email was always designed for human to human messages. Patch files need strict formatting (like anything that needs to be machine readable). That means you need to install extra tools, point them at your mail server, configure the mailing list address and proper formatting for each project, then find the right commit range and type in the description into a command line editor every time you send a patch series. The alternative is doing everything manually and that takes even more effort.
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.
Feels like you make the email workflow sound more complicated than it is on purpose. One could do that with the PR workflow as well.
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.
Come on, there were people using Gerrit instances (which had better PR UI than GH implementation) for good reasons even before GitHub became popular.
I'm a happy paying customer of both, have been for a while. I use SourceHut for private repos, Codeberg for GH mirrors.
I don't want to ignite an argument, but this feels like Linux v Windows. You should absolutely switch because you hate dealing with it, but the less-popular choice is going to be less popular everywhere. Your next job will very, very likely not care about your personal hatred and will simply force you back into the default, popular choice. It is sometimes best to stick with what (mostly) works for everyone unless you want to go down the path of learning another tool.
What is there to learn? It uses Git. What you think it feels like, it is not.
Honestly a lot of the complaints about migration feel to me like the result of poor management of actions etc. If your CI etc is so inextricably tied to github you were never doing it correctly
Self hosted GitLab has been good to me forever and has scaled and has a controllable attack surface as long as you keep on top of it
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)
Creator of GitSocial here: it's a Go binary CLI/TUI that lets you store all your issues, PRs, etc. in the git itself and self-host on any S3-compatible bucket: https://gitsocial.org/.
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!
If you are frustrated with Github being down again, and just want an alternative, the other options listed are better fits. If you have the time to look at doing more than that, then check out fossil https://fossil-scm.org/home/doc/trunk/www/index.wiki
- 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.
I've sorta overlooked Fossil a lot (mostly because it's not git...), but just browsing some instances on chisel and the fossil homepage has me intrigued.
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.
I can entertain you since no one else has so far. I've been using Fossil since 2009.
> 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.
Fossil looks really cool. I like how it's all in one and includes the web interface. The only thing is it doesn't seem like anyone actually uses it outside of sqlite. I don't necessarily need to use the most popular thing out there, but some social proof is nice.
It is a small community. The forums are moderately active though: https://fossil-scm.org/forum/forum
There's also a hosting service for fossil repos which does a really good job for a number of years now https://chiselapp.com/repositories/
Recently:
GitHub has alternatives, but no replacement
https://news.ycombinator.com/item?id=49135365
Why developers are ditching GitHub for Codeberg and self-hosting alternatives
https://news.ycombinator.com/item?id=48842611
For my personal projects I use https://radicle.dev/
Not sure if someone mentioned it already but I also used bitbucket in the past and found it very easy to use with a similar offering as github.
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
Bitbucket was the perfect alternative. I used it back in the day when they were the only ones who offered free private repos. Ahead of their time.
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.
It’s interesting how under the radar Bitbucket is these days.
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.
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
We use it at work and it's fine, but they just removed the issue tracker and forced us over to Jira.
I use Forgejo + Gitea for my home forge, then Tangled for anything I want to share with my own runner.
I self host Lore for my gamedev projects.
I got to know about https://opensats.org/projects/ngit when I worked at OpenSats as a writer for some short three months. Idk much about ngit though, so I can't vouch for it. Yet, some very fascinating nostr-based github stuff. There are others, too, but I can't remember them by name. With some light surfing you can see other implementations.
https://sr.ht
I'm nowadays hosting my projects on rngit (git over Reticulum). But also pushing a mirror to GitHub via a cronjob to increase visibility.
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.
Cursor just launched Origin, a Github alternative:
https://news.ycombinator.com/item?id=49334209
I'm mostly using GitLab right now, both self-hosted and their hosted platform. But am curious about Cursor Origin and certainly plan to try that out when it's available.
A big thing with Github its the unified functionality across most of the OSS world - that we can search across all projects, leverage pipeline actions from other projects, and easily have a single dashboard for our own contributions and interests across all projects.
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?
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.
I was one of the members who was a part of the initial grant for federation in Gitea, but sadly due to illness and other similar neither I nor my teammate were able to work on the grant (so no funding ended up being released), however the work we did start was completed, and we have continued to work on foundations since. Since spam/moderation/limitations are so significant we are focused on that portion first, since we don't want to open up another vector for it without having at least the minimum of protections in place. We have also been extremely fortunate to have experienced developers who do work on existing federated software share so much of their time, expertise, and experiences with us to help shape our work.
That would be good for following, but I'd worry about contributions. Single-sign-on would help but if you're going to ask the user to create a new username+password to log a bug you're not going to get bugs from anybody except your most hardcore users.
Also, unified dashboards/notifications are so useful (even though Github's notification UI is a bit mediocre, imho).
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.
That's the chief differentiator you're giving up when you give up on github vs a self-hosted forge. And the network effect of the CI pipelines should not be discounted since it means actions published anywhere on GH are automatically available for use without any import or install step.
Yes, you could feasibly split off the CI from the git+PR service, but you'd still want it to be federated.
Pipelines are not magic. You want a couple of primitives in there, variable substitution, maybe lite secret management. Depending on the type and languages you work across they could also be 100% unique to each company, language, project, and industry. LLMs have also further made pipeline creation pretty trivial.
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.
Might not be the right move for everyone but I'm very happy to have invested some time and effort to setup my personal Forgejo instance.
I've blogged about it too: https://news.ycombinator.com/item?id=48978707
I moved to gitea + ec2 spot for actions w/ mirroring to GH for the time being.
I self host Forgejo on a cheap VPS with hourly borg backups to rsync.net. It's a great system and seems comparable to github, although I'm not a heavy user of actions on either platform. I do use the container registry though. It was a smooth transition and easy to install. I used the docker installation method. Forgejo is great if you don't mind hosting yourself.
You may consider dsci as its ci is baked in and it uses general programming languages directly as the first class citizens
I've had both self hosted GitHub (enterprise), and GitLab in the last year. It really deoends what you're trying to replace and how you structure the things you're hoping to replace. Also, the value of investing in your separation of concern or safety valve.
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.
I'm building my own - https://git.zserge.com/fierj - and for a few weeks it's hosting itself. Still working on patches workflow and CI, but it's quite usable already. I try to make it "minimally federated" - only threads (issues/discussions etc) are federated via ActivityPub, for PR there is old-school patches workflow, for CI just chroot and a shell script. A lightweight personal git forge in ~4KLOC. Can't say everyone should use it and can't recomment it, but building a personal forge is very realistic. Or you can run cgit as a frontend to your git remote on a server.
Has anyone tried Tencent CNB? It offers generous free quotas.
https://cnb.build
Anything with Tencent on it is a no for me.
Why, would you please share?
For me it's usually a green-flag, since it automatically means they optimized for high-scalability first, as their userbase is gargantuous!
Because China is a terrifying country with no real notion of human rights. Basically all Chinese companies (including Tencent) work closely with the government and do what they want under threat of arrest. There’s no way I’m uploading my data to China where their government can get at it whenever they want.
GitHub Sponsors. It's a nice way to for free and open source developers to earn some money.
Which GitHub alternatives have anything like it?
In my opinion the most underestimated git forge is radicle.
Whatever you do, you should self-host it. Then you aren't going to be at the mercy of some third party when they start to get hammered by vibe coders doing an insane amount of traffic. Forgejo is a great option if you want something git-based. I'm personally very partial to Fossil, it works well and is dead easy to set up.
I’ve been happy self hosting gitea
https://about.gitea.com/
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:)
Awesome
It’s my go to now for all my private projects
My setup is a self hosted GitLab. From there, in most of my repos I setup repo mirroring (basically it just does its own SSH-based git push whenever I push commits to it) to GitHub, GitLab, and Codeberg.
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.
Mostly a toy, but I made https://dumbforge.dev which is intended for hosting public repos without setting up a daemon or forge at all.
The former CEO of GitHub has launched a competitor: https://thenewstack.io/thomas-dohmke-interview-entire/ Anyone using it?
Homepage only has login with GitHub option. Hard to call that a competitor.
Think of that GitHub login as more like a back door.
https://git.cafe if you want a team focused entirely on building a better forge experience rather than a github clone and don't want to deal with hosting yourself (and yes jj support is built in)
radicle.xyz to avoid centralization again
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.
to your actual question, no, it really doesn't make sense. The problem is you are saying it is down consistently.... and it's not. You can switch if you want, but from my observations, it's not really that often, and those that do switch make a bunch of compromises when they do. I'd only consider it once you actually measure the impact to your business. Based on actual data and not feelings, then consider whether it is worth it given all the costs of switching. We use it all the time and at most, may have had 30 minutes where we were stuck.
Anyone tried Entire ? https://entire.io/
some european alternatives : https://european-alternatives.eu/alternative-to/github
I miss something like GitHub but - hosted in the EU - without "FOSS only" limitation like codeberg.
I know I can self-host forgejo but would be nice to have something like forge.eu (even paid!)
SourceHut is actually from Amsterdam, and has both unlisted and private repo visibility.
It's also self hostable, but I'm on the $2 tier and damn is it good.
Each time I end up on SourceHut I'm immediatelly put of… it's probably fine but the UI (for me) is just difficult to work with…
I'm working on self hosting Gitea right now. Hopefully it goes well!
I've been self-hosting Gitea for years, and moved everything I had on GitHub off at the time of the Micro$oft takeover.
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
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:)
https://github.com/facebook/sapling Anyone outside of FB using it?
I have a pretty bad taste in my mouth from GitHub, GitLab, Forgejo, Gitea, etc. They all attempt to hijack Git itself and become a monolith and single custom interface, rather than independent components that work around the Git repo. I want the Unix philosophy applied to Git and other functions. That way I'm not forced to switch the entire kitchen sink out when some single piece of functionality or hoster ends up breaking things.
Sounds like the description of Radicle. :-) https://radicle.dev/guides/protocol#collaborative-objects
That's not really what I'm looking for. Radicle is trying to define specific functionality the system supports: a single protocol which combines multiple separate use cases into one standard.
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.
Hi guys have you looked into gitlawb.com?
Opensource, decentralized and agent friendly I just asked my agent to do a git push in seconds no human involve
Give https://diversion.dev/ a try. You can even have bi-directional sync between GitHub and Diversion while you decide.
Files of any size, centralized, and easy to use.
You might want to consider checking out GitLab and Gitee.
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/
Other way round. Forgejo is a fork of gitea
That's what I said, but indeed in a very bad way :)
No, it's not what you said.
Gitea is a fork of Gogs.
Forgejo is a fork of Gitea.
Codeberg folks forked Gitea to create forgejo.
"Forgejo was created in October 2022 after a for profit company took over the Gitea project. It exists under the umbrella of a non-profit organization, Codeberg e.V. and is developed in the interest of the general public."
https://forgejo.org/compare-to-gitea/
Technically gitee is also a git hosting provider: https://gitee.com/ (scroll to bottom right corner for language switcher).
FWIW Gitea is still community driven as before, there are yearly elections for the community maintainers for TOC leadership.
disclaimer: I'm one of the project leads of Gitea
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.
Why would people outside the US care more or less than people inside?
To people outside the USA, it's becoming harder to justify not treating American services with the same caution we treat Chinese services
Because they say you are assisting china, which they say is seeking to destroy the us
That’s terrible; this shouldn’t be a barrier to using technology.
I've been a Gitlab fan for a long time[0]. I typically default to GitHub for my repo slop[1], but if I'm doing something serious I put it in Gitlab. I like their CI setup better than GitHub and there's also self-host options if any of those "serious" projects ever needs that.
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've used github for ~12 years, and it was fine for single repos, but it sucked _hard_ for any kind of organisation. It also sucked really hard for CI.
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.
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.
I set up Forgejo on my FreeBSD home server the other week, it's been working fantastically. All the features I need, snappy, easy to install.
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.
don’t switch reactively, but use the outages as a trigger to evaluate alternatives and make sure a GitHub outage doesn’t stop critical work.
Branchyard launching soon! https://branchyard.com/ Add your name to the waitlist.
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
Maybe the big cloud’s git solutions? Not to say the are good alternatives, but for teams already on the clouds, they could be a easier migration with somewhat feature complete, uptime, security promises that execs are looking for.
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
For SaaS forges there's also upd.dev launched recently.
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?
AWS CodeCommit + CodeBuild. All day long.
Try https://gitgrasp.com/ for an open protocol approach that can't be shut down and uses normal HTTP git servers.
We're moving over to self-hosted forgejo. Interface is roughly similar, featureset is roughly similar enough.
https://cursor.com/origin
how has nobody mentioned https://codeberg.org ?
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.
All of that is good except if you also have a lot of private repos at GH, you cannot move them to Codeberg.
Like others I migrated from github to codeberg. But since lots of my projects are coauthored with Claude I moved to self hosting Forgejo on a small Hetzner instance which also does some static hosting. So far working well. I think some cross platforms stars and search would be good.
I moved recently to Gitoro with private projects, but do not have any meaningful opinion about it yet. It works for me, it’s fast, nothing to complain about. Just mentioning it here as EU-hosted alternative.
https://gitoro.com/
From when MS bought GitHub: https://github.com/ianchanning/awesome-github-alternatives
I've used GOGS for years (Go Git Service). https://gogs.io/getting-started/introduction
As a whole? None.
If you only need git hosting, do whatever wherever you want.
Cursor released Origin, its git repository , full integrated with AI patterns.
I just asked AI to write one for me and self-hosted it.
if you want to work on personal projects and store personal data, use gitLab; if you’re working on open-source projects, use codeberg. codeberg is a nonprofit organization dedicated to open source, so their storage policies are quite strict. gitLab offers 10gb of storage with no restrictions, and their data policies are much better than gitgub’s if you want full control and to deploy on your own, consider forgejo for an experience similar to github actions. If you’re used to gitlab’s pipelines, set up your own private gitlab instance
forgejo for hosting, woodpecker for CI/CD.
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/
this is our stack too, we initially ran BuildKite but switched to Woodpecker for Forgeo. Coming from Github there's a few basic things that are missing in woodpekcer that may frustrate you but it's improving regularly.
Try self-hosting Gitea with push mirror to GitLab or GitHub. Gitea is powerful and lightweight, and a push-mirror to another service is a plus as a backup location.
Try Fossil https://fossil-scm.org/home/doc/trunk/www/index.wiki
I have been hosting gitea for our small org (docker + sqlite) for close to 5 years now. ~50+ repos, some large. All upgrades, including major changes, have been as easy as just changing the tag and reloading the container.
We have self-hosted GitLab running for https://omniline.app/
If you want to try something a little bit more off the beaten path, https://gitworkshop.dev/ is a code forge built on nostr
oh, thats an awesome idea!
I am self-hosting with Gitea. Have action runners set up on my Windows PC and Mac (with a container for Linux). Works great.
What are people using as alternatives for GitHub Actions specifically these days?
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
Looks neat! I'll try your project if you try mine: https://getprobed.chat/
Thanks! Yours looks good too! What would you say is the difference with Slack connect? I find slack connect to be pretty painful once you have n > 50 channels
A big difference between Probed and Slack Connect is being able to create public community channels where all your users can talk to each other. You also get a feedback system, a public roadmap, and other features to help foster that community-driven growth.
Classic CI vendors like Semaphore, Circle, etc are options.
I feel like something is missing from your list of "classic CI vendors" but can't exactly jput my jfinger on jit.
I think of Jenkins as a project, not a vendor. (if you're looking for alternatives to Github, I'd assume it being a managed solution is a requirement)
Yet half of the recommendations here are self-hosted this and self-hosted that.
are we referring to jenkins here perhaps?
I loved the simplicity of Amazon CodeCommit. Unfortunately, Amazon decided to deprecate it, no new provisionion but existing accounts could remain. I'd love it if someone else offered a similar product.
https://repo.autonoma.ca/treetrek
I self-host using my own read-only, FOSS, pure PHP Git repository reader for personal projects.
I moved to Codeberg months ago in response to GitHub's unreliability, poor moderation and random/illegitimate takedowns, and overuse of AI.
Have never regretted the switch + I love the no AI policy.
If only there was a convention for storing PRs and issues and wiki inside the repository itself, similar to how Fossil[1] does it.
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.
[1] https://fossil-scm.org/home/doc/trunk/www/index.wiki
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 love Fossil, I have been using it for all of my projects for the last couple years. Things that I love include:
The biggest friction is managing users across repos. Each repo is its own RBAC, the "zhynn" user in one repo is not the same as the "zhynn" user in another repo. It would be cool to be able to sync users across repos, which should be possible with sql, but I think that it could get weird with repo-specific permissions. Currently I just add my user to each new repo, granting that user setup permissions, and removing the admin before I scp the .fossil file up to the webserver.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.
Those two pipe dreams sound really cool! Do you have a website or something to lurk you via if you eventuality get around to those? I find it difficult to keep up, as it were, using form histories and other social media platforms.
The workflow is paradigmically different, and that may throw many people off.
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.
Yep, it’s not for everyone, and their docs are pretty clear about that. OTOH those same docs contain a variety of arguments that git isn’t really designed for everyone either and that fossil might be a better fit for projects that have just one or a handful of developers, which AFAIK is the vast majority of projects on Github. My experience is that it is certainly an adjustment but the docs are good at explaining (and justifying) the differences, and the built-in features are very useful, especially for anyone looking to reduce their dependence on a centralized host that’s become unreliable.
Epiq also solves this with a git-native backend, so it is vendor agnostic and adheres to a issue-tracking-as-code paradigm. It is therefore distributed, has a TUI + browser GUI, mcp server, and so on.
https://ljtn.github.io/epiq/
It is also event sourced, and supports state replay from beginning to end, so very powerful for auditing workflows, whether that be your own or a swarm of agents.
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
FWIW, I have a new and much better webui that I need to release. I'm also planning to work on PRs and other stuff around the end of the year.
My org self hosts the community version of gitlab and we are perfectly happy with it. Manage your own infrastructure, put the work into maintaining it and you'll have much fewer headaches.
I'd like a self-hosted primary option as the source code repository, but I'd like to mirror the code in one of the usual external options, anyone done anything like that?
I want to know what the best guide is for running your code repo at homelab type of setup? proxmox? what hardware to buy?
i dont wanna get too crazy i just dont trust github with my code anymore
Try dsci / it’s super simple
Ironically hosted on Github Gogs is a self-hosted forge : https://github.com/gogs/gogs
For CI/CD woodpecker has been working for us really well https://woodpecker-ci.org/
I'm running gitea successfully with very little resources.
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:)
You've built a great piece of software, thank you!
Hi!
(Full disclosure: I am the author of rocketgit project.)
Check https://rocketgit.com
It is AGPLv3.
I self host Gitea and have been supremely happy with it.
Forgejo/Gitea is lightweight and easy to setup.
Codeberg seems like a good alternative and is already hosting loads of awesome stuff.
If an org is heavily invested in GitHub Actions and GitHub App integrations, is self-hosting GitHub enterprise the only practical option?
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
Buildkite has built a GitHub Actions adapter... a good first step out of the GitHub Actions supply chain attack trap.
You could ask a quote from consultants on how much it would cost to migrate them... For large corporations it will probably be millions of euros.
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
I'm one of the project leads of Gitea and we've put a ton of work into Gitea Actions, I'd be interested in any compatibility gaps that you've run into.
oh hello, thank you for your work on an excellent product! one small difference i ran into last weekend is that foregjo forwards the FORGEJO_TOKEN in the environment to composite actions so that they don't need to have a required "token" input.
mind trying https://github.com/preloopdev/preloop? We follow the official runner protocol 100% so we should hopefully have more workflow-compat.we also run in cross-platform microvms, not docker containers.
My org uses a self-hosted instance of RhodeCode Enterprise. It's not as feature rich as GitHub, but it's worked well for us.
I’m building a non-git alternative
https://oak.space
Would love for anyone to check it out!
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
We've added some things like CI, Windows support, and starting some work on path-based permissioning for monorepos. These are still in the early stages so not documented that great yet and need to be tested a little bit more. Should have more updates in the next couple weeks.
Can recommend https://codefloe.com
dunno how it works but Cursor just released its own alternative Origin and looks pretty good integrated to build agents and ship them quickly using one ecosystem, so will be worth it give it a chance
use codeberg if you're ok with never using ai in any of your projects. Any AI use and your repo is banned. - https://blog.codeberg.org/protecting-our-floss-commons-from-...
Mostly of recommendations only have linux runners, I need windows and macOS.
Any recommendations?
GitHub is like World of Warcraft, in that you can’t kill it with another GitHub.
forgejo, self hosted. Dead simple to host, even have it integrated with my pocket id so it’s one less password I have to remember.
for local Canadian based workflows that want sovereignty, I recommend https://about.worktree.ca
Note, currently worktree is just wrapping OVH as their “sovereign cloud”: https://docs.worktree.ca/sovereignty/
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.
Also they are using a home baked S3 compatible storage system and longhorn for block storage: https://docs.worktree.ca/updates/post-mortems/2026-07-20
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.
I'll second Worktree. I'm US based and have been using it for over a year. Very, very happy with their service.
Disappointed https://aboot.worktree.ca/ doesn’t work.
What part of github that's so sticky?
For me it's action and PR history.
What about a mailing list and `git format-patch`?
i don't think so. lots of cloud-providers still support github. atleast in my case i can't switch
cursor are launching a new one soon - https://cursor.com/origin
We already have a vibe-coded forge, it's called GitHub
This one is not managed by Microsoft.
edit: I'll take their engineering culture over MS.
This one is managed by SpaceX now.
What "culture"? I've seen Cursor's AI-coded web browser... which was released with parade despite not even compiling and being just millions of lines of glue code over external libraries actually doing the real work.
Elon won't be having my code
I guess we need a simpler alterntive to github
My org's GitHub Enterprise never goes down. The feature set is almost the same, though it lags a few months behind. At least you don't have to learn anything new.
I'm assuming you mean Enterprise Server (non-cloud), because my GitHub Enterprise Cloud is down right now.
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
Try Gitlab, Bitbucket, or Codeberg.
selfhosting gitea has been a great experience for me, its open source
It is time to switch to self-hostable alternatives.
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].
[0] https://news.ycombinator.com/item?id=22868406
[1] https://cursor.com/origin
Origin by Cursor probably will be future Software.
GitTorrent
If you accept a non-Git VCS, Pijul Nest.
Old skool is best skool... There is wisdom in keeping these decoupled:
- 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.
1. Code review (and hosting): Keep this in-house always.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...
I strongly prefer to keep it all in-house. Proprietary software is oil - capital. Own it fully, no exceptions. This was true "back then", and it has become even more business-critical now, for obvious reasons.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
(edit: fix formatting, typos)Not really. Is it stopping your work?
Curious to hear: does GitHub not have any switching costs to leave? Or is it the broader Microsoft ecosystem? Or a mix of both?
GitHub Actions, GitHub Auth, any hard coded GitHub URLs you use, GitHub's nice REST API.
They do have a bunch of value adds, it just depends on which you use
gitea/forgejo both do an 80% job of covering these needs, ime. they have mostly-GH-compatible APIs.
are you a paying customer?
right so basically moving upmarket, upselling around a core idea.
i use it quite often and it has not really been 'consistently down'
I wonder how hard it would be to vibe code a super basic gitea/gitlab clone (or a very stripped down version) that's designed to just have basic authentication w/ssh, some basic main branch protections, simple code review, etc... and runners with some simple YAML language.
I bet you could do it with like 10 prompts.