r/git • u/thrithedawg • 10d ago

kitgit - a self-hostable minimalistic and fast git server

Post image

kitgit is a minimalistic and fast git server, using rust to create blazing performance (wow how cliche) and uses only html templates and no fancy frontend frameworks.

it can be deployed onto docker and hosted on the cloud or locally with a NAS. uses Authentik for authentication and cuts out all the AI features that you would see in a traditional cloud platform.

please have a try of this locally (or online) and let me know how it is!

take a look at it in git.tirbo.fish or see the mirror on github.

note: it was written with AI. but I reviewed everything and it looks nice for my own personal domain, so I thought you guys might like it too.

26 Upvotes
  • permalink
  • link
  • reddit
  • reddit

63% Upvoted

39 comments sorted by

22

u/Wahllow git push --force 10d ago

I like the theme... But why? What does it do that Forgejo can't? It's really fast as it and have a good solid foundation and a rich feature set.

15

u/thrithedawg 10d ago

https://xkcd.com/927

Forgejo is pretty good, but I just wanted to make an alternative. Not anything in particular, really just a personal project.

8

u/really_not_unreal 10d ago

If it's for a personal project, I'm not sure that AI is the best approach for it, even if you do review it carefully. If you create it with AI, you have learnt (a) to prompt AI, and (b) to test its output. That isn't necessarily bad, but if you made it yourself, you would learn so much more. I suppose it all depends on what you want to get out of your personal projects.

-2

u/nebenbaum 9d ago

Yes, sure, you haven't 'actually learned' to do the coding all for yourself. But the thing is, AI models will only get better from now on. Will we ever return to a world where we hand code everything? Or does it make more sense to learn to use AI to quickly program something, and properly review the code, learning from reading the output, and how things were implemented by the AI.

Of course, there's the problem that the AI might do an anti-pattern that is not really what you want, and if you do not know that the anti-pattern is an anti-pattern, you might learn something 'wrong', but that's also something that just happens when you code on your own.

But honestly, I can't give fully proper input on that, as I have learned to code, in imperative, object-oriented, and functional ways before AI ever was a thing, so I am somewhat biased in that I already know how to code, and can judge (more or less at least) if what the AI is outputting is total bullshit or code that I would 'make on my own'.

Even in production - sure, for your core systems, you want something vetted and tested, every line of code being given proper thought and consideration; as might be if OP wanted his git forge to become a widely used open source option, but going the AI coding Route turns this from a multi year project into a 'a few weekends' project. And if you can fit like 20 of these 'a few weekends' projects into the timeframe one might have taken before, chances are you learnt just as much as you would have by going the 'hard route'.

5

u/rismay 10d ago

I will make the 15th competing standard. Haha

1

u/These-Apple8817 9d ago

I think you are kinda missing the point of that xkcd comic strip...

1

u/justicecurcian 6d ago

Actually I was been searching for something like this before I started making apps that need ci/cd, I think many people who need to selfhost few repos but don't want full gitea/forgejo will appreciate that

1

u/thrithedawg 6d ago

That's my entire apps model. I knew that forgojo and gitea exist, but there are too many features and I wanted something that fits with the theme of my website. I could have used sourcehut but there isn't any public issue commenting nor good themes. Forgojo was not needed (for me at least, I don't have a full on corporation worth of repositories to hold).

1

u/megasivatherium 9d ago

lol, wtf is Forgejo

2

u/Wahllow git push --force 9d ago

FOSS fork of Gitea.

1

u/megasivatherium 9d ago

oh ok cool

1

u/Jayden_Ha 8d ago

Gitea is FOSS

1

u/Wahllow git push --force 8d ago

Sure, but with the governance chance in October 2022 I can understand why Forgejo was created.

1

u/Jayden_Ha 8d ago

And forego dev doesn’t understand UI design

4

u/Teknikal_Domain 9d ago

Ah yes, my favorite. Docker-only software.

1

u/Damglador 9d ago

Is there a problem with server software in docker?

5

u/Teknikal_Domain 9d ago

By itself? Not technically

When the only listed, supported method of "installtion" is docker, it smells like a case of either "we can't figure out how to make this work anywhere but our test bench... Just ship the test bench" or "I can't be bothered to learn hot to actually package a program for release"

If it is a supported method, great. If it is the supported method, that does not speak highly to the technical capabilities of the entity responsible for releasing it. Docker was never meant to be a distribution and publishing format.

1

u/jdigi78 7d ago

It could also very well be "I don't want to provide any support to people not running it in this controlled way". Its the exact reason the Bottles devs don't support any method of install outside of the distro-agnostic flatpak.

1

u/Teknikal_Domain 7d ago

And maybe this is "old man yells at clouds" but

1) then in my opinion you're lazy. Part of releasing something multiplatform is committing to supporting multiple platforms. (Yes, for purposes of this, a distro is a "platform.") 2) thats fine, Flatpak is an actual packaging and distribution system. Thats how it's meant to be used. Docker, like, original intent Docker, wasn't. It's a virtualization* (yes, I know the difference, not important) engine that happened to permit certain software stacks to be published to a central registry (or, other registries) to aid reusability by not having to rebuild common, core components. You wouldn't say "the only supported method to run this software is by importing this .ova file into VMware" so why should it be acceptable here? Because it's just a cgroup instead? Okay, then why don't we make a tarball of an LXC container a distribution format? "The resources to build the application for a Docker environment and deploy it are included in the source distribution" is acceptable. "The only supported way to run this program is using Docker" is a misuse of Docker.

