Selfhost your own gitea instance - selfhosted, lightweight github alternative
I've recently set up my own Gitea instance and I figured I'd share a simple guide on how to do it yourself. Hopefully this will be helpful to anyone looking to get started.
If you have any feedback please feel free to comment it bellow.
https://4rkal.com/posts/gitea/Open linkView original on lemmy.world160
Comments31
I'll be that guy: Use forgejo instead, its main contributor is a Non-Profit compared to Gitea's For-Profit owners
Silly question but what is the problem with gitea being for profit?
I guess out of fear that we get another gitlab situation, where the open source offering has a load of key features eventually kept behind a paywall
At some point they will do a Redis or Terraform and say no more open source, pay us to use it.
All contributions are now owned by us and not by the person who wrote it.
As the other commenter already said it's an abundance of caution. GItea is already moving in the direction of SaaS and an easily self-hostable solution runs counter to that plan (Gitea is already offering a managed Cloud so this is not a hypothetical). One thing that has already happened is Gitea introducing a Contributor License Agreement, effectively allowing them to change the license of the code at any time.
Thanks, I always keep forgetting what this ones called. I use a build of gitea from before it became shit but I keep telling myself I need to change to "that better one".
If it helps, it's supposed to be a drop-in replacement.
It's a hard fork by now, but the switch should still be pretty painless.
Well I learned something new today.. maybe its time to plan a migration
I think for now Forgejo is a drop-in replacement. However since they are a hard-fork, at some point in the future they will diverge enough to be mutually incompatible, so the clock is ticking on migrating.
From what I have read on the FAQ they already did a hard fork from Gitea version 1.21.11 on, which was earlier this year
https://forgejo.org/faq/#im-sold-are-migrations-from-gitea-to-forgejo-possible
There's been a hostile takeover at Gitea and it's now run / owned by a for-profit company. The developers forked the project under the name Forgejo and are continuing the work under a non-profit. See also: Their introduction post and a page comparing the two projects. Feel free to look up more, since I haven't familiarized myself with the incident all that much myself. Either way though, maybe consider using Forgejo instead of Gitea.
Hostile not quite, as it was a group of core developers. But still a shitty move, especially how it was done in secrecy and disregarding other devs and the larger community.
Perhaps not a takeover so much as a betrayal, a backstabbing? Certainly hostile to the community.
Could you please provide some sources for that? I'd like to know more.
First of all though, there is no such thing as a "hostile fork". Being able to fork a project, for any reason, is the entire point of open source. And to be fair, not wanting to continue working for a for-profit company for free is a very good reason.
And yeah, when you suddenly turn a FOSS project that's been developed with the help of a bunch of contributors, into a for-profit company, without making a big fuss about it beforehand and allow the contributors and community to weigh in, then yeah, that's a hostile takeover of sorts, at least in my opinion. Developers gotta make money, but they could've done that by creating a new brand instead of taking over that of a previously completely FOSS project. Forgejo is preventing that exact thing from happening by joining Codeberg (a non-profit).
Try its fork forgejo instead.
Why?
In 2022, maintainers (...) founded the company Gitea Limited with the goal of offering hosting services using (proprietary) versions of Gitea. (...). The shift away from a community ownership model received some resistance from some contributors, which led to the formation of a software fork called Forgejo. From Wikipedia.
But check that it has all the features you need because it lags behind gitea in some aspects (like ci).
It's also ahead of gitea in some aspects: https://forgejo.org/faq/#is-there-a-roadmap-for-forgejo
Doesn't matter if those features are doomed to be locked behind a paywall shortly
Great question
I always found setting up a git server from scratch to be quite confusing and I also like the webui that gitea offers.
But recently I have also started moving some of my github projects there so having a link (with a readme and everything) that I can share with others is important.
No, but it is amazing for browsing your repos and visually seeing what you did in a past commit or a branch, while your IDE is open to your latest code. Or copying and pasting something that you need from a different repo.
For Git experts, sure they can probably do all that better inside their IDE or CLI, but for us plebs, having your own Forgejo is incredible 😍
I have mine configured to disable the wiki and issues, etc, it's just the repo browser.
I'm hoping federation will allow me to get rid of my github entirely, but that's wishful thinking I fear
I intentionally do not host my own git repos mostly because I need them to be available when my environment is having problems.
I make use of local runners for CI/CD though which is nice but git is one of the few things I need to not have to worry about.
Sidenote: If you just want a nice web frontend for others to view your Git repositories, you can use cgit instead.
cool guide love stuff like this
Fossil https://fossil-scm.org/home/doc/trunk/www/server/
I spent a decade as a full time Tcl developer and even I don’t use fossil.
After dealing with tcl errors trying to test sqlite, I feel I've never seen a more scathing criticism of fossil.
I love love love that Fossil is a single executable.
All in all, the version control wars have ended and git has won. Mercurial is another one I sort of wanna try just to see what it's like.
Re: rebasing, I think squashing / rebasing (in place of merging) is bad but I am also one of the few people I know who tries to make a good history with good commit messages prior to opening a pull request by using interactive rebasing. (This topic is confusing to talk about because I have to say "I don't rebase, instead o rebase" which can be confusing.)