Jan 16, 2021
Available now on GitLab

The latest features available on GitLab SaaS

New features are regularly released to GitLab SaaS (GitLab.com), with a packaged release available for GitLab Self-Managed on the 22nd of every month. Read on to learn more about the new features available on GitLab.com. Note that it may take a few days for a feature to become fully available on GitLab.com, due to deployment schedule and potential feature flags.

Additional information on past releases is available; be sure to check out the release for other features we've launched recently. We also have information about upcoming releases if you're interested in seeing what we are doing next.

Key features released in GitLab Preview

API Fuzz Testing results now visible in Security Dashboard

API fuzz testing results are now shown in the Security Dashboard and all other locations that security scanners show their results. You can now triage API fuzz testing results, create issues for them, and engage with your teams just like you can with other scanners.

We’re incredibly excited to bring these results out of the Tests tab so that you can integrate API fuzz testing alongside other security scanners and truly shift security left.

API Fuzz Testing results now visible in Security Dashboard

Manage Terraform state files through the UI

When managing your infrastructure with Terraform, you might create multiple state files, such as state files for each branch. To debug issues, you need an overview of the state files attached to your project, and various actions you can take for each state file. In previous versions of GitLab, managing Terraform state files required the API for tasks like releasing a state lock. We are now introducing a UI to list existing state files. It enables project maintainers to lock or unlock a state file, remove the state JSON, or to remove a state file entirely.

Manage Terraform state files through the UI

Searching for a file is the top use case in Advanced Search. Before this release, searching for files often required some specific syntax and was not very intuitive.

With GitLab 13.8, Advanced Search now supports full path searching. We have also made the file syntax search more flexible.

Improved file searching in Advanced Search

Export requirements to a CSV file

After completing development and verifying your product meets all requirements, it may be necessary to export the requirement status to allow for incorporation into a higher level requirements tracability analysis. With the introduction of the requirements export feature, this is now possible! Simply initiate the requirement export and they will be automatically sent to you in .CSV format, ready to import into other tools or provide to your customer.

This is the first iteration if this feature, so please provide feedback and follow along in the Requirements Export Epic

Export requirements to a CSV file

New deployment frequency charts in CI/CD dashboard

Knowing and monitoring deployment frequency is a starting point for organizations adopting DevOps. We are proud to introduce the deployment frequency charts at the project level so that you and your development teams can monitor the efficiency of deployments over time, find bottlenecks, and make improvements when necessary. This is the first of the DORA metrics that we are making available within GitLab out of the box.

New deployment frequency charts in CI/CD dashboard

Repeat failed test notification

When you’re reviewing the results of a Merge Request’s pipeline execution, there may be test failures to investigate further. It’s often hard to validate whether a test failure is accurate and needs to be fixed, or if it’s simply a flaky test that can be ignored. Figuring this out can be even more difficult when you’re not dealing with a brand new test failure.

The first minimal viable change for repeat failed test notification will provide you a count of how often a test has failed in previous pipelines on the Test Summary Merge Request Widget. We are requesting feedback from the wider community in this issue to understand what we can improve in future iterations of this feature.

Repeat failed test notification

Project configuration to control storage of latest artifacts

Keeping the latest artifact from the most recent successful job is a useful default behavior but can also result in significant amounts of storage usage. This can cause an unexpected surge in disk space usage if you have pipelines that generate large artifacts. To improve storage consumption management, you can now disable this behavior for any project in the settings.

Coming up next, gitlab#276583 will allow you to entirely disable keeping the latest artifacts at the instance level.

Project configuration to control storage of latest artifacts

Control job status using exit codes

You can use the allow_failure keyword to prevent failed jobs from causing an entire pipeline to fail. Previously, allow_failure only accepted boolean values of true or false but we’ve made improvements in this release, so now you can use the allow_failure keyword to look for specific script exit codes. This gives you more flexibility and control over your pipelines, preventing failures based on the exit codes.

Control job status using exit codes

Support `variables` for pipeline `rules`

Previously, the rules keyword was limited in scope and only determined if a job should be included or excluded from pipelines. In this release, you can now decide if certain conditions are met and subsequently override variables in jobs, providing you with more flexibility when configuring your pipelines.

Support `variables` for pipeline `rules`

Other improvements in GitLab Preview

Busy status indicator

