[{"data":1,"prerenderedAt":843},["ShallowReactive",2],{"/en-us/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0":3,"navigation-en-us":40,"banner-en-us":450,"footer-en-us":460,"blog-post-authors-en-us-Martin Brümmer|Fabian Zimmer|Sam Wiskow":701,"blog-related-posts-en-us-a-guide-to-the-breaking-changes-in-gitlab-18-0":740,"blog-promotions-en-us":780,"next-steps-en-us":833},{"id":4,"title":5,"authorSlugs":6,"body":10,"categorySlug":11,"config":12,"content":16,"description":10,"extension":28,"isFeatured":14,"meta":29,"navigation":30,"path":31,"publishedDate":24,"seo":32,"stem":36,"tagSlugs":37,"__hash__":39},"blogPosts/en-us/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0.yml","A Guide To The Breaking Changes In Gitlab 18 0",[7,8,9],"martin-brmmer","fabian-zimmer","sam-wiskow",null,"product",{"slug":13,"featured":14,"template":15},"a-guide-to-the-breaking-changes-in-gitlab-18-0",false,"BlogPost",{"title":17,"description":18,"authors":19,"heroImage":23,"date":24,"body":25,"category":11,"tags":26},"A guide to the breaking changes in GitLab 18.0","Prepare now for the removals in our upcoming major release. Assess your impact and then review the mitigation steps provided in the documentation to ensure a smooth transition to GitLab 18.0.",[20,21,22],"Martin Brümmer","Fabian Zimmer","Sam Wiskow","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659437/Blog/Hero%20Images/AdobeStock_398929148.jpg","2025-04-18","GitLab 18.0, our next major release, will be packed with new features that push the boundaries of DevSecOps innovation. At the same time, we’ll be removing some deprecated features from GitLab. Here is what you need to know about these breaking changes and how you can mitigate their impact.\n\n## Deployment windows\n\n### GitLab.com\n\nBreaking changes for GitLab.com will be limited to these three windows.\n\n- April 21-23, 2025\n- April 28-30, 2025\n- May 5-7, 2025\n\nMany other changes will continue to roll out throughout the month. You can learn more about the high-impact changes occurring within each of these windows in this [breaking changes documentation](https://docs.gitlab.com/update/breaking_windows/).\n\n***Note:** Breaking changes may fall slightly outside of these windows in exceptional circumstances.*\n\n### GitLab Self-Managed\n\nGitLab 18.0 will be available starting on May 15. You can learn more about the release schedule [here](/releases/whats-new/).\n\n### GitLab Dedicated\n\nThe upgrade to GitLab 18.0 will take place during your maintenance window from June 24-29, 2025. You can learn more and find your assigned maintenance window [here](https://docs.gitlab.com/administration/dedicated/maintenance/#release-rollout-schedule).\n\nWe’ve also developed custom tooling and resources to help you assess the impact of these changes on your environment and plan any necessary actions ahead of the 18.0 upgrade. You can find [information about these mitigation tools and resources](#tools-and-resources-to-manage-your-impact).\n\nVisit the [Deprecations page](https://docs.gitlab.com/ee/update/deprecations?removal_milestone=18.0) to see a full list of items scheduled for removal in 18.0. Read on to learn what’s coming and how to prepare for this year’s release based on your specific deployment.\n\n## Breaking changes\n\n### High impact\n\n**1. CI/CD job token - “Limit access from your project” setting removal**\n\nGitLab.com | Self-Managed | Dedicated\n\nIn GitLab 14.4, we introduced a setting to **[limit access *from* your project's CI/CD job tokens (CI_JOB_TOKEN)](https://docs.gitlab.com/ci/jobs/ci_job_token/#limit-your-projects-job-token-access)** for added security. This setting was called **Limit CI_JOB_TOKEN access**. In GitLab 16.3, we renamed this setting **Limit access *from* this project** for clarity.\n\nIn GitLab 15.9, we introduced an alternative setting called **[Authorized groups and projects](https://docs.gitlab.com/ci/jobs/ci_job_token/#add-a-group-or-project-to-the-job-token-allowlist)**. This setting controls job token access to your project by using an allowlist. This new setting is a significant improvement over the original. The first iteration was deprecated in GitLab 16.0 and scheduled for removal in GitLab 18.0.\n\nThe **Limit access *from* this project** setting is disabled by default for all new projects. In GitLab 16.0 and later, you cannot re-enable this setting after it is disabled in any project. Instead, use the **Authorized groups and projects** setting to control job token access to your projects.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#cicd-job-token---limit-access-from-your-project-setting-removal)\n- [GitLab Detective check available](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md)\n\n**2. CI/CD job token - Authorized groups and projects allowlist enforcement**\n\nGitLab.com | Self-Managed | Dedicated\n\nWith the **[Authorized groups and projects setting](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#add-a-group-or-project-to-the-job-token-allowlist)** introduced in GitLab 15.9 (renamed from **Limit access to this project** in GitLab 16.3), you can manage CI/CD job token access to your project. When set to **Only this project and any groups and projects in the allowlist**, only groups or projects added to the allowlist can use job tokens to access your project.\n\n* **Prior to GitLab 15.9**, the allowlist was disabled by default ([**All groups and projects**](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#allow-any-project-to-access-your-project) access setting selected), allowing job token access from any project.\n* **Since GitLab 17.6**, administrators for GitLab Self-Managed and Dedicated instances have had the option to [**enforce a more secure setting for all projects**](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#job-token-permissions), which prevents project maintainers from selecting **All groups and projects**. This change ensures a higher level of security between projects.\n* In GitLab 18.0, this setting will be enabled by default. On GitLab.com, we will automatically populate your projects’ allowlists based on your project authentication logs.\n* To prepare for this change on **GitLab.com**, project maintainers using the job token for cross-project authentication should populate their project's **Authorized groups and projects** allowlists. They should then change the setting to **Only** **this project and any groups and projects in the allowlist**. We encourage the use of available [migration tooling](https://docs.gitlab.com/ci/jobs/ci_job_token/#auto-populate-a-projects-allowlist) to ***automate*** the creation of the allowlist based on the project’s [authentication logs](https://docs.gitlab.com/ci/jobs/ci_job_token/#job-token-authentication-log) prior to GitLab 18.0.\n* **Self-Managed users** should populate the allowlists before completing the 18.0 upgrade.\n* **Dedicated users** should work with their GitLab account team to develop the appropriate strategy for their specific instance.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#cicd-job-token---authorized-groups-and-projects-allowlist-enforcement)\n- [Documentation](https://docs.gitlab.com/ci/jobs/ci_job_token/#add-a-gr)\n- [GitLab Detective check available](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md)\n\n**3. Dependency Proxy token scope enforcement**\n\nGitLab.com | Self-Managed | Dedicated\n\nThe Dependency Proxy for containers accepts **`docker login`** and **`docker pull`** requests using **personal, project,** or **group** access tokens without validating their scopes.\n\nIn GitLab 18.0, the Dependency Proxy will require both **`read_registry`** and **`write_registry`** scopes for authentication. After this change, authentication attempts using tokens without these scopes will be **rejected**.\n\nBefore upgrading, create new access tokens with the [**required scopes**](https://docs.gitlab.com/ee/user/packages/dependency_proxy/#authenticate-with-the-dependency-proxy-for-container-images), and update your workflow variables and scripts with these new tokens.\n\nYou also have the option to use [**Dependency Token Checker**](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/dependancy-token-checker/), a community-developed script that allows you to view tokens and rotate them automatically.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#dependency-proxy-token-scope-enforcement)\n\n### Medium impact\n\n**1. New data retention limits for vulnerabilities on GitLab.com**\n\nGitLab.com - **Ultimate tier customers only**\n\nStarting in GitLab 18.1 with a phased six-month rollout, we will be introducing a **new data retention limit** for GitLab.com **Ultimate** customers to improve system performance and reliability. The data retention limit affects how long your vulnerability data is stored.\n\nVulnerabilities older than 12 months that have not been updated will be automatically moved to cold storage archives. These archives:\n\n* Remain accessible and downloadable through the GitLab UI\n* Are retained for 3 years\n* Are permanently deleted after 3 years\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#new-data-retention-limits-for-vulnerabilities-on-gitlabcom)\n- [Documentation](https://handbook.gitlab.com/handbook/security/records-retention-deletion/)\n\n**2. Reject container image pull policies not in `allowed_pull_policies`**\n\nGitLab.com | Self-Managed | Dedicated\n\nAll configured pull policies should be present in the [**allowed_pull_policies configuration**](https://docs.gitlab.com/runner/executors/docker/#allow-docker-pull-policies) specified in the runner's **`config.toml`** file. If they are not, the job should fail with an **`incompatible pull policy`** error.\n\nIn the current implementation, when multiple pull policies are defined, jobs pass if at least one pull policy matches those in **`allowed-pull-policies`**, even if other policies are not included.\n\nIn GitLab 18.0, jobs will fail only if none of the pull policies match those in **`allowed-pull-policies`**. However, unlike past behavior, jobs will use only the pull policies listed in **`allowed-pull-policies`**. This distinction can cause jobs that currently pass to fail in GitLab 18.0.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#reject-container-image-pull-policies-not-in-allowed_pull_policies)\n- [Documentation](https://docs.gitlab.com/runner/executors/docker/#allow-docker-pull-policies)\n\n**3. PostgreSQL 14 and 15 no longer supported**\n\nSelf-Managed\n\nGitLab follows an [**annual upgrade cadence for PostgreSQL**](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/data-access/database-framework/postgresql-upgrade-cadence/).\n\nSupport for PostgreSQL 14 and 15 is scheduled for removal in GitLab 18.0. In GitLab 18.0, PostgreSQL 16 becomes the minimum required version of PostgreSQL.\n\nPostgreSQL 14 and 15 will be supported for the full GitLab 17 release cycle. PostgreSQL 16 will also be supported for instances that want to upgrade prior to GitLab 18.0.\n\nTo prepare for this change on instances that don't use [**PostgreSQL Cluster**](https://docs.gitlab.com/administration/postgresql/replication_and_failover/) (for example, if you are running a single PostgreSQL instance you installed with an Omnibus Linux package), upgrades to GitLab 17.11 will attempt to automatically upgrade PostgreSQL to Version 16. If you use [**PostgreSQL Cluster**](https://docs.gitlab.com/administration/postgresql/replication_and_failover/) or [**opt out of this automated upgrade**](https://docs.gitlab.com/omnibus/settings/database/#opt-out-of-automatic-postgresql-upgrades), you must [**manually upgrade to PostgreSQL 16**](https://docs.gitlab.com/omnibus/settings/database/#upgrade-packaged-postgresql-server) to be able to upgrade to GitLab 18.0. Make sure you have sufficient disk space to accommodate the upgrade.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#postgresql-14-and-15-no-longer-supported)\n- [Documentation](https://docs.gitlab.com/omnibus/settings/database/#upgrade-packaged-postgresql-server)\n- [Migration guidelines](https://docs.gitlab.com/omnibus/development/managing-postgresql-versions/)\n\n**4. Deprecate the Terraform CI/CD templates**\n\nSelf-Managed\n\nThe Terraform CI/CD templates are deprecated and will be removed in GitLab 18.0. This affects the following templates:\n\n* `Terraform.gitlab-ci.yml`\n* `Terraform.latest.gitlab-ci.yml`\n* `Terraform/Base.gitlab-ci.yml`\n* `Terraform/Base.latest.gitlab-ci.yml`\n\nGitLab won't be able to update the **`terraform`** binary in the job images to any version that is licensed under the BSL.\n\nTo continue using Terraform, clone the templates and [**Terraform image**](https://gitlab.com/gitlab-org/terraform-images), and maintain them as needed. GitLab provides [**detailed instructions**](https://gitlab.com/gitlab-org/terraform-images) for migrating to a custom-built image.\n\n**As an alternative, we recommend using the new OpenTofu CI/CD component on GitLab.com or the new OpenTofu CI/CD template on GitLab Self-Managed.** CI/CD components are not yet available on GitLab Self-Managed, however, [**Issue #415638**](https://gitlab.com/gitlab-org/gitlab/-/issues/415638) proposes adding this feature. If CI/CD components become available on GitLab Self-Managed, the OpenTofu CI/CD template will be removed.\n\nRead more about the new [OpenTofu CI/CD component](https://gitlab.com/components/opentofu).\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#deprecate-terraform-cicd-templates)\n\n**5. Major update of the Prometheus subchart**\n\nSelf-Managed\n\nWith GitLab 18.0 and GitLab chart 9.0, the Prometheus subchart will be updated from 15.3 to 27.3.\n\nAlong with this update, Prometheus 3 will be shipped by default.\n\nManual steps are required to perform the upgrade. If you have Alertmanager, Node Exporter, or Pushgateway enabled, you will also need to update your Helm values.\n\nPlease refer to the [**migration guide**](https://docs.gitlab.com/charts/releases/9_0/#prometheus-upgrade) for more information.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#major-update-of-the-prometheus-subchart)\n\n### Low impact\n\n**1. No longer building SUSE Linux Enterprise Server 15 SP2 packages**\n\nSelf-Managed\n\nLong-term service and support (LTSS) for SUSE Linux Enterprise Server (SLES) 15 SP2 ended in December 2024.\n\nTherefore, we will no longer support the SLES SP2 distribution for Linux package installs. You should upgrade to SLES 15 SP6 for continued support.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#support-for-suse-linux-enterprise-server-15-sp2)\n\n**2. Remove Gitaly rate limiter**\n\nSelf-Managed\n\nGitaly used to support [**RPC-based rate limiting**](https://gitlab.com/gitlab-org/gitaly/-/blob/4b7ea24f6172a03e7989879200b47b6fd0e2d059/doc/backpressure.md#L55-55). We are deprecating this feature as it does not achieve the desired results. Please see the deprecation issue for details.\n\nIf customers have the rate limiter configured (which is being deprecated), no error will be returned and the config will simply be ignored.\n\nCustomers should utilize the [**Concurrency Limiter**](https://docs.gitlab.com/administration/gitaly/concurrency_limiting/) instead.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#gitaly-rate-limiting)\n\n**3. Deprecate NGINX controller image 1.3.1 support**\n\nSelf-Managed\n\nWe're upgrading the default NGINX controller image to 1.11.2. This new version requires new RBAC rules and some users set **nginx-ingress.rbac.create: false** to manage their own RBAC rules.\n\nThese users will need to add the RBAC rules before migrating to 1.11.2 or later. We added a fallback mechanism to only deploy 1.3.1 if this Helm value is set as above. We've also added **nginx-ingress.controller.image.disableFallback**, which defaults to false. Users who manage their own RBAC can set this to true to enable their deployments to also use 1.11.2, after ensuring the new RBAC rules are in place.\n\nWe plan to deprecate the 1.3.1 image support as well as the fallback mechanism as part of 17.5, so that we can remove this support completely and use only 1.11.2, which offers numerous security benefits.\n\n[Deprecation notice](https://docs.gitlab.com/update/deprecations/#fallback-support-for-gitlab-nginx-chart-controller-image-v131)\n\n**4. Application Security Testing analyzers major version update**\n\nGitLab.com | Self-Managed | Dedicated\n\nThe Application Security Testing stage will be bumping the major versions of its analyzers in tandem with the GitLab 18.0 release.\n\nIf you are not using the default included templates, or have pinned your analyzer versions, you must update your CI/CD job definition to either remove the pinned version or update the latest major version.\n\nUsers of GitLab 17.0-17.11 will continue to experience analyzer updates as normal until the release of GitLab 18.0. After GitLab 18.0, all newly fixed bugs and features will be released only in the new major version of the analyzers.\n\nWe do not backport bugs and features to deprecated versions as per our maintenance policy. As required, security patches will be backported to the latest three minor releases.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#application-security-testing-analyzers-major-version-update)\n\n**5. API Discovery will use branch pipelines by default**\n\nGitLab.com | Self-Managed | Dedicated\n\nIn GitLab 18.0, we'll update the default behavior of the CI/CD template for API Discovery (**API-Discovery.gitlab-ci.yml**).\n\nBefore GitLab 18.0, this template configures jobs to run in [**merge request pipelines**](https://docs.gitlab.com/ci/pipelines/merge_request_pipelines/) by default when an MR is open.\n\nStarting in GitLab 18.0, we'll align this template's behavior with the behavior of the [**Stable template editions**](https://docs.gitlab.com/user/application_security/detect/roll_out_security_scanning/#template-editions) for other AST scanners:\n\n* By default, the template will run scan jobs in branch pipelines.\n* You'll be able to set the CI/CD variable **AST_ENABLE_MR_PIPELINES: true** to use MR pipelines instead when an MR is open. The implementation of this new variable is tracked in [**Issue #410880**](https://gitlab.com/gitlab-org/gitlab/-/issues/410880).\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#api-discovery-will-use-branch-pipelines-by-default)\n\n**6. DAST DAST_DEVTOOLS_API_TIMEOUT will have a lower default value**\n\nGitLab.com | Self-Managed | Dedicated\n\nThe **DAST_DEVTOOLS_API_TIMEOUT** environment variable determines how long a DAST scan waits for a response from the browser. Before GitLab 18.0, the variable has a static value of 45 seconds. After GitLab 18.0, **DAST_DEVTOOLS_API_TIMEOUT** environment variable has a dynamic value, which is calculated based on other timeout configurations.\n\nIn most cases, the 45-second value was higher than the timeout value of many scanner functions. The dynamically calculated value makes the __DAST_DEVTOOLS_API_TIMEOUT__ variable more useful by increasing the number of cases to which it applies.\n\n- [Deprecation notice](https://docs.gitlab.com/update/deprecations/#dast-dast_devtools_api_timeout-will-have-a-lower-default-value)\n\n## Tools and resources to manage your impact\n\nWe’ve developed specific tooling to help our customers understand how these planned changes impact their GitLab instance(s). Once you’ve assessed your impact, we recommend reviewing the mitigation steps provided in the documentation to ensure a smooth transition to GitLab 18.0.\n\n* [Advanced Search Deprecations](https://gitlab.com/gitlab-com/cs-tools/gitlab-cs-tools/deprecation-migration-tools/advanced-search-deprecations): This tool uses GitLab's Advanced Search API to find strings related to deprecations across GitLab groups and projects. It also reports which files should be manually checked. *__Note:__ May have some false positives.*\n* [Dependency Scanning Build Support Detection Helper](https://gitlab.com/security-products/tooling/build-support-detection-helper): This tool identifies projects impacted by three Dependency Scanning deprecations ([1](https://docs.gitlab.com/update/deprecations/#dependency-scanning-for-javascript-vendored-libraries), [2](https://docs.gitlab.com/update/deprecations/#dependency-scanning-upgrades-to-the-gitlab-sbom-vulnerability-scanner), [3](https://docs.gitlab.com/update/deprecations/#resolve-a-vulnerability-for-dependency-scanning-on-yarn-projects); all postponed to 19.0). It uses API to scan for relevant files and CI job names.\n* [GitLab Detective](https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective/-/blob/main/README.md) (Self-Managed only): This experimental tool automatically checks a GitLab installation for known issues. It completes complex checks by looking at config files or database values. **Note:** Needs to run directly on your GitLab nodes.\n\nWe’ve also launched a series of micro courses (15 minutes or less!) on GitLab University to help you plan and execute mitigation activities for several of these changes. [Start your learning journey here](https://university.gitlab.com/catalog?query=18.0).\n\nIf you have a paid plan and have questions or require assistance with these changes, please [open a support ticket](https://support.gitlab.com/hc/en-us/articles/11626501035292-Support-Portal-User-Guide) on the GitLab Support Portal.\n\nIf you are a [free Gitlab.com user](https://support.gitlab.com/hc/en-us/articles/11625911285404-Statement-of-Support#free-users), you can access additional support through community sources, such as [GitLab Documentation](https://docs.gitlab.com/), [GitLab Community Forum](https://forum.gitlab.com/), and [Stack Overflow](http://stackoverflow.com/questions/tagged/gitlab).\n",[11,27],"DevSecOps platform","yml",{},true,"/en-us/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0",{"title":17,"description":18,"ogTitle":17,"ogDescription":18,"noIndex":14,"ogImage":23,"ogUrl":33,"ogSiteName":34,"ogType":35,"canonicalUrls":33},"https://about.gitlab.com/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0","https://about.gitlab.com","article","en-us/blog/a-guide-to-the-breaking-changes-in-gitlab-18-0",[11,38],"devsecops-platform","K3KwLgeqHe6pdk3sG0Bxoc0z0Cdf7KJ0_PcetVozWI0",{"data":41},{"logo":42,"freeTrial":47,"sales":52,"login":57,"items":62,"search":370,"minimal":401,"duo":420,"switchNav":429,"pricingDeployment":440},{"config":43},{"href":44,"dataGaName":45,"dataGaLocation":46},"/","gitlab logo","header",{"text":48,"config":49},"Get free trial",{"href":50,"dataGaName":51,"dataGaLocation":46},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":53,"config":54},"Talk to sales",{"href":55,"dataGaName":56,"dataGaLocation":46},"/sales/","sales",{"text":58,"config":59},"Sign in",{"href":60,"dataGaName":61,"dataGaLocation":46},"https://gitlab.com/users/sign_in/","sign in",[63,90,185,190,291,351],{"text":64,"config":65,"cards":67},"Platform",{"dataNavLevelOne":66},"platform",[68,74,82],{"title":64,"description":69,"link":70},"The intelligent orchestration platform for DevSecOps",{"text":71,"config":72},"Explore our Platform",{"href":73,"dataGaName":66,"dataGaLocation":46},"/platform/",{"title":75,"description":76,"link":77},"GitLab Duo Agent Platform","Agentic AI for the entire software lifecycle",{"text":78,"config":79},"Meet GitLab Duo",{"href":80,"dataGaName":81,"dataGaLocation":46},"/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":83,"description":84,"link":85},"Why GitLab","See the top reasons enterprises choose GitLab",{"text":86,"config":87},"Learn more",{"href":88,"dataGaName":89,"dataGaLocation":46},"/why-gitlab/","why gitlab",{"text":91,"left":30,"config":92,"link":94,"lists":98,"footer":167},"Product",{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"View all Solutions",{"href":97,"dataGaName":93,"dataGaLocation":46},"/solutions/",[99,123,146],{"title":100,"description":101,"link":102,"items":107},"Automation","CI/CD and automation to accelerate deployment",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":46},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[108,112,115,119],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":46,"dataGaName":109},"/solutions/continuous-integration/",{"text":75,"config":113},{"href":80,"dataGaLocation":46,"dataGaName":114},"gitlab duo agent platform - product menu",{"text":116,"config":117},"Source Code Management",{"href":118,"dataGaLocation":46,"dataGaName":116},"/solutions/source-code-management/",{"text":120,"config":121},"Automated Software Delivery",{"href":105,"dataGaLocation":46,"dataGaName":122},"Automated software delivery",{"title":124,"description":125,"link":126,"items":131},"Security","Deliver code faster without compromising security",{"config":127},{"href":128,"dataGaName":129,"dataGaLocation":46,"icon":130},"/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[132,136,141],{"text":133,"config":134},"Application Security Testing",{"href":128,"dataGaName":135,"dataGaLocation":46},"Application security testing",{"text":137,"config":138},"Software Supply Chain Security",{"href":139,"dataGaLocation":46,"dataGaName":140},"/solutions/supply-chain/","Software supply chain security",{"text":142,"config":143},"Software Compliance",{"href":144,"dataGaName":145,"dataGaLocation":46},"/solutions/software-compliance/","software compliance",{"title":147,"link":148,"items":153},"Measurement",{"config":149},{"icon":150,"href":151,"dataGaName":152,"dataGaLocation":46},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[154,158,162],{"text":155,"config":156},"Visibility & Measurement",{"href":151,"dataGaLocation":46,"dataGaName":157},"Visibility and Measurement",{"text":159,"config":160},"Value Stream Management",{"href":161,"dataGaLocation":46,"dataGaName":159},"/solutions/value-stream-management/",{"text":163,"config":164},"Analytics & Insights",{"href":165,"dataGaLocation":46,"dataGaName":166},"/solutions/analytics-and-insights/","Analytics and insights",{"title":168,"items":169},"GitLab for",[170,175,180],{"text":171,"config":172},"Enterprise",{"href":173,"dataGaLocation":46,"dataGaName":174},"/enterprise/","enterprise",{"text":176,"config":177},"Small Business",{"href":178,"dataGaLocation":46,"dataGaName":179},"/small-business/","small business",{"text":181,"config":182},"Public Sector",{"href":183,"dataGaLocation":46,"dataGaName":184},"/solutions/public-sector/","public sector",{"text":186,"config":187},"Pricing",{"href":188,"dataGaName":189,"dataGaLocation":46,"dataNavLevelOne":189},"/pricing/","pricing",{"text":191,"config":192,"link":194,"lists":198,"feature":278},"Resources",{"dataNavLevelOne":193},"resources",{"text":195,"config":196},"View all resources",{"href":197,"dataGaName":193,"dataGaLocation":46},"/resources/",[199,232,250],{"title":200,"items":201},"Getting started",[202,207,212,217,222,227],{"text":203,"config":204},"Install",{"href":205,"dataGaName":206,"dataGaLocation":46},"/install/","install",{"text":208,"config":209},"Quick start guides",{"href":210,"dataGaName":211,"dataGaLocation":46},"/get-started/","quick setup checklists",{"text":213,"config":214},"Learn",{"href":215,"dataGaLocation":46,"dataGaName":216},"https://university.gitlab.com/","learn",{"text":218,"config":219},"Product documentation",{"href":220,"dataGaName":221,"dataGaLocation":46},"https://docs.gitlab.com/","product documentation",{"text":223,"config":224},"Best practice videos",{"href":225,"dataGaName":226,"dataGaLocation":46},"/getting-started-videos/","best practice videos",{"text":228,"config":229},"Integrations",{"href":230,"dataGaName":231,"dataGaLocation":46},"/integrations/","integrations",{"title":233,"items":234},"Discover",[235,240,245],{"text":236,"config":237},"Customer success stories",{"href":238,"dataGaName":239,"dataGaLocation":46},"/customers/","customer success stories",{"text":241,"config":242},"Blog",{"href":243,"dataGaName":244,"dataGaLocation":46},"/blog/","blog",{"text":246,"config":247},"Remote",{"href":248,"dataGaName":249,"dataGaLocation":46},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":251,"items":252},"Connect",[253,258,263,268,273],{"text":254,"config":255},"GitLab Services",{"href":256,"dataGaName":257,"dataGaLocation":46},"/services/","services",{"text":259,"config":260},"Community",{"href":261,"dataGaName":262,"dataGaLocation":46},"/community/","community",{"text":264,"config":265},"Forum",{"href":266,"dataGaName":267,"dataGaLocation":46},"https://forum.gitlab.com/","forum",{"text":269,"config":270},"Events",{"href":271,"dataGaName":272,"dataGaLocation":46},"/events/","events",{"text":274,"config":275},"Partners",{"href":276,"dataGaName":277,"dataGaLocation":46},"/partners/","partners",{"backgroundColor":279,"textColor":280,"text":281,"image":282,"link":286},"#2f2a6b","#fff","Insights for the future of software development",{"altText":283,"config":284},"the source promo card",{"src":285},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":287,"config":288},"Read the latest",{"href":289,"dataGaName":290,"dataGaLocation":46},"/the-source/","the source",{"text":292,"config":293,"lists":295},"Company",{"dataNavLevelOne":294},"company",[296],{"items":297},[298,303,309,311,316,321,326,331,336,341,346],{"text":299,"config":300},"About",{"href":301,"dataGaName":302,"dataGaLocation":46},"/company/","about",{"text":304,"config":305,"footerGa":308},"Jobs",{"href":306,"dataGaName":307,"dataGaLocation":46},"/jobs/","jobs",{"dataGaName":307},{"text":269,"config":310},{"href":271,"dataGaName":272,"dataGaLocation":46},{"text":312,"config":313},"Leadership",{"href":314,"dataGaName":315,"dataGaLocation":46},"/company/team/e-group/","leadership",{"text":317,"config":318},"Team",{"href":319,"dataGaName":320,"dataGaLocation":46},"/company/team/","team",{"text":322,"config":323},"Handbook",{"href":324,"dataGaName":325,"dataGaLocation":46},"https://handbook.gitlab.com/","handbook",{"text":327,"config":328},"Investor relations",{"href":329,"dataGaName":330,"dataGaLocation":46},"https://ir.gitlab.com/","investor relations",{"text":332,"config":333},"Trust Center",{"href":334,"dataGaName":335,"dataGaLocation":46},"/security/","trust center",{"text":337,"config":338},"AI Transparency Center",{"href":339,"dataGaName":340,"dataGaLocation":46},"/ai-transparency-center/","ai transparency center",{"text":342,"config":343},"Newsletter",{"href":344,"dataGaName":345,"dataGaLocation":46},"/company/contact/#contact-forms","newsletter",{"text":347,"config":348},"Press",{"href":349,"dataGaName":350,"dataGaLocation":46},"/press/","press",{"text":352,"config":353,"lists":354},"Contact us",{"dataNavLevelOne":294},[355],{"items":356},[357,360,365],{"text":53,"config":358},{"href":55,"dataGaName":359,"dataGaLocation":46},"talk to sales",{"text":361,"config":362},"Support portal",{"href":363,"dataGaName":364,"dataGaLocation":46},"https://support.gitlab.com","support portal",{"text":366,"config":367},"Customer portal",{"href":368,"dataGaName":369,"dataGaLocation":46},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":371,"login":372,"suggestions":379},"Close",{"text":373,"link":374},"To search repositories and projects, login to",{"text":375,"config":376},"gitlab.com",{"href":60,"dataGaName":377,"dataGaLocation":378},"search login","search",{"text":380,"default":381},"Suggestions",[382,384,388,390,394,398],{"text":75,"config":383},{"href":80,"dataGaName":75,"dataGaLocation":378},{"text":385,"config":386},"Code Suggestions (AI)",{"href":387,"dataGaName":385,"dataGaLocation":378},"/solutions/code-suggestions/",{"text":109,"config":389},{"href":111,"dataGaName":109,"dataGaLocation":378},{"text":391,"config":392},"GitLab on AWS",{"href":393,"dataGaName":391,"dataGaLocation":378},"/partners/technology-partners/aws/",{"text":395,"config":396},"GitLab on Google Cloud",{"href":397,"dataGaName":395,"dataGaLocation":378},"/partners/technology-partners/google-cloud-platform/",{"text":399,"config":400},"Why GitLab?",{"href":88,"dataGaName":399,"dataGaLocation":378},{"freeTrial":402,"mobileIcon":407,"desktopIcon":412,"secondaryButton":415},{"text":403,"config":404},"Start free trial",{"href":405,"dataGaName":51,"dataGaLocation":406},"https://gitlab.com/-/trials/new/","nav",{"altText":408,"config":409},"Gitlab Icon",{"src":410,"dataGaName":411,"dataGaLocation":406},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":408,"config":413},{"src":414,"dataGaName":411,"dataGaLocation":406},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":416,"config":417},"Get Started",{"href":418,"dataGaName":419,"dataGaLocation":406},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/get-started/","get started",{"freeTrial":421,"mobileIcon":425,"desktopIcon":427},{"text":422,"config":423},"Learn more about GitLab Duo",{"href":80,"dataGaName":424,"dataGaLocation":406},"gitlab duo",{"altText":408,"config":426},{"src":410,"dataGaName":411,"dataGaLocation":406},{"altText":408,"config":428},{"src":414,"dataGaName":411,"dataGaLocation":406},{"button":430,"mobileIcon":435,"desktopIcon":437},{"text":431,"config":432},"/switch",{"href":433,"dataGaName":434,"dataGaLocation":406},"#contact","switch",{"altText":408,"config":436},{"src":410,"dataGaName":411,"dataGaLocation":406},{"altText":408,"config":438},{"src":439,"dataGaName":411,"dataGaLocation":406},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":441,"mobileIcon":446,"desktopIcon":448},{"text":442,"config":443},"Back to pricing",{"href":188,"dataGaName":444,"dataGaLocation":406,"icon":445},"back to pricing","GoBack",{"altText":408,"config":447},{"src":410,"dataGaName":411,"dataGaLocation":406},{"altText":408,"config":449},{"src":414,"dataGaName":411,"dataGaLocation":406},{"title":451,"button":452,"config":457},"See how agentic AI transforms software delivery",{"text":453,"config":454},"Watch GitLab Transcend now",{"href":455,"dataGaName":456,"dataGaLocation":46},"/events/transcend/virtual/","transcend event",{"layout":458,"icon":459,"disabled":30},"release","AiStar",{"data":461},{"text":462,"source":463,"edit":469,"contribute":474,"config":479,"items":484,"minimal":690},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":464,"config":465},"View page source",{"href":466,"dataGaName":467,"dataGaLocation":468},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":470,"config":471},"Edit this page",{"href":472,"dataGaName":473,"dataGaLocation":468},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":475,"config":476},"Please contribute",{"href":477,"dataGaName":478,"dataGaLocation":468},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":480,"facebook":481,"youtube":482,"linkedin":483},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[485,532,585,629,656],{"title":186,"links":486,"subMenu":501},[487,491,496],{"text":488,"config":489},"View plans",{"href":188,"dataGaName":490,"dataGaLocation":468},"view plans",{"text":492,"config":493},"Why Premium?",{"href":494,"dataGaName":495,"dataGaLocation":468},"/pricing/premium/","why premium",{"text":497,"config":498},"Why Ultimate?",{"href":499,"dataGaName":500,"dataGaLocation":468},"/pricing/ultimate/","why ultimate",[502],{"title":503,"links":504},"Contact Us",[505,508,510,512,517,522,527],{"text":506,"config":507},"Contact sales",{"href":55,"dataGaName":56,"dataGaLocation":468},{"text":361,"config":509},{"href":363,"dataGaName":364,"dataGaLocation":468},{"text":366,"config":511},{"href":368,"dataGaName":369,"dataGaLocation":468},{"text":513,"config":514},"Status",{"href":515,"dataGaName":516,"dataGaLocation":468},"https://status.gitlab.com/","status",{"text":518,"config":519},"Terms of use",{"href":520,"dataGaName":521,"dataGaLocation":468},"/terms/","terms of use",{"text":523,"config":524},"Privacy statement",{"href":525,"dataGaName":526,"dataGaLocation":468},"/privacy/","privacy statement",{"text":528,"config":529},"Cookie preferences",{"dataGaName":530,"dataGaLocation":468,"id":531,"isOneTrustButton":30},"cookie preferences","ot-sdk-btn",{"title":91,"links":533,"subMenu":541},[534,537],{"text":27,"config":535},{"href":73,"dataGaName":536,"dataGaLocation":468},"devsecops platform",{"text":538,"config":539},"AI-Assisted Development",{"href":80,"dataGaName":540,"dataGaLocation":468},"ai-assisted development",[542],{"title":543,"links":544},"Topics",[545,550,555,560,565,570,575,580],{"text":546,"config":547},"CICD",{"href":548,"dataGaName":549,"dataGaLocation":468},"/topics/ci-cd/","cicd",{"text":551,"config":552},"GitOps",{"href":553,"dataGaName":554,"dataGaLocation":468},"/topics/gitops/","gitops",{"text":556,"config":557},"DevOps",{"href":558,"dataGaName":559,"dataGaLocation":468},"/topics/devops/","devops",{"text":561,"config":562},"Version Control",{"href":563,"dataGaName":564,"dataGaLocation":468},"/topics/version-control/","version control",{"text":566,"config":567},"DevSecOps",{"href":568,"dataGaName":569,"dataGaLocation":468},"/topics/devsecops/","devsecops",{"text":571,"config":572},"Cloud Native",{"href":573,"dataGaName":574,"dataGaLocation":468},"/topics/cloud-native/","cloud native",{"text":576,"config":577},"AI for Coding",{"href":578,"dataGaName":579,"dataGaLocation":468},"/topics/devops/ai-for-coding/","ai for coding",{"text":581,"config":582},"Agentic AI",{"href":583,"dataGaName":584,"dataGaLocation":468},"/topics/agentic-ai/","agentic ai",{"title":586,"links":587},"Solutions",[588,590,592,597,601,604,608,611,613,616,619,624],{"text":133,"config":589},{"href":128,"dataGaName":133,"dataGaLocation":468},{"text":122,"config":591},{"href":105,"dataGaName":106,"dataGaLocation":468},{"text":593,"config":594},"Agile development",{"href":595,"dataGaName":596,"dataGaLocation":468},"/solutions/agile-delivery/","agile delivery",{"text":598,"config":599},"SCM",{"href":118,"dataGaName":600,"dataGaLocation":468},"source code management",{"text":546,"config":602},{"href":111,"dataGaName":603,"dataGaLocation":468},"continuous integration & delivery",{"text":605,"config":606},"Value stream management",{"href":161,"dataGaName":607,"dataGaLocation":468},"value stream management",{"text":551,"config":609},{"href":610,"dataGaName":554,"dataGaLocation":468},"/solutions/gitops/",{"text":171,"config":612},{"href":173,"dataGaName":174,"dataGaLocation":468},{"text":614,"config":615},"Small business",{"href":178,"dataGaName":179,"dataGaLocation":468},{"text":617,"config":618},"Public sector",{"href":183,"dataGaName":184,"dataGaLocation":468},{"text":620,"config":621},"Education",{"href":622,"dataGaName":623,"dataGaLocation":468},"/solutions/education/","education",{"text":625,"config":626},"Financial services",{"href":627,"dataGaName":628,"dataGaLocation":468},"/solutions/finance/","financial services",{"title":191,"links":630},[631,633,635,637,640,642,644,646,648,650,652,654],{"text":203,"config":632},{"href":205,"dataGaName":206,"dataGaLocation":468},{"text":208,"config":634},{"href":210,"dataGaName":211,"dataGaLocation":468},{"text":213,"config":636},{"href":215,"dataGaName":216,"dataGaLocation":468},{"text":218,"config":638},{"href":220,"dataGaName":639,"dataGaLocation":468},"docs",{"text":241,"config":641},{"href":243,"dataGaName":244,"dataGaLocation":468},{"text":236,"config":643},{"href":238,"dataGaName":239,"dataGaLocation":468},{"text":246,"config":645},{"href":248,"dataGaName":249,"dataGaLocation":468},{"text":254,"config":647},{"href":256,"dataGaName":257,"dataGaLocation":468},{"text":259,"config":649},{"href":261,"dataGaName":262,"dataGaLocation":468},{"text":264,"config":651},{"href":266,"dataGaName":267,"dataGaLocation":468},{"text":269,"config":653},{"href":271,"dataGaName":272,"dataGaLocation":468},{"text":274,"config":655},{"href":276,"dataGaName":277,"dataGaLocation":468},{"title":292,"links":657},[658,660,662,664,666,668,670,674,679,681,683,685],{"text":299,"config":659},{"href":301,"dataGaName":294,"dataGaLocation":468},{"text":304,"config":661},{"href":306,"dataGaName":307,"dataGaLocation":468},{"text":312,"config":663},{"href":314,"dataGaName":315,"dataGaLocation":468},{"text":317,"config":665},{"href":319,"dataGaName":320,"dataGaLocation":468},{"text":322,"config":667},{"href":324,"dataGaName":325,"dataGaLocation":468},{"text":327,"config":669},{"href":329,"dataGaName":330,"dataGaLocation":468},{"text":671,"config":672},"Sustainability",{"href":673,"dataGaName":671,"dataGaLocation":468},"/sustainability/",{"text":675,"config":676},"Diversity, inclusion and belonging (DIB)",{"href":677,"dataGaName":678,"dataGaLocation":468},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":332,"config":680},{"href":334,"dataGaName":335,"dataGaLocation":468},{"text":342,"config":682},{"href":344,"dataGaName":345,"dataGaLocation":468},{"text":347,"config":684},{"href":349,"dataGaName":350,"dataGaLocation":468},{"text":686,"config":687},"Modern Slavery Transparency Statement",{"href":688,"dataGaName":689,"dataGaLocation":468},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":691},[692,695,698],{"text":693,"config":694},"Terms",{"href":520,"dataGaName":521,"dataGaLocation":468},{"text":696,"config":697},"Cookies",{"dataGaName":530,"dataGaLocation":468,"id":531,"isOneTrustButton":30},{"text":699,"config":700},"Privacy",{"href":525,"dataGaName":526,"dataGaLocation":468},[702,716,728],{"id":703,"title":704,"body":10,"config":705,"content":707,"description":10,"extension":28,"meta":711,"navigation":30,"path":712,"seo":713,"stem":714,"__hash__":715},"blogAuthors/en-us/blog/authors/martin-brmmer.yml","Martin Brmmer",{"template":706},"BlogAuthor",{"name":20,"config":708},{"headshot":709,"ctfId":710},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659427/Blog/Author%20Headshots/martin_brummer.webp","1QkLKK0UnkvZDDBzzEhkaA",{},"/en-us/blog/authors/martin-brmmer",{},"en-us/blog/authors/martin-brmmer","5XXFf9xKfqhpm33ots964Z5lLGWP6fmjjylRLOrvUe4",{"id":717,"title":21,"body":10,"config":718,"content":719,"description":10,"extension":28,"meta":723,"navigation":30,"path":724,"seo":725,"stem":726,"__hash__":727},"blogAuthors/en-us/blog/authors/fabian-zimmer.yml",{"template":706},{"name":21,"config":720},{"headshot":721,"ctfId":722},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750713473/q6awwqbxtg0a4x9gtmhs.png","3TK88UogcX5lx83kWMVuvI",{},"/en-us/blog/authors/fabian-zimmer",{},"en-us/blog/authors/fabian-zimmer","qPVb4mKZuBff6-yly4-T5Bar6IdyXcx_tJHGlSL8QIA",{"id":729,"title":22,"body":10,"config":730,"content":731,"description":10,"extension":28,"meta":735,"navigation":30,"path":736,"seo":737,"stem":738,"__hash__":739},"blogAuthors/en-us/blog/authors/sam-wiskow.yml",{"template":706},{"name":22,"config":732},{"headshot":733,"ctfId":734},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659433/Blog/Author%20Headshots/swiskow-headshot.jpg","swiskow",{},"/en-us/blog/authors/sam-wiskow",{},"en-us/blog/authors/sam-wiskow","TR52XmFI8G3xfSF6pTXW6r_bf0Bd5tf82MmM7VjjKfM",[741,752,767],{"content":742,"config":750},{"title":743,"description":744,"heroImage":745,"date":746,"category":11,"tags":747},"GitLab Patch Release: 18.11.1, 18.10.4, 18.9.6","Discover what's in this latests patch release.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661926/Blog/Hero%20Images/security-patch-blog-image-r2-0506-700x400-fy25_2x.jpg","2026-04-22",[748,749],"patch releases","security releases",{"featured":14,"template":15,"externalUrl":751},"https://docs.gitlab.com/releases/patches/patch-release-gitlab-18-11-1-released/",{"content":753,"config":765},{"title":754,"description":755,"body":756,"category":11,"tags":757,"date":760,"authors":761,"heroImage":764},"GitLab + Amazon: Platform orchestration on a trusted AI foundation","Pair GitLab Duo Agent Platform with Amazon Bedrock for agentic software development and orchestration.","If your team runs GitLab and has a strong AWS practice, a new combination of Duo Agent Platform and Amazon Bedrock is just for you. The model is simple: GitLab acts as your orchestration layer to help accelerate your entire software lifecycle with agentic AI, and Bedrock is designed to provide a secure, compliant foundation model layer with AI inference behind the scenes.\n\nGitLab Duo Agent Platform enables you to handle planning, merge pipelines, security scanning, vulnerability remediation, and more as part of your GitLab workflows, while the GitLab AI Gateway routes model calls to Bedrock (or GitLab-managed Bedrock-backed endpoints, depending on your setup). That means you can build on the identity and access management (IAM) policies, virtual private cloud (VPC) boundaries, regional controls, and cloud spend commitments you already have in AWS.\n\nIf you already use Amazon Bedrock and want AI to help inside the work you already do in GitLab, not in yet another standalone chat tool, this is the pairing for you.\n\n\nIn this article, we look at the real problem many teams face today: AI is fragmented, data paths are fuzzy, and Bedrock investment gets underused when AI sits outside the software development lifecycle. Then we break down your deployment options for GitLab Duo Agent Platform:\n\n* Integrated with self-hosted models on Amazon Bedrock for GitLab Self-Managed deployments and self-hosted AI gateway   \n* Integrated with GitLab-operated models on Amazon Bedrock (with GitLab-owned keys) for GitLab Self-Managed deployments and GitLab-hosted AI gateway  \n* Integrated with GitLab-operated models on Amazon Bedrock (with GitLab-owned keys) for GitLab.com instances and GitLab-hosted AI gateway\n\nWe wrap with a summary on how this approach helps avoid shadow AI and point-tool sprawl without creating a parallel tech stack for AI tooling.\n\n## AI everywhere, control nowhere\n\nSomewhere in your company right now, software teams might be using an AI tool that your security team hasn't approved. Prompt data might be leaving your environment through a path no one has fully mapped. And your organization’s Amazon Bedrock investment might be underused while individual teams expense separate AI tools, pulling workloads and cloud spend away from the platforms you’ve already committed to.\n\nInstead of being a people problem, this might be an architecture problem. And it surfaces the same three constraints in nearly every enterprise:\n\n**Operational fragmentation.** Each team, or sometimes even an individual developer, picks their own development toolset, including AI tooling and model selection. That fragmentation makes end-to-end governance within the software development lifecycle nearly impossible.\n\n**Security and sovereignty.** Where does prompt and code data actually flow? Who owns the logs?\n\n**Cloud spend optimization.** Commitments to key cloud providers like AWS are diluted as workloads and AI usage drift to point tools outside of customers’ existing agreements.\n\nGitLab Duo Agent Platform and Amazon Bedrock help solve this together. The division of labor is straightforward: Duo Agent Platform owns the workflow orchestration with agentic AI for software development, Bedrock owns the inference layer and hosts approved foundational models, and your organization has full control over the data and policy boundaries you already defined in AWS. Three jobs, three owners, no fragmentation.\n\n## GitLab Duo Agent Platform: The agentic control plane\n\nGitLab Duo Agent Platform is GitLab's agentic AI layer: a framework of specialized agents and flows that operate simultaneously and in-parallel, going beyond the traditional stage-based handoffs  and helping automate work across the entire software lifecycle. Rather than a single assistant responding to prompts, Duo Agent Platform enables teams to orchestrate many AI agents asynchronously using unified data and project context, including issues, merge requests, pipelines, and security findings. Linear workflows are turned into coordinated, continuous collaboration between software teams and their AI agents, at scale.\n\nWith that control plane in place, the natural next question is which AI foundation should power these agents. For customers who run GitLab Self-Managed on AWS and need inference traffic, prompt data, and logs to also stay within their AWS environment along with their software lifecycle data, Amazon Bedrock acting as the AI inference layer is the natural fit. \n\n## Amazon Bedrock: The trusted AI foundation\n\nAmazon Bedrock is a fully managed, serverless foundation model layer that runs entirely within your AWS environment. Customer data stays in the customer's AWS account: inputs and outputs are encrypted in transit and at rest, never shared with model providers, and never used to train base models. Bedrock carries compliance certifications across GDPR, HIPAA, and FedRAMP High, covering many regulated industry requirements out of the box. Teams can also bring fine-tuned models from elsewhere via Custom Model Import and deploy them alongside native Bedrock models through the same infrastructure, without managing separate deployment pipelines. Bedrock Guardrails adds configurable safeguards across all models for content filtering, hallucination detection, and sensitive data protection.\n\nTogether, GitLab Duo Agent Platform and Bedrock consolidate DevSecOps orchestration and AI model governance, helping eliminate the fragmentation that happens when teams roll out AI tools independently.\n\n## Choosing your deployment path\n\nThe integration delivers the same core GitLab Duo Agent Platform capabilities regardless of how it is deployed. What varies is who runs GitLab, who operates the AI Gateway, and whose Bedrock account the inference runs through. The right pattern depends on where your organization already operates.\n\nAt a high level, the integration has three main components:\n\n* **GitLab Duo Agent Platform:** agentic workflows embedded across the software development lifecycle  \n* **AI Gateway (GitLab-managed or self-hosted):** the abstraction layer between Duo Agent Platform and the foundational model backend   \n* **Amazon Bedrock:** the AI model and inference substrate\n\n![Deployment of GitLab and AWS Bedrock](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776362365/udmvmv2efpmwtkxgydch.png)\n\nChoosing a deployment pattern is informed by where an organization wants to place the levers of control. The patterns below are designed to meet teams where they already are, whether that's SaaS-first, self-managed for compliance, or all-in on AWS with existing Bedrock investments.\n\n| Deployment Model | GitLab.com instance with GitLab-hosted AI Gateway with GitLab-operated Bedrock models   | GitLab Self-Managed with GitLab-hosted AI Gateway with GitLab-operated Bedrock models | GitLab Self-Managed  with self-hosted AI Gateway and customer-operated Bedrock models |\n| :---- | :---- | :---- | :---- |\n| **Ideal if you:** | Are primarily on GitLab.com and don’t want to self-host AI gateway and Bedrock models  | Need GitLab Self-Managed for compliance and operational reasons but don’t want to manage AI layer | Are AWS-centric with existing Bedrock usage and strict data/control needs  |\n| **Key Benefits** | Fastest, turnkey way to get Duo Agent Platform workflows: GitLab runs GitLab.com, the AI Gateway, integrated with Bedrock AI models. | Keep GitLab deployed in your own environment while consuming Bedrock models via a GitLab-managed AI Gateway, combining deployment control with simplified AI operations. | Run GitLab and AI Gateway in your AWS account, reuse existing IAM/VPC/regions, keep logs and data in your environment, and draw Bedrock usage from your existing AWS spend commitments. |\n\n## How customers use GitLab Duo Agent Platform with Amazon Bedrock\n\nPlatform teams can use GitLab Duo Agent Platform with Amazon Bedrock to standardize which models handle code suggestions, security analysis, and pipeline remediation. This helps enforce guardrails and logging centrally rather than letting individual teams adopt separate tools independently.\n\nSecurity workflows see particular benefit. GitLab Duo Agent Platform agents can propose and validate fixes for security findings within GitLab, helping reduce the manual triage work developers would otherwise handle outside the platform.\n\nFor enterprises already committed to AWS, routing AI workloads through Bedrock from within GitLab enables you to keep developer AI usage aligned with existing cloud agreements rather than generating separate, unplanned spend.\n\n## Closing the loop\n\nThe constraints that slow enterprise AI adoption are often not technical. They are organizational: fragmented tooling, ungoverned data flows, and cloud spend that never consolidates. Those are the problems that can stall AI programs even after the pilots succeed.\n\nGitLab Duo Agent Platform and Amazon Bedrock help address each one directly. Platform teams get consistent governance, auditability, and standardized paths for AI usage across the software development lifecycle. Development teams get streamlined, agentic workflows that feel native to GitLab. And AWS-centric organizations get to extend their existing Bedrock investment rather than build parallel AI infrastructure alongside it.\n\nThe result is an AI program that scales without fragmenting. Governance and velocity on the same stack, serving the same teams, under policies the organization already owns.\n\n\n> To explore which deployment pattern is right for your organization and how to align GitLab Duo Agent Platform and Amazon Bedrock with your existing AWS strategy, [contact the GitLab sales team](https://about.gitlab.com/sales/) and we’ll help you design and implement the best architecture for your environment. You can also [visit our AWS partner page](https://about.gitlab.com/partners/technology-partners/aws/) to learn more.",[277,758,759],"AWS","AI/ML","2026-04-21",[762,763],"Joe Mann","Mark Kriaf","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776362275/ozbwn9tk0dditpnfddlz.png",{"featured":30,"template":15,"slug":766},"gitlab-amazon-platform-orchestration-on-a-trusted-ai-foundation",{"content":768,"config":778},{"title":769,"description":770,"authors":771,"heroImage":773,"date":774,"body":775,"category":11,"tags":776},"GitLab 18.11: Budget guardrails for GitLab Credits","Learn how new spending caps and per-user credit limits give organizations the budget guardrails to scale GitLab Duo Agent Platform.",[772],"Bryan Rothwell","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776259080/cakqnwo5ecp255lo8lzo.png","2026-04-16","Teams using GitLab Duo Agent Platform with on-demand GitLab Credits are shipping faster, catching bugs earlier, and automating tasks that used to take entire sprints. But as adoption grows, so does oversight from finance, procurement, and platform teams to prove that AI spending is bounded, predictable, and controllable.\n\nOne of the greatest barriers to broader AI adoption isn't skepticism about the technology. It's uncertainty about managing spend. Without budget caps, a busy month could produce unexpected expenses. Without per-user limits, a handful of power users could burn through the team's credits before the month is over. And without either, engineering leaders who want to expand their use of agentic AI for software development have to jump through more hoops for budget approval.\n\nSince its [general availability](https://about.gitlab.com/blog/gitlab-duo-agent-platform-is-generally-available/), GitLab Duo Agent Platform has provided usage governance and visibility. With GitLab 18.11, we're introducing usage controls for [GitLab Credits](https://about.gitlab.com/blog/introducing-gitlab-credits/): spending caps and budget guardrails that give your organization even more control and transparency over how credits are consumed.\n\n## Managing GitLab Credits\n\nGitLab 18.11 adds three layers of control over GitLab Credits consumption: a subscription-level spending cap, per-user credit limits, and visibility into cap status and enforcement.\n\n### Subscription-level spending cap\n\nBilling account managers can now set a hard monthly ceiling for on-demand GitLab Credits consumption for their entire subscription.\n\nHere's how it works:\n\n* **Set a cap** in the `Customers Portal` under your subscription's GitLab Credits settings.  \n* **Enforce spend limits automatically.**  When on-demand usage reaches the cap, DAP access is paused for all users on that subscription until the next monthly period begins.  \n* **Make adjustments as you go.** Raise or disable the cap mid-month to restore access.\n\nThe cap resets each monthly period and your configured limit carries forward unless you change it. Because usage data is synchronized periodically rather than in real time, a small amount of additional usage may occur after the cap is reached before enforcement takes effect. See the [GitLab Credits documentation](https://docs.gitlab.com/subscriptions/gitlab_credits/) for details.\n\n### User-level spending caps\n\nNot every user consumes credits at the same rate, and that's expected. But when one or two power users account for a disproportionate share of the pool, the rest of the team can lose access before the month is over.\n\nPer-user credit caps prevent any single user from consuming more than their fair share:\n\n* **Flat per-user cap.** Set a uniform credit limit that applies equally to every user on the subscription through the GitLab GraphQL API. Unlike the subscription-level cap, the per-user cap applies to a user's total consumption across all credit sources.  \n* **Custom per-user overrides.** For organizations that need differentiated limits, you can set individual credit caps for specific users through the GraphQL API. For example, you could give your staff engineers a higher allocation while applying a standard limit to the broader team.  \n* **Individual enforcement.** When a user reaches their cap, they retain full access to GitLab. Only their Duo Agent Platform credit usage is paused until the next billing cycle. Everyone else keeps working uninterrupted until they hit their own limit or the subscription-level cap is reached, whichever comes first.\n\n### Visibility and notifications\n\nWhen a subscription-level cap is reached, GitLab sends an email notification to billing account managers so they can take action: raise the cap, wait for the next period, or redistribute credits.\n\nWithin GitLab, group owners (GitLab.com) and instance administrators (Self-Managed) can view which users have been blocked due to reaching their per-user cap and restore access by adjusting the cap through the GraphQL API. \n\n## How budget guardrails help organizations scale AI usage\n\nGuardrails are essential as organizations ramp up their AI adoption. Here's why:\n\n### Predictable AI budgets\n\nUsage controls for GitLab Duo Agent Platform turn AI into a bounded, predictable budget item using on-demand GitLab Credits. That makes it easier to deploy agents across the software development lifecycle and get sign-off from finance, justify renewals, and plan quarterly spend.\n\n### Governance and chargeback\n\nLarge organizations often need to align AI consumption with internal budgets, cost centers, or departmental policies. Per-user caps give platform teams a straightforward mechanism to allocate credits fairly and track consumption at the individual level. The API import options make it practical to manage caps at enterprise scale. Combined with per-user usage data from the GitLab Credits dashboard, organizations can track consumption patterns to inform their own internal chargeback or budget allocation processes.\n\n### Confidence to scale\n\nMany customers start GitLab Duo Agent Platform with a small pilot group. Usage controls remove risks associated with expanding that pilot across the organization. You can roll out Duo Agent Platform to hundreds or thousands of developers knowing there's a hard ceiling protecting your budget. If usage grows faster than expected, you'll hit the cap, not an unexpected invoice.\n\n## Addressing the seat-based and visibility conundrum\n\nMany AI coding tools take a seat-based approach to cost management. You buy a fixed number of seats at a flat per-user price, and that's your budget. It's simple, but rigid. You pay the same whether a developer uses the tool ten times a day or never touches it. And as vendors introduce premium models and usage-based overages on top of seat pricing, the cost predictability that seat-based licensing promised starts to erode.\n\n\nGitLab takes a different approach. Usage-based pricing with hard caps and a single governance dashboard. You get the flexibility of paying for what your teams actually use, with the budget predictability of enforced spending limits.\n\n## Real-world usage controls\n\n**One example is a mid-size SaaS customer that wants to protect their monthly budget.** A 200-person engineering organization sets a subscription-level cap equal to their expected on-demand usage. Their VP of Engineering can confidently tell finance that GitLab Duo Agent Platform spend will never exceed the approved amount, even as they onboard new teams. If they approach the cap mid-month, the billing account manager gets a notification and can decide whether to raise the limit or wait for the next period.\n\n**At GitLab, we also work with large enterprises that want to keep usage fair across teams.** A global financial services company with 2,000 developers uses per-user caps to ensure equitable access. Staff engineers working on complex refactoring projects get a higher individual allocation via API, while most developers receive a standard flat cap. No single user can exhaust the pool, and the platform team uses the per-user usage data in the GitLab Credits dashboard to track consumption patterns and inform quarterly budget planning.\n\n## Getting started\n\nUsage controls are available for both GitLab.com and Self-Managed customers running GitLab 18.11. Different controls are configured in different places depending on the scope and your role.\n\n**Subscription-level cap**\n\nBilling account managers set the subscription-level on-demand cap in the Customers Portal:\n\n1. Sign in to the `Customers Portal`.  \n2. On your subscription card, navigate to **GitLab Credits** settings.  \n3. Enable the monthly on-demand credits cap and enter your desired limit.\n\n**Flat per-user cap**\n\nThe flat per-user cap can be set through the GitLab GraphQL API by namespace owners (GitLab.com) or instance administrators (Self-Managed). Check the [GitLab Credits documentation](https://docs.gitlab.com/subscriptions/gitlab_credits/) for the latest on available configuration surfaces.\n\n**Custom per-user overrides**\n\nFor differentiated limits, namespace owners (GitLab.com) and instance administrators (Self-Managed) can set individual caps programmatically. This is useful for automation and infrastructure-as-code workflows.\n\n**Monitor usage and cap status**\n\n* **Customers Portal:** View detailed usage and cap status.  \n* **GitLab.com:** Group owners can view blocked users under **Settings > GitLab Credits**.  \n* **Self-Managed:** Instance administrators can view cap status and blocked users under **Admin > GitLab Credits**.\n\n## GitLab Duo Agent Platform is ready to scale\n\nUsage controls are available now in GitLab 18.11. If you've been waiting for the right guardrails before expanding GitLab Duo Agent Platform across your organization, this is your moment. Set your caps, roll out Duo Agent Platform to more teams, and start shipping faster!\n\n> [Learn more about GitLab Credits and usage controls](https://docs.gitlab.com/subscriptions/gitlab_credits/).",[11,759,777],"news",{"featured":14,"template":15,"slug":779},"gitlab-18-11-budget-guardrails-for-gitlab-credits",{"promotions":781},[782,796,807,819],{"id":783,"categories":784,"header":786,"text":787,"button":788,"image":793},"ai-modernization",[785],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":789,"config":790},"Get your AI maturity score",{"href":791,"dataGaName":792,"dataGaLocation":244},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":794},{"src":795},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":797,"categories":798,"header":799,"text":787,"button":800,"image":804},"devops-modernization",[11,569],"Are you just managing tools or shipping innovation?",{"text":801,"config":802},"Get your DevOps maturity score",{"href":803,"dataGaName":792,"dataGaLocation":244},"/assessments/devops-modernization-assessment/",{"config":805},{"src":806},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":808,"categories":809,"header":811,"text":787,"button":812,"image":816},"security-modernization",[810],"security","Are you trading speed for security?",{"text":813,"config":814},"Get your security maturity score",{"href":815,"dataGaName":792,"dataGaLocation":244},"/assessments/security-modernization-assessment/",{"config":817},{"src":818},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":820,"paths":821,"header":824,"text":825,"button":826,"image":831},"github-azure-migration",[822,823],"migration-from-azure-devops-to-gitlab","integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":827,"config":828},"See how GitLab compares to GitHub",{"href":829,"dataGaName":830,"dataGaLocation":244},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":832},{"src":806},{"header":834,"blurb":835,"button":836,"secondaryButton":841},"Start building faster today","See what your team can do with the intelligent orchestration platform for DevSecOps.\n",{"text":837,"config":838},"Get your free trial",{"href":839,"dataGaName":51,"dataGaLocation":840},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":506,"config":842},{"href":55,"dataGaName":56,"dataGaLocation":840},1777302610941]