Lots of posts on youtube recently about using Gitea as a home lab git repository system. I got interested in looking at that further as it supposedly has very low resource requirements. It may not be a ‘new kid’ as it has probably been around a while without me hearing about it until videos about it started trending on youtube.
I am looking at this from the point of view of trying to find a solution with minimal resource requirements, as in a home lab every Gb of memory saved could be another VM started to test something in.
Most of those videos on gitea are about running it in a docker container environment; where it will magically install itself and create the mysql database container and docker volumes needed as part of the docker compose. It seems relatively simple to use that way. But that seems a bit resource intensive as well.
I found a much simpler way, the project also provides standalone binaries which are very tiny (compared to docker images) and even easier to setup. While you can if you want use external databases such as mariadb or postgesql for a home lab it is much simpler to simply use the sqlite3 database it supports embedded.
So a quick summary would be that for home lab use, or anywhere with very few users, where you do not need an external high performance database, Gitea uses very few resources and works well.
What I was using – gitlab-ce
What I have been using until now was the gitlab-ce docker image, which while working well had the following issues
- Needed a VM with 6Gb memory assigned, and if left running for a while at one point used 2Gb swap before I restarted the container
- takes quite a few minutes for the container to start up and become ‘healthy’, sometimes needs a bounce to get it there
- Has to be updated frequently, and as the image is huge if you miss few updates and have to incrementally apply them by pulling one image version at a time, running it, getting the next version etc. it can take a while
- while most updates work ok, I have had to for a few of them delete everything and recreate from scratch
[root@gitlab gitea]# docker image list REPOSITORY TAG IMAGE ID CREATED SIZE gitlab/gitlab-ce latest e71188eb2659 3 weeks ago 3.63GB gitlab/gitlab-ce old 3f416ff94400 7 weeks ago 3.71GB
And Gitea on the same VM
Remembering that I am not comparing apples to apples here, I am using the standalone binary rather than a docker container for Gitea. The docker implementation will also use a database in the container and a docker volume which are not needed for the standalone binary, the binary can use an external database but I chose not to as that is overkill for a small implementation so I use the inbuilt sqlite3 one.
- in the same VM with 6Gb memory assigned… top showed 4Gb available memory, so I have resized the VM down 2Gb and no issues (leaving 2Gb headroom for other containers I start as needed in that VM)
- starts up in seconds
- comapared to docker image sizes the binary is tiny
[root@gitlab gitea]# ls -la bin total 110528 drwxr-xr-x. 2 gitea gitea 4096 Jun 17 17:08 . drwx------. 7 gitea gitea 4096 Jun 17 18:17 .. lrwxrwxrwx. 1 gitea gitea 24 Jun 17 17:08 gitea -> gitea-1.24.0-linux-amd64 -rwxr-xr-x. 1 gitea gitea 113168376 Jun 17 17:04 gitea-1.24.0-linux-amd64 [root@gitlab gitea]#
How I installed and configured it
The basic instructions for obtaining and using the Gitea binary are at https://docs.gitea.com/installation/install-from-binary at time of writing this. The major differences between the instructions and what I did were to put everything under the gitea user directory
- The user I created was gitea, with a home directory of /home/gitea
- where there are instructions to created the needed filesystem structure I removed the leading / and created everything under the /home/gitea directory (so for me GITEA_WORK_DIR=/var/lib/gitea/ becomes GITEA_WORK_DIR=/home/gitea/var/lib/gitea/ for example)
- I also created a /home/gitea/bin directory to put the binary file in. It is recomended that the binary be called “gitea” to save complications when upgrading; as you can see above I just used a link so upgrades (yet to be attempted) just need changing the link to the new binary
- and of course all references to /etc/gitea/app.ini I changed to /home/gitea/etc/gitea/app.ini in the command line for testing and in the service file when I was happy with it
Once you are ready to start it, just run the binary (with the updated config file of course) and point a web browser at port 3000 to get the initial config screen. On the config screen…
- I selected sqlite3 in the dropdown as the database to use (no need for external databases to chew up resources); it creates the sqlite database under the /home/gitea/var… structure I used
Helpful tip
If you do not already use it investigate the use of a .ssh/config file :-) where for a hostname you can configure the remote port and local private key identity file to use for the hostname; so for in my examples here I can “git push” to origion “gitea-local” and ssh to “gitea-server” (no entry so uses default port 22) without needing to remember what keys or ports to use (and I would say still document them but that is what the config file does); just remember to have a default with nothing at the end.
Host gitea-local IdentityFile ~/.ssh/id_ed25519_local_gitlab Port 5522 Host github.com IdentityFile ~/.ssh/id_ed25519_github_20250506 Port 22 User git Host router KexAlgorithms +diffie-hellman-group1-sha1 Ciphers +aes128-cbc Host *
The only real issue I had was even though I had set SSH to port to 5522 in the initial configuration screen by default the SSH server did not start, you have to manually add to the app.ini file in the [server] section “START_SSH_SERVER = true” for it to start. After that it worked perfectly well.
The other minor issue was just annoying, it was logging a lot of messages for /metrics URL not found, which it kept doing even after I added the below to the app.ini file.
[metrics] ENABLED = false ENABLED_ISSUE_BY_LABEL = false ENABLED_ISSUE_BY_REPOSITORY = false
however they were informational, and as I want this to be lightweight and not fill up my filesystem I changed the app.ini log section from Info to warn, additionally from console to file. The messages tend to imply the docker images also include prometheus to collect stats from /metrics, I do not need stats so have not looked further into that (for this post anyway).
After it was running I just created new repos in Gitea to match what I had been using in gitlab-ce, and in the filesystem of my dev machine ‘git remote remove origion” and used the “git add remote origion…” command shown when the repo was created (almost the same, I removed the port number, as noted I use .ssh/config to select ports and keys to use as I just have so many of them) to change where they pointed and did an initial push; and it just worked.
What I have not tested
I have not had to upgrade the gitea binary to a new relase as of course I used the latest; so that procedure is untested. And of course I have no idea if I will eventually hit a limit on the size of the sqlite database, although as this has been so simple to setup just fire up a second copy.
Some of the videos on youtube discuss actions and runners, where in the docker solution another container can be started as a ‘runner’ of a specific OS/distro when things change to do stuff. I have not looked at any of that stuff yet so do not know if it requires a docker environment; not high on my priority list as I never used those functions in gitlab-ce anyway as I have Jenkins but the functions may be useful as a replacement if available in the binary Gitea (there are tabs/selectios to set them up, I just have not looked into what those do yet).
Summary
Gitea, the binary install anyway, is very low on resource needs and starts/restarts in seconds. Any upgraded needed will not take GBs of data to download which is another big win. If you want to host your own local git repository this is ideal.
Why you might want to host your own repository ?. You of course all use git for anything important in your local filesystems to manage changes, and I do test my backup/restores often, but being able to push changes to a local git repository (on a seperate machine of course) is another good backup for that important stuff.
I do have stuff on github, but having a local repository allows for lots of test branches that I may never want to push there, and a lot of ‘site only’ stuff it would be pointless to put there that still needs to be managed so for me a local repository is needed. You may never have a need for one… but this was so simple/easy to setup you probably should.