With status updates, users can currently share a personalized status message and emoji with their team. We are now taking this one step further with a busy indicator. By marking yourself as Busy, your coworkers can easily see when you are unavailable for code reviews and other tasks. The Busy status will be displayed next to your name throughout the GitLab user interface.

Busy status indicator

Support for predefined variables in CI include section

Regulated customers rely on GitLab’s CI/CD capabilities to define and automate their security and compliance jobs and processes for deploying changes to sensitive environments. They need to ensure they’re maintaining separation of duties between the teams writing code and the teams deploying that code and these jobs always run in sensitive environments.

In 13.8, you can now use predefined project variables in the include: section of your .gitlab-ci.yml file. This change is part of a bigger solution to bring better separation of duties control to your GitLab CI/CD pipelines.

Scope a board to the current iteration

Many teams use boards to manage issues during an iteration. In 13.6, we added support for filtering issues on a board to a specific Iteration, but it is cumbersome to remember to apply that filter every time you go to your board.

In this release, we’ve added the ability to scope your board to the currently active iteration.

Scope a board to the current iteration

Approval Rule information for Reviewers

When working to have your merge request reviewed, approved, and finally merged, it’s important to select the right people to perform those tasks. Asking for a review from people who can’t provide the approvals can slow down the process of delivering your contribution.

From GitLab 13.8 onwards, when selecting a reviewer for your merge request, you can see which approval rules that the user matches displayed right below the reviewer’s name.

Approval Rule information for Reviewers

When viewing a commit in GitLab, the merge requests containing the commit are linked. Finding the merge request that added the commit is very useful when you are trying to find the business and technical context of a change.

If you use squash or merge commits, merge request information was not previously included. GitLab 13.8 now includes merge request links for all commit types, ensuring you can find where a change was introduced.

Rebase quick action for merge requests

Rebase is a Git command used to reapply commits on top of a new commit. In practice, this means reapplying commits from a feature branch on top of the latest version of the target branch (e.g. main). In this way, it is possible to bring the feature branch up to date and resolve any conflicts without using a merge commit with the benefit of a simpler linear Git history.

GitLab 13.8 brings the ability to execute the rebase quick action in merge requests, allowing you quickly invoke the rebase Git utility.

On a merge request comment, type /rebase and click the Comment button. It’s that simple.

Active scan mode in on-demand DAST scanner profile

Used in conjunction with the new site validation feature, active DAST scans are now available for configuration in the on-demand DAST scanner profile. After validating a site for ownership, you can configure an active scan to run against the site. These scans include actual, destructive, malicious attacks against the site. Because of this, we recommend and encourage that you only use an active scan on staging and test sites that do not contain production data, where data loss is not a concern.

Improved SAST severity data for JavaScript vulnerabilities

When available from our security scan analyzers, GitLab Static Application Security Testing provides severity data for identified vulnerabilities. We recently updated our JavaScript analyzer, ESLint, to add support for severity and CWE data. This data will help increase the usability and accuracy of Security Approval Rules as fewer vulnerabilities will report ‘Unknown’ severity. Additionally this data is shown on vulnerability detail pages providing more information and links to relevant information about vulnerabilities making it easier for developer to understand and remediate issues. In the future, we will augment other analyzers missing vulnerability metadata and add a mechanism to allow customized vulnerability metadata enabling organizations to tailor results to match their risk profiles.

Improved SAST severity data for JavaScript vulnerabilities

Improved pipeline status email subject line

GitLab sends email notifications when your pipeline succeeds, fails, or is fixed. In previous releases, these emails looked similar. This made it hard to tell the pipeline status without reading the entire body of the email. This release updates the subject line of these email notifications so you can determine pipeline status with a quick glance.

Improved pipeline status email subject line

Upload metrics images directly to incidents

Processing incidents during a fire-fight requires responders to coordinate across multiple tools to evaluate different data sources. Collecting and assessing metrics, logs, and traces - and sharing these with a response team - is time-consuming and challenging. We’ve streamlined this workflow by providing drag-and-drop uploads for these screenshots in a new Metrics tab on incidents. Aggregate and centrally locate all your screenshots of metrics so your team can quickly access and reference important charts.

Upload metrics images directly to incidents

Compare repositories and validate if they are the same

One Git repository can be compared to another by checksumming all refs of each repository. If both repositories have the same refs, and if both repositories pass an integrity check, then we can be confident that both repositories are the same. For example, this can be used to compare a backup of a repository against the source repository.