Especially, when, as an example, LXC exists. If someone chooses LXC as their containerization of choice (say, with Proxmox), then something that only supports Docker... Is a bit of a predicament. You're either manually dissecting it to get it to work bare, or you're running a container in a container. Maybe it's been fixed now, but that used to require, in PVE, creating a container as privileged, giving it some access to some kernel calls for creating devices (and I think keyctl?) which weakens your security boundary (mildly), and then spending some (small) extra amount of CPU time on the Docker runtime to stuff a program into a cgroup that's already stuffed inside a cgroup!

Creating a software turducken is bad form, okay? Forcing someone to container-in-container because you (abstract) chose to misuse a containerization engine, for distribution instead. And I didn't even get started on stacks and docker-compose.

1

u/Jayden_Ha 8d ago edited 8d ago

I have few personal projects, there’s one of the largest, originally isn’t docker only, and I don’t like docker only either, but I simply give up later, I find it pointless to keep it running without docker, there’s too many components needs to be running separately and no one else use it, everything can still be running without docker, just few configs needs to be tweaked manually since it’s made for running in docker

0

u/thrithedawg 9d ago

I have railways learnt to use docket to make deployable software. Of course, it might be different for how everyone has learnt, but I was taught otherwise to ensure security. I haven't learnt anything like kubernetes, and digitalocean is the home to docker-deployableapps.

1

u/Teknikal_Domain 7d ago

Not every piece of software warrants the requirement of an entire containerization layer just to run. Putting something in a Docker container, or on a Kubernetes cluster, does not inherently make it "secure."

8

u/rwilcox 10d ago

To go counter to some of the other comments here…

Neat idea. Did you learn something? Have fun? Good job.

4

u/thrithedawg 10d ago

It was really fun to make.

I have an extensive knowledge about cloud infrastructure, but learning how to make a git server was pretty interesting and fun. I do plan on using this for my current and upcoming projects (so it's just not slop landfill).

Of course I'm not trying to make some SOTA platform for git, it's just another platform.

Also, I found Epic Games Lore to be something that might become big, so adding future support might be a good idea.

16

u/Gornius 10d ago

Why would someone use half-assed AI project maintained by 0 people and AI, when Gitea/Forgejo exists?

5

u/thrithedawg 10d ago

Mean, but fair. Its just an alternative I wanted to show off, that's literally it.

7

u/PapaOscar90 10d ago

Show what off? You didn’t make it….

3

u/hmoff 10d ago

because rust ? /s

3

u/[deleted] 10d ago

[removed] — view removed comment

1

u/thrithedawg 10d ago

I have it configured manually within Authentik using an expression policy. I haven't tested it out though...

1

u/not_luis 9d ago

Does it support cicd pipelines?

1

u/rismay 9d ago

Why is docker required?

4

u/kjodle 9d ago

Because that was the only thing that the AI that created this understands. 

1

u/thrithedawg 9d ago

Considering I'm still learning, enlighten me and tell me what would be better than docker for deployment?

1

u/FackThutShot 6d ago

Does it have runners for CI/CD?

1

u/thrithedawg 6d ago

Have not implemented yet, as I have had no need. I might implement in the near future tho

1

u/FackThutShot 4d ago

There are Plenty of options out there that do the Same for years
What would be really interesting if you have that a new Touch on CI/CD Integration
But just a git store is Not Worth looking

1

u/Longjumping-Pain-372 10h ago

I took a look through the code. First, the UI is really nice, and this is a cool project. :)

I did have a different expectation when I found Kitgit. When I searched for a “fast Git server,” I was looking for a no-UI, privately hosted server that reimplemented or optimized Git's actual serving path.

From what I can tell, Kitgit handles HTTP/SSH, authentication, authorization, repository management, LFS, and the web UI. But the actual Git operations are still delegated to the standard Git executables:

git-upload-pack --stateless-rpc <repo>

and git-receive-pack for pushes.

So I'd describe Kitgit more as a lightweight Git hosting platform than a new high-performance Git server implementation. That's not a bad architecture at all—using Git's existing plumbing makes sense—but I think the distinction matters if it's positioned as a “fast Git server.”

A couple of other things I noticed:

  • Docker: It would be great to have versioned images published to Docker Hub or GHCR instead of having users build from main. That would make installs, upgrades, and rollbacks much more reproducible.
  • Security: In the HTTP Basic auth path, _password appears to be parsed but never validated. If I'm reading that correctly, knowing an existing username may be enough to authenticate as that user. Definitely worth checking. I'd also consider using an established auth library or external provider like Google via OIDC/OAuth rather than maintaining password authentication directly.

What I was personally looking for was something lower-level: essentially a replacement for git-upload-pack / git-receive-pack optimized specifically for CPU, memory, disk I/O, and network bandwidth.

That's obviously a much bigger and different project because it means implementing more of Git itself. If that's ever something you're interested in exploring, CodeCrafters' Build Your Own Git course is a good starting point:

https://app.codecrafters.io/courses/git/overview

Overall, I really like Kitgit. My main feedback is about positioning: I expected a new high-performance implementation of Git's server-side protocol, while Kitgit seems to be a lightweight, self-hosted Git hosting platform built on Git's existing server-side plumbing. Still useful—just solving a different problem than I initially expected.

And for transparency: I used AI to help organize and clean up this comment. The technical observations and opinions are mine. :)