GitLab is a powerful, open-source code management platform that offers different subscription types. Although there is a free version that is open to everyone, the premium version has additional features and support.
Like any other IT company, we always look for ways to optimize costs and improve efficiency. This blog post will tell the story of how we moved to Self-Hosted GitLab and saved over $10,000 yearly for a client.
In October 2022, GitLab changed its subscription model. There are three plans:
- Premium—$19 per user/month
- Ultimate—$99 per user/month.
Switching to a paid subscription or looking for alternatives became necessary for large teams and projects.
The free plan supports up to 5 users in a project or group and is unsuitable for us. It is possible to deploy our self-hosted GitLab CE, but this will require infrastructure and support costs.
In one of our projects, all the binding in the form of CI and environments had already been made for the specifics of GitLab, and the number of repositories numbered several dozen. First, we looked at the proposals of GitLab so as not to waste time on pipelines. Moreover, we had to consider that the total number of users in the project was around 64.
The free plan supports up to 5 users in a project or group, and it was not a right fit for us. We could deploy our self-hosted GitLab CE, but it would require infrastructure and support costs.
Let’s do the simple math.
If we had bought a Premium subscription: 64 users * $19 = $1,216 per month or $14,592 per year (Subscriptions must be paid annually).
And if we raise our GitLab in AWS (the cost in GCP is about the same):
- The minimum recommendation for a self-hosted instance for a service of up to 500 users is 4 CPU 8 Mem, which is ~$130 per month;
- 200Gb drive with daily snapshots up to 14 days is ~$26 per month;
- RDS database with daily snapshots storage for up to 10 days is ~$50 per month;
- S3 bucket for storing caches and artifacts is ~$1 per month.
- Total: ~$207 per month.
NB: Here, we consider only the main GitLab service without runners because their value in all cases is constant.
After the estimation, we presented the results to the customer and discussed the obvious benefit of having a leftover $1,000 per month. We also separately drew attention to the need to support and regularly update our own GitLab CE. We added about 6 hours a month for support and started moving.
In IT, you can adopt several strategies and best practices to help achieve optimized cost goals. If you are still deciding what to choose, you can tell us about your project at a free consultation. Our Delivery Managers will carefully consider your case and offer the most suitable and profitable solution for cost optimization.
Using Terraform, we created a network, storage, S3, instance, and RDS in the cloud. This is our favorite IaC (Infrastructure as Code) approach, which makes it convenient to manage the infrastructure and, if necessary, reuse the finished code.
As a VM image, we used the official GitLab CE AMI (Amazon Machine Image)—an image that is updated and maintained by GitLab itself. To update the GitLab version and not be afraid that the instance will break, we used the ASG (Auto Scaling Group) with the Launch template, to which we transferred the AMI image, instance type, disk configuration, etc.
Moreover, we used a small bash script in User Data to reconfigure and roll our data and configs automatically. It runs immediately after creating the instance, checks the availability of the allocated IP address and storage with data and configuration, and subsequently reconfigures the new model into “our” GitLab.
So, “our” GitLab is configured and tested. Next, we must migrate users and repositories from SaaS GitLab to self-hosted GitLab.
If you're, like most people, always looking for ways to save money, one of the options is to use cloud services. Cloud cost optimization is a hot topic these days; learn more about it in our new article.
To avoid violating the deadlines and not interfering with the developers themselves, it was necessary to agree on and draw up a plan to migrate repositories. For the convenience of user migration, we added Google OAuth with authorization in our Google organization and asked all developers to log in to the new GitLab, thus getting users.
Furthermore, the repositories had to be migrated one by one manually through the export/import mechanism. At the same time, it was necessary to consider that the CI/CD and webhook settings are not exported because they depend on the environments. They had to be adjusted manually for each repository. In addition, we had to connect our group runners as shared runners from GitLab SaaS will not be available.
We moved the repositories, set up the CI environment and webhooks, and checked with the developers that everything worked.
Pros and cons of this decision:
|FEATURES||SELF-HOSTED GITLAB||SAAS GITLAB|
|Full access to the API||+||-|
While Self-Hosted GitLab provides more options, it requires you to have your own support.
For a modest amount of money, the client received git hosting (GitLab CE), which is slightly inferior in functionality to the premium version of SaaS in some aspects but is generally suitable for work.
If you have a large team and are not willing to pay over $10,000 per year, working with self-hosted GitLab is for you. Of course, such a choice will oblige you to deal with support, allocate additional time for engineers, and the responsibility for the work of GitLab will be entirely on the DevOps team, but this can save you a lot of money.
If you have a small team and don't want to spend time maintaining git hosting, SaaS is a great option. You can get an out-of-the-box, working solution by buying a subscription rather than worrying about infrastructure.
Want to learn more? You can read about how the Mad Devs team optimized the infrastructure for Veeqo, an inventory and shipping e-commerce platform. You can also contact us, and we'll answer all your questions.