GitLab
Last updated: Nov 4, 2026
Rationale
GitLab is the platform that Fluid Attacks uses to develop its software. It gives important services, for example, Git repositories, merge requests, development planning, CI/CD, and many more.
These are the primary reasons why Fluid Attacks selected GitLab and not other alternatives:
- It is open source.
- It is SaaS.
- It is a DevOps Suite. Thus, all its technical work is to make a workflow that gets high-quality code to production as securely and as quickly as possible. This vision agrees with the vision of Fluid Attacks about software development and the current development cycle.
- It has its own Continuous Integrator with built-in support, which is necessary for the development cycle of Fluid Attacks.
- It gives Development Planning with issues, milestones, roadmaps, and more. These features are necessary to set task priorities and assign resources.
- It has very customizable permissions settings. Thus, Fluid Attacks can give permissions with a granular approach for each user. Fluid Attacks can also publish only some sections of a project with a granular approach for each section.
- It supports Two-factor Authentication.
- It supports Merge Requests. Thus, developers can open requests to send their changes to production.
- It supports Merge Request Approvals. Fluid Attacks uses one approval rule: the GitLab bot must approve each merge request. The review policy of the bot decides who else must approve. For example, the paths that owe a review must get an approval from an approver of that path, and trusted authors do not need other approvers. Authors cannot approve their own merge requests.
- It has a very complete REST API. With it, Fluid Attacks automates processes, for example, reviewing merge requests, rotating AWS secrets, and programmatically cloning repositories.
- It has its own Container registry. Thus, Fluid Attacks keeps all its containers in the same location.
- It supports CI/CD schedules. Thus, Fluid Attacks can easily run scheduled jobs.
- It supports Environments to get access easily to development and production environments.
- It supports built-in Analytics that give issue insights, CI/CD analytics, merge request analytics, issue analytics, repository analytics, and more.
- It supports many ChatOps integrations. Thus, Fluid Attacks has an open, dedicated telemetry channel on its internal chat platform that gets all types of important information from GitLab. Developers only have to monitor it to know what occurs with merge requests, issues, failed jobs, and more.
- It supports Repository Mirroring. Thus, Fluid Attacks has a mirror of its repository on GitHub.
- It supports Project Access Tokens. These tokens make the integrations of Fluid Attacks much more secure and reliable. The reason is that Fluid Attacks uses tokens that are bound to a project, not to a user account.
- It supports SSH Signed Commits. With signed commits, Fluid Attacks can make sure that a commit comes from the person who it identifies. Push rules also reject commits from a committer who is not the person who pushes.
- It supports GitLab Pages, a very easy method to publish static web pages.
- It supports Protected Branches, an important feature that makes sure that no user or bot can push to the primary production branch. Thus, developers must get to production through merge requests.
- It supports infrastructure integrations for Error Tracking, Tracing, Metrics, and more.
- It supports Push Rules that let Fluid Attacks customize more what users can and cannot push to the repository. For example, branch naming, signed commits, secret pushing prevention, and more.
Alternatives
- Azure DevOps: It was not available at that time. It is not open source.
- BitBucket: It is not a DevOps solution, but a source code repository. It did not integrate with a CI/CD solution.
- GitHub: It is not a DevOps solution, but a source code repository. It did not integrate with a CI/CD solution.
Usage
Fluid Attacks uses GitLab for these tasks:
- To host its universe repository
- To host its issues
- To host its milestones
- To open its merge requests
- To host its containers
- To show jobs and pipelines
Fluid Attacks does not use GitLab for these tasks:
- Implementing it as code: Fluid Attacks can implement only a part of GitLab as code with Terraform.
- Security scans: Fluid Attacks tried to implement them before, but it could not, because the scans had a small number of parameters.
- Operations: Fluid Attacks uses Datadog instead for logs, metrics, traces, error tracking, and monitoring.