The new gitlab:git:checksum_projects rake task allows systems administrators to select a subset of projects by ID or loop through all projects, and output a checksum of the Git references that can be compared to a copy of the same project.

Group webhook for members (edit, remove)

In GitLab 13.7, we introduced a webhook that is triggered when a new member is added to a group. In GitLab 13.8, the group member events webhook will also be triggered if the access level of a user has changed, the expiration date for user access has been updated, or a user has been removed from the group. With the addition of these events, the group member events webhook can be used to be aware of all changes made to group members without relying on API calls which put unnecessary performance load on your GitLab instance.

Display all available quick actions in autocomplete

When you enter / into a description or comment field, all available Quick Actions are now displayed in a scrollable list. Quick Actions are a great way to efficiently update data on an issue, merge request, or epic, and this small improvement helps them be more discoverable in the context in which they are used.

Display all available quick actions in autocomplete

Send an email to an issue

To more efficiently integrate GitLab into your email workflows, each issue now has a unique email address. Emailing an issue creates a new comment on your behalf. You can now say goodbye to manually copying email content and attachments into your GitLab issues.

Send an email to an issue

Designate optional sections in the codeowners file

Code owner sections allow multiple teams to configure their own code owners independently in the same file. This means teams can be assigned as code owners in their own section so that each team is added as a distinct reviewer in merge requests. This helps when multiple teams are responsible for common parts of the code, by helping authors getting feedback from the right reviewers. However, when approval from Code Owners is required, this applies to all the sections meaning all teams need to approve, which can hold back a changes from getting merged.

GitLab 13.8 introduces the ability to designate optional sections in your code owners file. Simply prepend the section name with the caret ^ character and the section will be treated as optional. This means, related change through merge requests will not require approval from designated owners. With optional sections you may continue to designate responsible parties for various parts of the code while providing a more relaxed policy for parts of your project that may be updated often but don’t require stringent reviews.

Rate Limit Dry Run Mode and Bypass Mechanism

It can be challenging to set rate limits for your application in such a way to allow requests from trusted sources while blocking malicious traffic. We have made several enhancements to make it easier to properly set rate limits. First, you can now test rate limit settings using a new dry run mode that checks requests against each rate limit and logs the results without actually blocking the client. This lets you fine tune request throttle settings before enabling them in production.

Second, you can also configure specific requests. This allows you to better support trusted services.

Finally, you can configure specific users to bypass the rate limiter. This allows you to better support trusted users accessing your GitLab instance.

Use rich output for Jupyter notebooks

Jupyter notebooks are documents that contain live code, equations, visualizations, and narrative text. They are widely used for data cleaning and transformation, numerical simulation, statistical modeling, data visualization, machine learning, and more. They are capable of using “rich output” to show an object’s rendered representation, such as HTML, JPEG, SVG, or LaTeX files. Previously, opening the notebook in Jupyter was the only way to read it with rich output.

GitLab 13.8 now shows rich output for Jupyter notebook content by default. This is an excellent way both to preview changes to your files as well as consume Jupyter notebook without ever having to leave GitLab.

Use rich output for Jupyter notebooks

Add DAST.latest.gitlab-ci.yml template

GitLab’s DAST has always had only a single template that isn’t versioned and is updated whenever we need to change things. This has proven difficult for users whose tests break after a template update. Starting in GitLab 13.8, we introduce a .latest version of the template. This template includes all template changes made between major releases, including breaking changes. This gives users a warning that changes are coming and enables them to test the changes for themselves before being forced to switch.

Breaking changes are brought into the stable template on the next major GitLab version. For non-breaking changes, these can be brought into the stable template after living in the latest template for a few releases. The speed at which the changes are incorporated into the stable template depends on a number of factors and takes into account feedback from users as they test the changes in the latest template.

Site validation for on-demand scans

Beginning in GitLab 13.8, users can validate that they own or have permission to test the domains added as a site profile. By adding a text file with a project- and site-specific string to their site, users can validate ownership of the domains. The validation process unlocks the ability to run active DAST scans against the domain. Since active DAST scans include actual attacks against the site, site validation provides a level of assurance that users can’t accidentally run an active scan against a site where they could cause data loss or damage. Because of this, any site profile that uses a domain that isn’t validated is only allowed to use scanner profiles that use a passive scanning mode.

