Gitea vs GitLab: Which one for Home Lab?

If you are looking for a self-hosted git solution that will allow you to host your own git repositories, there are probably two solutions that you will see come up on every Reddit thread and blog post that you land on, including this one, Gitea, and GitLab. However, hopefully, I am going to fill in some blanks and questions you may wonder about between using Gitea vs GitLab.

What is Gitea?

Gitea, is a relative newcomer I would say in a manner of speaking in the git space as it has gained traction since around 2020 or so or that is when I started hearing about it and seeing creators start talking about it. It is a super lightweight solution that is all about performance, and it looks basically like GitHub, except hosted locally. Learn more about Gitea here: Gitea.

What is GitLab?

GitLab is the cadillac solution out there that will do just about anything you need it to do when it comes to hosting git repos. With GitLab, you get code repositories, and built-in CI/CD pipeline functionality. You also have the ability to have a self-hosted image repository using GitLab. So, it is like a Swiss Army Knife when it comes to git repos and DevOps. Learn more about GitLab here: GitLab.

Comparing Gitea vs GitLab

Let’s look at the following areas of comparison between Gitea and GitLab and see which one comes out on top in my opinion in each.

1. Installation
2. Performance
3. CI/CD capabilities
4. Integrations
5. Scheduling pipelines

1. Installation

The installation of both solutions can be done with Docker Compose code where you can bring up your needed containers for each solution. I will say this, the GitLab Omnibus installation (contains all of the solutions needed in a single contianer) makes the process for GitLab easier than it would be than if you would have to stand up each individual solution and tie them together.

GitLab is a beast. It has many different components, including PostgreSQL, Redis, Gitaly, and others contained in the single Omnibus container. Tuning the solution, which I will cover under the Performance section, is where you will definitely run into complexity when it comes to the “installation” of the solution. However, just the docker-compose code is straightforward:

version: '3.8'
services:
  gitlab:
    image: gitlab/gitlab-ee:latest
    hostname: 'gitlab.mydomain.com'
    restart: always
    networks:
      - nginxproxy
    volumes:
      - '~/homelabservices/gitlab/data:/var/opt/gitlab'
      - '~/homelabservices/gitlab/config:/etc/gitlab'
      - '~/homelabservices/gitlab/logs:/var/log/gitlab'

    container_name: gitlab

Gitea, is super simple in its architecture by comparison. But, and this is a major but. Gitea doesn’t contain a native CI/CD pipeline inside the solution itself. So, you have to bolt-on solutions like Drone CI server to add this functionality. This adds complexity. And the fact that it isn’t a native to the solution, it means that you find yourself navigating between different solutions for a single project, which is a bit cumbersome. Keep this in mind between the solutions when it comes to the installation.

version: "3.8"

services:
  gitea:
    image: gitea/gitea:latest
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - GITEA__database__DB_TYPE=mysql
      - GITEA__database__HOST=gitea-db:3306
      - GITEA__database__NAME=gitea
      - GITEA__database__USER=gitea
      - GITEA__database__PASSWD=gitea
      - GITEA__security__INSTALL_LOCK=true
      - GITEA__security__SECRET_KEY=342bc7e3db20204ec9af2bb4ecbfa26688ad96d85fd82494e173b99b38fa2cf3
      - GITEA__service__DISABLE_REGISTRATION=true
      - GITEA__admin__USERNAME=admin
      - GITEA__admin__PASSWORD=password
      - [email protected]
      - GITEA__mailer__ENABLED=true
      - GITEA__mailer__SMTP_ADDR=10.1.149.19:8025
      - [email protected]
      - GITEA__mailer__PROTOCOL=mail
    networks:
      - npm-stack_nginxproxy
    volumes:
      - /mnt/cephfs/gitea/data:/data
    restart: always

  gitea-db:
    image: mysql:8
    environment:
      - MYSQL_ROOT_PASSWORD=gitea
      - MYSQL_USER=gitea
      - MYSQL_PASSWORD=gitea
      - MYSQL_DATABASE=gitea
    networks:
      - npm-stack_nginxproxy
    volumes:
      - /mnt/cephfs/gitea-db/mysql-data:/var/lib/mysql
    restart: always
   

networks:
  npm-stack_nginxproxy:
    external: true

