GitLab is a bargain

Some things you don't need to worry about if you use GitLab

Brett Weir Dec 30, 2022 8 min read

GitLab has its rough edges, but if you can tolerate them, what you get in return is possibly the most and best integrated development toolset in existence.

This is because GitLab brings a number of fairly substantial and important features, in their own right, under one roof, where they already work together and are centrally managed.

Continuous integration

It may be old news to some, but GitLab CI/CD is actually fantastic. It's simple, powerful, and deeply integrated into GitLab's platform, making it the easiest CI/CD system to adopt when using GitLab for source management.

In addition, the GitLab Runner is written in Go and can be widely and easily deployed on target hardware. It can run jobs on cloud VMs, bare metal machines, Kubernetes, and can be deployed on embedded hardware for in-place testing. It is even possible to deploy custom runners. For example, you use it to run jobs on a legacy machine that your company is contractually obligated to support.

In other words, in GitLab, CI/CD is largely a solved problem, so messing around with third-party CI systems is a waste of time if your team is already using GitLab. There may be scenarios in which a team needs a specialized CI system, but more often than not, that's probably not you. The BrettOps pipeline catalog demonstrates that you can accomplish an awful lot with a general-purpose CI/CD system.

Services eliminated from our stack:

Package hosting

Teams improve development velocity by using pre-built artifacts. This allows package consumers to treat them as black boxes, rather than having to check out, configure, build, and test each package before using it. It also guarantees that consumers are using known-good builds that have already been verified by an upstream process.

Using pre-built artifacts is only possible when you have a place to put artifacts. The form these artifact repositories take on varies wildly between different implementations and organization environments, or perhaps they just don't exist at all. Either that, or get ready to spend a bunch of money on a fancy standalone artifact system like Artifactory or Sonatype Nexus.

Let's talk about what life looks like with other tools:

  • JFrog Artifactory costs a small fortune. The Free tier only allows 2GB storage and 5GB data transfer. These limits are hit incredibly easily if you're building containers or using a CI/CD system. Never mind if your company does anything with machine learning. The $98 / month Pro tier only allows 4GB storage and 20GB transfer. A real implementation would take you right into the $1199 Enterprise X tier. Yikes.

  • Sonatype Nexus costs $13 / user / month to host it yourself (there's also a free version). It does almost as much as Artifactory, so it's a strong contender, but it's too much work for a startup to run something like that.

  • AWS CodeArtifact / Azure Artifacts are pretty cheap, and identically only offer PyPI, Maven, npm, and NuGet hosting. They aren't fully featured, but they're great options if you're using those clouds. You still have the problem of somehow integrating this with your CI/CD environment though.

GitLab Package Registry makes this complexity very easy. It supports package types a mile long: (at the time of writing) Composer, Conan, Debian, Go, Helm, Maven, npm, NuGet, PyPI, Ruby gems, Yarn, and a Generic package type that is useful for hosting whatever you need a place for. Again, it does all of this at no additional cost and inherits the permissions of your GitLab users, so it's pretty simple to manage access to your organization. There's no additional credentials to set up either, because the GitLab job token always has the right access. You can check out the BrettOps python pipeline for a complete example of using the GitLab Package Registry. Problem solved.

Services eliminated from our stack:

Container hosting

Containers are everywhere. Something you're doing probably needs one, and you probably already have a container registry somewhere holding them. If it's not GitLab, think again.

GitLab Container Registry means that every project can easily store Docker container images. No extra approval or configuration steps needed. It's just there. Check out the BrettOps container pipeline for a zero-config container build pipeline that works for a majority of use cases. The UI is basic, but the utter convenience of zero administrative overhead for container hosting is bliss. Hosting containers on GitLab when you are using GitLab CI/CD shared runners also means that you don't need to pay data transfer costs when building and pushing containers.

The GitLab Dependency Proxy gives you a container image proxy built into GitLab, so any container pulls from Docker Hub can be proxied through GitLab instead. This sidesteps rate limiting, avoids the need for an extra Docker Hub subscription, and is good for business continuity as well. For a real multi-user implementation, this avoids an extra $9 / user / month just to pull common images like Alpine and Ubuntu.

Services eliminated from our stack:

Terraform state management

Terraform is the greatest thing in the universe, but it's useless for anything other than local development unless you have a way to centrally manage and delegate access to all the state files it produces.

Hashicorp has built an awesome Terraform Cloud offering that cleanly integrates with the Terraform CLI, and in terms of user experience, it's hard to beat. However, all that awesomeness comes with a price tag.

You can't access the full pricing on the website, but you can find a real breakdown by logging in and creating an organization (😮‍💨):

  • Free Plan - $0.00 / user / month
  • Team Plan - $20.00 / user / month
  • Team & Governance Plan - $70.00 / user / month
  • Business Plan - Call sales?

In the Free Plan, you better hope you trust your team, because everyone will have root access. The Team Plan gives you access control. The Team & Governance Plan adds more cool stuff. Unfortunately, unless you're willing to get on the phone with a sales rep, you can only run a single job at a time, which means that active teams, even small ones, will spend a lot of time waiting for Terraform runners.

All of this adds up to you most likely having to pay a lot to use Terraform Cloud with a team of any significant size.

GitLab, on the other hand, offers GitLab-managed Terraform state, even on the free tier! It's not as smooth as Terraform Cloud, but it works, which means:

  • You don't need to roll your own state management system if you don't want to buy Terraform Cloud.

  • You can run as many concurrent plans as there are CI runners (∞).

  • Your Terraform projects inherit the permissions and roles of GitLab, so no separate memberships to manage.

Anyone in your company with a GitLab account can now participate in Infrastructure-as-Code projects, at no extra cost.

Services eliminated from our stack:


There will always be use cases that require special tools and fancy features, but for many organizations, the default settings are just fine, and surprisingly powerful.

GitLab is a cheap and effective tool that allows your organization to save potentially hundreds of dollars, per user, per month, on third-party tooling while actually increasing productivity.

Just use GitLab!