GitLab Terraform Provider 3.4 updates

If you use Terraform to set up GitLab, we are happy to announce version 3.4.0 of the GitLab Terraform Provider. In the past months, the provider received support of project mirroring, group sharing, project approval rules and instance level CI variables, beside many smaller enhancements and a few bug fixes.

Alpha Geo support for PostgreSQL high-availability

Patroni is a solution for PostgreSQL high availability which also allows the configuration of a highly available PostgreSQL standby cluster on a Geo secondary. This configuration is important when a secondary is used as part of a disaster recovery strategy because it allows systems administrators to mirror the number of database nodes on the primary and secondary. This means that after a failover, no additional database nodes need to be provisioned to regain high-availability.

Geo now provides alpha-level support for highly available PostgreSQL configurations using Patroni. We’ve upgraded Patroni to 2.0.1, added failover documentation and fixed a number of bugs.

Advanced Search can scale from small personal instances all the way up to GitLab.com. On some of the largest instances however, search can slow down as the size of the index grows, and the number of permissions needing to be checked.

In GitLab 13.8 we have split out issues into their own index, making Advanced Search faster for larger instances. We have also simplified the method of permissions checks, further improving performance.

This update will apply automatically, without a need to conduct a manual reindex. The process takes less than 2 hours, however there will be a delay in indexing new content while this completes.


DAST environment variable renaming and removal

GitLab 13.8 renames multiple environment variables to support their broader usage in different workflows. In GitLab 14.0, the old variables will be permanently removed and will no longer work. Any configurations using these variables must be updated to the new variable names. Any scans using these variables in GitLab 14.0 and later will fail to be configured correctly. These variables are: - DAST_AUTH_EXCLUDE_URLS will now be DAST_EXCLUDE_URLS - AUTH_EXCLUDE_URLS will now be DAST_EXCLUDE_URLS - AUTH_USERNAME will now be DAST_USERNAME - AUTH_PASSWORD will now be DAST_PASSWORD - AUTH_USERNAME_FIELD will now be DAST_USERNAME_FIELD - AUTH_PASSWORD_FIELD will now be DAST_PASSWORD_FIELD - DAST_ZAP_USE_AJAX_SPIDER will now be DAST_USE_AJAX_SPIDER - DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIRED will be removed, since the feature is being removed

Deprecation date: Jun 22, 2021

Deprecate Container Registry log formatters

Currently, GitLab supports:

  • Text, JSON, and logstash log formatting for app logs.
  • Text, JSON, and combined log formatting for access logs.

We will deprecate both logstash and combined, unifying the formatters for both app and access logs with only two options text (for development) and JSON.

Deprecation date: January 22nd, 2021

Deprecate Container Registry logging hooks

The Container Registry currently supports logging hooks that can only be used for email notifications.

These days, alerts based on log entries are commonly handled by separate tools. As far as we know, none of our users rely on this functionality and it is not used at GitLab either. The implementation of this feature is tightly coupled with the underlying logging library, which is a limitation for our ability to switch dependencies without affecting the available features.

In an effort to simplify the registry features and configurations, we will drop support for logging hooks.

Deprecation date: January 22nd, 2021

Deprecate Container Registry maxidle and maxactive Redis pool settings

Some of the configuration settings that we currently expose for the Redis connection pool are tied to the underlying Redis client and do not have an equivalent in alternative libraries. As we start working on improving the Redis integration, such as adding support for Sentinel, we decided to start working towards replacing the current Redis client dependency with a more feature-rich alternative that can be better supported. To do this, we need to replace the current Redis pool configuration settings that are tied to the current client library.

We intend to:

  • Remove the redis.pool.maxidle and redis.pool.maxactive settings.
  • Add redis.pool.size (maximum number of connections), redis.pool.minidle (minimum number of idle connections), and redis.pool.maxlifetime (maximum amount of time a connection may be reused) settings.

Deprecation date: January 22nd, 2021

Deprecate Container Registry support for Bugsnag

Bugsnag is one of the error reporting services supported by the Container Registry. As far as we know, none of our users rely on this service, and at GitLab we use Sentry. In an effort to simplify and consolidate the supported error reporting services, we intend to add support for Sentry and remove support for Bugsnag.

Deprecation date: January 22nd, 2021

Deprecate Container Registry support for NewRelic