2. Performance

This is the big one I think between the two solutions. I have used GitLab for quite some time now and performance of the solution, especially self-hosted is not really what it is known for. In fact, I have spent hours trying to tweak and tune my GitLab installation for better performance with caching, and other tweaks to make it perform better and more acceptably.

This is still the area of GitLab that I am most unhappy with. I haven’t been able to get the performance of the solution where I think it should be. I have thrown hardware at it, and other tricks, but still feels like there is something I am missing with the configuration. Let me know if you guys have any tricks up your sleeve.

Gitea on the other hand is built for performance and efficiency. It is super snappy and the site just “pops” when you deploy the container. In all fairness though, GitLab can do so much more beyond what Gitea can do and everything is native, without the need for bolt-on solutions that you have to pair with it for things like CI/CD.

3. CI/CD capabilities

Comparing both Gitea and GitLab for their CI/CD capabilities is a no contest between GitLab and Gitea. Gitea, doesn’t have built-in CI/CD. You will need to bolt-on something like Drone CI Server to have a CI/CD pipeline with your Gitea installation.

Thanks to the comments on the blog, Gitea does indeed have a native solution that was introduced at the end of 2023 – called Gitea actions. Using this in conjunction with the Gitea runners that were also recently released, you don’t have to bolt-on something like Drone CI. I will delve into this a bit more in a future article. Learn more from their official docs here: Overview | Gitea Documentation.

However, in looking at the solution there are some drawbacks to note. It looks like with Gitea actions you can’t spin up container images with tools you want to use, such as a VMware PowerCLI container image. It lacks the built-in functionality to specify and spin up custom container images on demand for each job, unlike something like GitLab CI/CD, where you can directly define the container image for a pipeline job.

In GitLab, this functionality is built into the solution. So you don’t have to install anything else. Simply spin up your GitLab instance and you are off and running.

With Gitea, you can easily integrate Drone with OAuth authentication tokens and this works very well. However, when working with it, it very much seems like a bolt on solution with you having to log into Drone to work with CI/CD and then back in gitea to work with your code. This back and forth can get a bit annoying.

Also, there are just simple things in GitLab CI/CD that works much better than Gitea+Actions or Gitea+Drone. The experience seems more natively backed in with GitLab.

4. Integrations

When it comes to integrations, both GitLab and Gitea offer integrations with various services and have the prebuilt integration options you can choose from to make sure you have the proper config instead of just setting up generic webhooks in the interface.

I do think GitLab’s integrations are smoother than Gitea. Also, for something simple like Discord notifications, I was able to configure this globally in GitLab, and it just works across all repos. For some reason in Gitea, it looks like I have to configure the webhook on each repo instead of being able to do this globally. I wasn’t able to get it to fire off when I simply had the integration configured in the site administration.

Below is a look at the integrations in Gitlab, you can see just how many there are and this is only part of the page. Also, you see the Discord integration created.

With Gitea, the list is much smaller:

5. Scheduling pipelines

This isn’t really as much a gripe with Gitea as it is with Drone CI that I tested for CI CD initially. I am curious to test the Gitea actions and runners that were recently introduced, which for full disclosure I have not tested as of yet. With Drone CI that I tested, scheduling CI/CD pipelines is cumbersome. In the UI interface, you only have the pre-canned options like @daily @weekly, etc.

To get granular configurations on your Drone CI CRON jobs, you have to download and use the Drone CLI which allows you to interact with the Drone CI Server. However, even when I have specific CRON job times scheduled, these appear to only be a recommendation to the server roughly when to run them as there are skews and offsets in play.

With Gitea Actions you can trigger actions based on things you would expect like code pushes, etc.

With GitLab, since the integration is native, the scheduling is rock solid. I can be confident knowing if I schedule something to run at 3:00 a.m., it will run at 3:00 a.m.

I think the integration with Gitea actions and runners will likely be better.

Wrapping up Gitea vs GitLab

Hopefully this comparison of Gitea vs GitLab is helpful and hopefully shares some of my findings with those who are wondering which git repo to self-host. Gitea is a great relative newcomer. I am still very fond of GitLab just too to the seamless nature of the solution. I am very familiar with the CI/CD functionality of GitLab more so than Gitea, but this is a part of the solution that I want to explore more.