NewRelic is one of the error reporting services supported by the Container Registry. As far as we know, none of our users rely on this service, and at GitLab we use Sentry. In an effort to simplify and consolidate the supported error reporting services, we intend to add support for Sentry and remove support for NewRelic.

Deprecation date: January 22nd, 2021

Deprecate Container Registry support for TLS 1.0 and 1.1

Support for TLS 1.0 and TLS 1.1 has been deprecated and removed for GitLab for security reasons. We will do the same for the GitLab Container Registry, which currently supports 1.0 (default), 1.1, 1.2, and 1.3. and defaults to 1.0.

We will deprecate support for TLS 1.0 and TLS 1.1, showing a warning log message when these are used. Support for these versions will be removed and TLS 1.2 will become the default.

Deprecation date: January 22nd, 2021

Deprecate Gitaly support for TLS 1.0 and 1.1

Support for TLS 1.0 and TLS 1.1 has been deprecated and removed from GitLab for security reasons. We will do the same for Gitaly as there are cases where the minimum TLS version was not set and was therefore defaulted to TLS 1.0.

Gitaly will be configured to use TLS 1.2 at a minimum for all client and server-side connections.

Deprecation date: January 22, 2021

Deprecate pulls that use v1 of the Docker registry API

GitLab is disabling pulls via the Docker registry v1 APIs on January 22nd, 2021. Deprecated by Docker in June, 2019, deprecating this feature allows the GitLab team to focus on features and fixes that provide you with more value and target current registry use cases.

Existing users of the v1 registry API on GitLab can move to the v2 registry API by completing the following steps:

  1. Update your Docker Engine to 17.12 or later so it is compatible with the v2 registry API.
  2. If you have content in GitLab that is in the v1 format, you can move it to the v2 format by using a newer Docker client (more recent than 1.12) to rebuild the image and push it to GitLab.

Deprecation date: January 22nd, 2021

GitLab Runner installation to ignore the skel directory

In GitLab Runner 14.0, the installation process will ignore the skel directory by default when creating the user home directory. Refer to issue #4845 for details.

Deprecation date: Jun 22, 2021

Make pwsh the default shell for newly-registered Windows Runners

In GitLab Runner 13.2, PowerShell Core support was added to the Shell executor. In 14.0, pwsh will be the default shell for newly-registered Windows runners. Windows CMD will still be available as a shell option for Windows runners. Refer to issue #26419 for details.

Deprecation date: Jun 22, 2021

Removal of legacy fields from DAST report

As a part of the migration to a common report format for all of the Secure scanners in GitLab, DAST is making changes to the DAST JSON report. Certain legacy fields are being deprecated in 13.8 and will be completely removed in 14.0. These fields are @generated, @version, site, and spider. This should not affect any normal DAST operation, but does affect users who consume the JSON report in an automated way and use these fields. Anyone impacted by these changes who needs these fields for business reasons is encouraged to open a new GitLab issue and explain the need.

For more information, see the removal issue.

Deprecation date: Jun 22, 2021

In GitLab Runner 13.3, a symlink was added from /user/lib/gitlab-runner/gitlab-runner to /usr/bin/gitlab-runner. In 14.0, we will remove this symlink and the runner will be installed in /usr/bin/gitlab-runner. Refer to issue #26651 for details.

Deprecation date: Jun 22, 2021

Remove DAST default template stages

In GitLab 14.0, the stages defined in the current DAST.gitlab-ci.yml template will be removed to avoid the situation where the template overrides manual changes made by DAST users. This change is being made in response to customer issues where the stages in the template cause problems when used with customized DAST configurations. Because of this removal, gitlab-ci.yml configurations that do not specify a dast stage must be updated to include this stage.

In GitLab 13.8, the stages are deprecated and the changes to remove them from the template are included in the DAST.latest.gitlab-ci.yml template. Anyone can test and see if any changes are needed in their configuration files.

Deprecation date: Jun 22, 2021


In GitLab Runner 13.1, issue #3376, we introduced sigterm and then sigkill to a process in the Shell executor. We also introduced a new feature flag, FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL, so you can use the previous process termination sequence. In GitLab Runner 14.0, issue #6413, we will remove the feature flag.

Deprecation date: Jun 22, 2021


In GitLab Runner 14.0, we will remove the FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER feature flag. Refer to issue #27175 for details.

Deprecation date: Jun 22, 2021

Remove Ubuntu 19.10 (Eoan Ermine) package

Ubuntu 19.10 (Eoan Ermine) reached end of life on Friday, July 17, 2020. In GitLab Runner 14.0, we will remove the Ubuntu 19.10 (Eoan Ermine) from our package distribution. Refer to issue #26036 for details.

Deprecation date: Jun 22, 2021

Remove legacy DAST domain validation

Starting with GitLab 13.8, the current method of DAST Domain Validation for CI/CD scans is deprecated. In GitLab 14.0, the legacy DAST validation method will be removed. This method of domain validation only disallows scans if the DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIRED environment variable is set to true in the gitlab-ci.yml file, and a Gitlab-DAST-Permission header on the site is not set to allow. This two-step method created a situation in which users had to opt-in to using the variable before they could opt-out from using the header. For users concerned about protecting a site against a full, active scan, permission for a GitLab DAST scan can still be revoked by adding to any website a Gitlab-DAST-Permission header with a value of deny. This continues to block GitLab DAST scans attempted against any website that includes this HTTP header.

For more information, see the removal issue.

Deprecation date: Jun 22, 2021

Remove off peak time mode configuration for Docker Machine autoscaling

In GitLab Runner 13.0, issue #5069, we introduced new timing options for the GitLab Docker Machine executor. In GitLab Runner 14.0, we plan to remove the old configuration option, off peak time mode.

Deprecation date: Jun 22, 2021

Remove success and failure for finished build metric conversion

In GitLab Runner 13.5, we introduced failed and success states for a job. To support Prometheus rules, we chose to convert success/failure to finished for the metric. In 14.0, we will remove the conversion. Refer to issue #26900 for details.

Deprecation date: Jun 22, 2021

Remove translation from step_script to build_script in custom executor

In GitLab Runner 13.2 a translation for step_script to build_script was added to the custom executor. In 14.0 the ‘build_script’ stage will be replaced with ‘step_script`. Refer to issue #26426 for details.

Deprecation date: Jun 22, 2021


Default DAST spider begin crawling at target URL

In GitLab 14.0, DAST will remove the current method of resetting the scan to the hostname when starting to spider. Previous to GitLab 14.0, the spider would not begin at the specified target path for the URL but would instead reset the URL to begin crawling at the host root. In GitLab 14.0, the default for the new variable DAST_SPIDER_START_AT_HOST will be changed to false to better support users’ intention of beginning spidering and scanning at the specified target URL, rather than the host root URL. In addition to starting to crawl the specified URL, this will have an added benefit that scans could take less time, if the specified path does not contain links to the entire site. This will enable easier scanning of smaller sections of an application, rather than the entire app being crawled at every scan.

Removal date: Jun 22, 2021

We have enabled a deeper integration with Opsgenie and other alerting tools through HTTP endpoint integrations so you can see alerts within the GitLab interface. As a result, the previous link to Opsgenie in the alerts list has been deprecated in this release.

Removal date: January 22, 2021


Please check out the changelog to see all the named changes:


If you are setting up a new GitLab installation please see the download GitLab page.


Check out our update page.

GitLab Subscription Plans

GitLab is available in self-managed and cloud SaaS options.

Self-managed: Deploy on-premises or on your favorite cloud platform.

  • Core: For small teams, personal projects, or GitLab trials with unlimited time.
  • Starter: For co-located teams with few projects who need professional support.
  • Premium: For distributed teams who need advanced features, high availability, and 24/7 support.
  • Ultimate: For enterprises that want to align strategy and execution with enhanced security and compliance.

Cloud SaaS - GitLab.com: hosted, managed, and administered by GitLab with free and paid subscriptions for individuals and teams.

  • Free: Unlimited private repositories and unlimited collaborators on a project. Private projects get access to Free features, public projects gets access to Gold features.
  • Bronze: For teams that need access to more advanced workflow features.
  • Silver: For teams that need more robust DevOps capabilities, compliance and faster support.
  • Gold: Great with many CI/CD jobs. Every public project get the features of Gold for free irrespective of their plan.

Try all GitLab features - free for 30 days

GitLab is more than just source code management or CI/CD. It is a full software development lifecycle & DevOps tool in a single application.

Try GitLab Free

Try GitLab risk-free for 30 days.

No credit card required. Have questions? Contact us.

Gitlab x icon svg
Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license