[{"data":1,"prerenderedAt":802},["ShallowReactive",2],{"/en-us/blog/ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline":3,"navigation-en-us":34,"banner-en-us":443,"footer-en-us":453,"blog-post-authors-en-us-Dov Hershkovitch":694,"blog-related-posts-en-us-ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline":708,"blog-promotions-en-us":740,"next-steps-en-us":792},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":25,"isFeatured":11,"meta":26,"navigation":27,"path":28,"publishedDate":20,"seo":29,"stem":30,"tagSlugs":31,"__hash__":33},"blogPosts/en-us/blog/ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline.yml","Ci Cd Inputs Secure And Preferred Method To Pass Parameters To A Pipeline",[7],"dov-hershkovitch",null,"product",{"featured":11,"template":12,"slug":13},false,"BlogPost","ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline",{"title":15,"description":16,"authors":17,"heroImage":19,"date":20,"body":21,"category":9,"tags":22},"CI/CD inputs: Secure and preferred method to pass parameters to a pipeline","Learn how CI/CD inputs provide type-safe parameter passing with validation, replacing error-prone variables for more reliable pipelines.",[18],"Dov Hershkovitch","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749658912/Blog/Hero%20Images/blog-image-template-1800x945__20_.png","2025-07-07","\nGitLab CI/CD inputs represent the future of pipeline parameter passing. As a purpose-built feature designed specifically for typed parameters with validation, clear contracts, and enhanced security, inputs solve the fundamental challenges that teams have been working around with variables for years.\nWhile CI/CD variables have served as the traditional method for passing parameters to pipelines, they were originally designed for storing configuration settings — not as a sophisticated parameter-passing mechanism for complex workflows. This fundamental mismatch has created reliability issues, security concerns, and maintenance overhead that inputs elegantly eliminate.\nThis article demonstrates why CI/CD inputs should be your preferred approach for pipeline parameters. You'll discover how inputs provide type safety, prevent common pipeline failures, eliminate variable collision issues, and create more maintainable automation. You'll also see practical examples of inputs in action and how they solve real-world challenges, which we hope will encourage you to transition from variable-based workarounds to input-powered reliability.\n## The hidden costs of variable-based parameter passing\nThe problems with using variables for parameter passing are numerous and frustrating. \n**No type validation**\nVariables are strings. There is no type validation, meaning a pipeline expecting a boolean or a number, but accidentally receives a string. This leads to unexpected failures deep into the pipeline execution. In the case of a deployment workflow for example, hours after it was started  a critical production deployment fails because a boolean check in a variable was not passed as expected.\n\n**Runtime mutability**\nVariables can be modified throughout the pipeline runtime, creating unpredictable behavior when multiple jobs attempt to change the same values. For example, deploy_job_a sets `DEPLOY_ENV=staging`, but deploy_job_b changes the `DEPLOY_ENV` value to `production`. \n\n**Security risks**\nSecurity concerns arise because variables intended as simple parameters often receive the same access permissions as sensitive secrets. There's no clear contract defining what parameters a pipeline expects, their types, or their default values. A simple `BUILD_TYPE` parameter, that seems innocuous at first glance, suddenly has access to production secrets simply because variables do not inherently distinguish between parameters and sensitive data.\n\nPerhaps most problematically, error detection happens too late in the process. A misconfigured variable might not cause a failure until minutes or even hours into a pipeline run, wasting valuable CI/CD resources and developer time. Teams have developed elaborate workarounds such as custom validation scripts, extensive documentation, and complex naming conventions just to make variable-based parameter passing somewhat reliable.\nMany users have requested local debugging capabilities to test pipeline configurations before deployment. While this seems like an obvious solution, it quickly breaks down in practice. Enterprise CI/CD workflows integrate with dozens of external systems — cloud providers, artifact repositories, security scanners, deployment targets — that simply can't be replicated locally. Even if they could, the complexity would make local testing environments nearly impossible to maintain. This mismatch forced us to reframe the problem entirely. Instead of asking \"How can we test pipelines locally?\" we started asking \"How can we prevent configuration issues caused by variable-based parameter passing before users run a CI/CD automation workflow?\"\n## Understanding variable precedence\nGitLab's variable system includes multiple [precedence levels](https://docs.gitlab.com/ci/variables/#cicd-variable-precedence) to provide flexibility for different use cases. While this system serves many valid scenarios like allowing administrators to set instance- or group-wide defaults while letting individual projects override them when needed, it can create challenges when building reusable pipeline components.\n\nWhen creating components or templates that will be used across different projects and groups, the variable precedence hierarchy can make behavior less predictable. For example, a template that works perfectly in one project might behave differently in another due to group- or instance-level variable overrides that aren't visible in a pipeline configuration.\n\nWhen including multiple templates, it also can be challenging to track which variables are being set where and how they might interact.\n\nIn addition, components authors need to document not just what variables their template uses, but also potential conflicts with variables that might be defined at higher precedence levels.\n\n### Variable precedence examples\n\n**Main pipeline file (`.gitlab-ci.yml`):**\n\n```yaml\nvariables:\n  ENVIRONMENT: production  # Top-level default for all jobs\n  DATABASE_URL: prod-db.example.com\n\ninclude:\n  - local: 'templates/test-template.yml'\n  - local: 'templates/deploy-template.yml'\n\n```\n\n**Test template (`templates/test-template.yml`):**\n\n```yaml\nrun-tests:\n  variables:\n    ENVIRONMENT: test  # Job-level variable overrides the default\n  script:\n    - echo \"Running tests in $ENVIRONMENT environment\"  \n    - echo \"Database URL is $DATABASE_URL\"  # Still inherits prod-db.example.com!\n    - run-integration-tests --env=$ENVIRONMENT --db=$DATABASE_URL\n    `# Issue: Tests run in \"test\" environment but against production database`\n\n```\n\n**Deploy template (`templates/deploy-template.yml`):**\n\n```yaml\ndeploy-app:\n  script:\n    - echo \"Deploying to $ENVIRONMENT\"  # Uses production (top-level default)\n    - echo \"Database URL is $DATABASE_URL\"  # Uses prod-db.example.com\n    - deploy --target=$ENVIRONMENT --db=$DATABASE_URL\n    # This will deploy to production as intended\n\n```\n**The challenges in this example:**\n\n1. Partial inheritance: The test job gets `ENVIRONMENT=test` but still inherits `DATABASE_URL=prod-db.example.com`.  \n2. Coordination complexity: Template authors must know what top-level variables exist and might conflict.  \n3. Override behavior: Job-level variables with the same name override defaults, but this isn't always obvious.  \n4. Hidden dependencies: Templates become dependent on the main pipeline's variable names.\n\nGitLab recognized these pain points and introduced [CI/CD inputs](https://docs.gitlab.com/ee/ci/inputs/) as a purpose-built solution for passing parameters to pipelines, offering typed parameters with built-in validation that occurs at pipeline creation time rather than during execution.\n\n## CI/CD inputs fundamentals\n\nInputs provide typed parameters for reusable pipeline configuration with built-in validation at pipeline creation time, designed specifically for defining values when the pipeline runs. They create a clear contract between the pipeline consumer and the configuration, explicitly defining what parameters are expected, their types, and constraints.\n\n### Configuration flexibility and scope\n\nOne of the advantages of inputs is their configuration-time flexibility. Inputs are evaluated and interpolated during pipeline creation using the interpolation format `$[[ inputs.input-id ]]`, meaning they can be used anywhere in your pipeline configuration — including job names, rules conditions, images, and any other YAML configuration element. This eliminates the long-standing limitation of variable interpolation in certain contexts.\n\nOne common use case we've seen is that users define their job names like `test-$[[ inputs.environment ]]-deployment`.\n\nWhen using inputs in job names, you can prevent naming conflicts when the same component is included multiple times in a single pipeline. Without this capability, including the same component twice would result in job name collisions, with the second inclusion overwriting the first. Input-based job names ensure each inclusion creates uniquely named jobs.\n\n**Before inputs:**\n\n```yaml\ntest-service:\n  variables:\n    SERVICE_NAME: auth-service\n    ENVIRONMENT: staging\n  script:\n    - run-tests-for $SERVICE_NAME in $ENVIRONMENT\n\n```\n\n**With inputs:**\n\n```yaml\nspec:\n  inputs:\n    environment:\n      type: string\n    service_name:\n      type: string\n\ntest-$[[ inputs.service_name ]]-$[[ inputs.environment ]]:\n  script:\n    - run-tests-for $[[ inputs.service_name ]] in $[[ inputs.environment ]]\n\n```\n\nWhen included multiple times with different inputs, this creates jobs like `test-auth-service-staging`, `test-payment-service-production`, and `test-notification-service-development`. Each job has a unique, meaningful name that clearly indicates its purpose, making pipeline visualization much clearer than having multiple jobs with identical names that would overwrite each other.\n\nNow let's go back to the first example in the top of this blog and use inputs, one immediate benefit is that instead of maintaining multiple templates file we can use one reusable template with different input values:\n\n```yaml\nspec:\n  inputs:\n    environment:\n      type: string\n    database_url:\n      type: string\n    action:\n      type: string\n---\n$[[ inputs.action ]]-$[[ inputs.environment ]]:\n  script:\n    - echo \"Running $[[ inputs.action ]] in $[[ inputs.environment ]] environment\"\n    - echo \"Database URL is $[[ inputs.database_url ]]\"\n    - run-$[[ inputs.action ]] --env=$[[ inputs.environment ]] --db=$[[ inputs.database_url ]]\n\n```\n\nAnd in the main `gitlab-ci.yml` file we can include it twice (or more) with different values, making sure we avoid naming collisions\n\n```yaml\ninclude:\n  - local: 'templates/environment-template.yml'\n    inputs:\n      environment: test\n      database_url: test-db.example.com\n      action: tests\n  - local: 'templates/environment-template.yml'\n    inputs:\n      environment: production\n      database_url: prod-db.example.com\n      action: deploy\n\n```\n\n**The result:** Instead of maintaining separate YAML files for testing and deployment jobs, you now have a single reusable template that handles both use cases safely. This approach scales to any number of environments or job types — reducing maintenance overhead, eliminating code duplication, and ensuring consistency across your entire pipeline configuration. One template to maintain instead of many, with zero risk of variable collision or configuration drift.\n\n### Validation and type safety\n\nAnother key difference between variables and inputs lies in validation capabilities. Inputs support different value types, including strings, numbers, booleans, and arrays, with validation occurring immediately when the pipeline is created. If you define an input as a boolean but pass a string, GitLab will reject the pipeline before any jobs execute, saving time and resources.\n\nHere is an example of the enormous benefit of type validation.\n\n**Without type validation (variables):**\n\n```yaml\nvariables:\n  ENABLE_TESTS: \"true\"  # Always a string\n  MAX_RETRIES: \"3\"      # Always a string\n\ndeploy_job:\n  script:\n    - if [ \"$ENABLE_TESTS\" = true ]; then  # This fails!\n        echo \"Running tests\"\n      fi\n    - retry_count=$((MAX_RETRIES + 1))      # String concatenation: \"31\"\n\n```\n\n**Problem:**  The boolean check fails because “`true`” (string) is not equal to `true`, (boolean).\n\n**With type validation (inputs):**\n\n```yaml\nspec:\n  inputs:\n    enable_tests:\n      type: boolean\n      default: true\n    max_retries:\n      type: number\n      default: 3\n\n      \ndeploy_job:\n  script:\n    - if [ \"$[[ inputs.enable_tests ]]\" = true ]; then  # Works correctly\n        echo \"Running tests\"\n      fi\n    - retry_count=$(($[[ inputs.max_retries ]] + 1))    # Math works: 4\n\n```\n\n**Real-world impact for variable type validation failure**: A developer or a process triggers a GitLab CI/CD pipeline with `ENABLE_TESTS = yes` instead of `true`. Assuming it takes on average 30 minutes before the deployment job starts, then finally when this job kicks off, 30 minutes or longer into the pipeline run, the deployment script tries to evaluate the boolean and fails.  \n\nImagine the impact in terms of time-to-market and, of course. developer time trying to debug why a seemingly basic deploy job failed.\n\nWith type inputs, GitLab CI/CD will immediately throw an error and provide an explicit error message regarding the type mismatch.\n\n### Security and access control\n\nInputs provide enhanced security through controlled parameter passing with explicit contracts that define exactly what values are expected and allowed, creating clear boundaries between parameter passing to the pipeline, In addition. inputs are immutable. Once the pipeline starts, they cannot be modified during execution, providing predictable behavior throughout the pipeline lifecycle and eliminating the security risks that come from runtime variable manipulation.\n\n### Scope and lifecycle\n\nWhen you define variables using the `variables:` keyword at the top level of your `.gitlab-ci.yml` file, these variables become defaults for all jobs in your entire pipeline. When you include templates, you must consider what variables you've defined globally, as they can interact with the template's expected behavior through GitLab's variable precedence order.\n\nInputs are defined in CI configuration files (e.g. components or templates) and assigned values when a pipeline is triggered, allowing you to customize reusable CI configurations. They exist solely for pipeline creation and configuration time, scoped to the CI configuration file where they're defined, and become immutable references once the pipeline begins execution. Since each component maintains its own inputs, there is no risk of inputs interfering with other components or templates in your pipeline, eliminating variable collision and override issues that can occur with variable-based approaches.\n\n## Working with variables and inputs together\n\nWe recognize that teams have extensive investments in their variable-based workflows, and migration to inputs doesn't happen overnight. That's why we've developed capabilities that allow inputs and variables to work seamlessly together, providing a bridge between existing variables and the benefits of inputs while overcoming some key challenges in variable expansion.\n\nLet's look at this real-world example.\n\n**Variable expansion in rules conditions**\n\nA common challenge occurs when using variables that contain other variable references in `rules:if` conditions. GitLab only expands variables one level deep during rule evaluation, which can lead to unexpected behavior:\n\n```yaml\n# This doesn't work as expected\nvariables:\n  TARGET_ENV:\n    value: \"${CI_COMMIT_REF_SLUG}\"\n\ndeploy-job:\n  rules:\n    - if: '$TARGET_ENV == \"production\"'  # Compares \"${CI_COMMIT_REF_SLUG}\" != \"production\"\n      variables:\n        DEPLOY_MODE: \"blue-green\"\n\n```\n\nThe `expand_vars` function solves this by forcing proper variable expansion in inputs:\n```yaml\nspec:\n  inputs:\n    target_environment:\n      description: \"Target deployment environment\"\n      default: \"${CI_COMMIT_REF_SLUG}\"\n---\n\ndeploy-job:\n  rules:\n    - if: '\"$[[ inputs.target_environment | expand_vars ]]\" == \"production\"'\n      variables:\n        DEPLOY_MODE: \"blue-green\"\n        APPROVAL_REQUIRED: \"true\"\n    - when: always\n      variables:\n        DEPLOY_MODE: \"rolling\"\n        APPROVAL_REQUIRED: \"false\"\n  script:\n    - echo \"Target: $[[ inputs.target_environment | expand_vars ]]\"\n    - echo \"Deploy mode: ${DEPLOY_MODE}\"\n\n```\n\n### Why this matters\n\nWithout `expand_vars`, rule conditions evaluate against the literal variable reference (like `\"${CI_COMMIT_REF_SLUG}\"`) rather than the expanded value (like `\"production\"`). This leads to rules that never match when you expect them to, breaking conditional pipeline logic.\n\n**Important notes about expand_vars:**\n\n* Only variables that can be used with the include keyword are supported  \n* Variables must be unmasked (not marked as protected/masked)  \n* Nested variable expansion is not supported  \n* Rule conditions using `expand_vars` must be properly quoted: `'\"$[[ inputs.name | expand_vars ]]\" == \"value\"'`\n\nThis pattern solves the single-level variable expansion limitation, working for any conditional logic that requires comparing fully resolved variable values.\n\n### Function chaining for advanced processing\n\nAlong with `expand_vars`, you can use functions like `truncate` to shorten values for compliance with naming restrictions (such as Kubernetes resource names), creating sophisticated parameter processing pipelines while maintaining input safety and predictability.\n\n```yaml\nspec:  \n  inputs:\n    service_identifier:\n      default: 'service-$CI_PROJECT_NAME-$CI_COMMIT_REF_SLUG'\n---\ncreate-resource:\n  script:\n    - resource_name=$[[ inputs.service_identifier | expand_vars | truncate(0,50) ]]\n\n```\n\nThis integration capability allows you to adopt inputs gradually while leveraging your existing variable infrastructure, making the migration path much smoother.\n\n### From components only to CI pipelines\n\nUp until GitLab 17.11, GitLab users were able to use inputs only in components and templates through the `include:` syntax. This limited their use to reusable CI/CD configurations, but didn't address the broader need for dynamic pipeline customization.\n\n### Pipeline-wide inputs support\n\nStarting with GitLab 17.11, GitLab users can now use inputs to safely modify pipeline behavior across all pipeline execution contexts, replacing the traditional reliance on pipeline variables. This expanded support includes:\n\n* Scheduled pipelines: Define inputs with defaults for automated pipeline runs while allowing manual override when needed.  \n* Downstream pipelines: Pass structured inputs to child and multi-project pipelines with proper validation and type safety.  \n* Manual pipelines: Present users with a clean, validated form interface.\n\nThose enhancements, with more to follow, allow teams to modernize their pipelines while maintaining backward compatibility gradually. Once inputs are fully adopted, users can disable pipeline variables to ensures a more secure and predictable CI/CD environment.\n\n## Summary\n\nThe transition from variables to inputs represents more than just a technical upgrade — it's a shift toward more maintainable, predictable, and secure CI/CD pipelines. While variables continue to serve important purposes for configuration, inputs provide the parameter-passing capabilities that teams have been working around for years.\n\nWe understand that variables are deeply embedded in existing workflows, which is why we've built bridges between the two systems. The `expand_vars` function and other input capabilities allow you to adopt inputs gradually while leveraging your existing variable infrastructure.\n\nBy starting with new components and templates, then gradually migrating high-impact workflows, you'll quickly see the benefits of clearer contracts, earlier error detection, and more reliable automation that scales across your organization. Additionally, moving to inputs creates an excellent foundation for leveraging [GitLab's CI/CD Catalog](https://gitlab.com/explore/catalog), where reusable components with typed interfaces become powerful building blocks for your DevOps workflows but more on that in our next blog post.\n\nYour future self and your teammates will thank you for the clarity and reliability that inputs bring to your CI/CD workflows, while still being able to work with the variable systems you've already invested in.\n\n## What's next \n\nLooking ahead, we're expanding inputs to solve two key challenges: enhancing pipeline triggering with cascading options that [dynamically adjust based on user selections](https://gitlab.com/gitlab-org/gitlab/-/issues/520094), and providing job-level inputs that allow users to [retry individual jobs with different parameter values](https://gitlab.com/groups/gitlab-org/-/epics/17833). We encourage you to follow these discussions, share your feedback, and contribute to shaping these features. You can also provide general feedback on CI/CD inputs through our [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/407556).\n## Read more\n- [How to include file references in your CI/CD components](https://about.gitlab.com/blog/how-to-include-file-references-in-your-ci-cd-components/) - [CI/CD inputs documentation](https://docs.gitlab.com/ci/inputs/) - [CI/CD Catalog goes GA: No more building pipelines from scratch](https://about.gitlab.com/blog/ci-cd-catalog-goes-ga-no-more-building-pipelines-from-scratch/) - [GitLab environment variables demystified](https://about.gitlab.com/blog/demystifying-ci-cd-variables/)\n",[23,9,24],"CI/CD","security","yml",{},true,"/en-us/blog/ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline",{"noIndex":11,"title":15,"description":16},"en-us/blog/ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline",[32,9,24],"cicd","3oyv6SyMzVVryk8JK_fO87zP-M2aEanFnDxCN-vW5ds",{"data":35},{"logo":36,"freeTrial":41,"sales":46,"login":51,"items":56,"search":363,"minimal":394,"duo":413,"switchNav":422,"pricingDeployment":433},{"config":37},{"href":38,"dataGaName":39,"dataGaLocation":40},"/","gitlab logo","header",{"text":42,"config":43},"Get free trial",{"href":44,"dataGaName":45,"dataGaLocation":40},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":47,"config":48},"Talk to sales",{"href":49,"dataGaName":50,"dataGaLocation":40},"/sales/","sales",{"text":52,"config":53},"Sign in",{"href":54,"dataGaName":55,"dataGaLocation":40},"https://gitlab.com/users/sign_in/","sign in",[57,84,178,183,284,344],{"text":58,"config":59,"cards":61},"Platform",{"dataNavLevelOne":60},"platform",[62,68,76],{"title":58,"description":63,"link":64},"The intelligent orchestration platform for DevSecOps",{"text":65,"config":66},"Explore our Platform",{"href":67,"dataGaName":60,"dataGaLocation":40},"/platform/",{"title":69,"description":70,"link":71},"GitLab Duo Agent Platform","Agentic AI for the entire software lifecycle",{"text":72,"config":73},"Meet GitLab Duo",{"href":74,"dataGaName":75,"dataGaLocation":40},"/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":77,"description":78,"link":79},"Why GitLab","See the top reasons enterprises choose GitLab",{"text":80,"config":81},"Learn more",{"href":82,"dataGaName":83,"dataGaLocation":40},"/why-gitlab/","why gitlab",{"text":85,"left":27,"config":86,"link":88,"lists":92,"footer":160},"Product",{"dataNavLevelOne":87},"solutions",{"text":89,"config":90},"View all Solutions",{"href":91,"dataGaName":87,"dataGaLocation":40},"/solutions/",[93,116,139],{"title":94,"description":95,"link":96,"items":101},"Automation","CI/CD and automation to accelerate deployment",{"config":97},{"icon":98,"href":99,"dataGaName":100,"dataGaLocation":40},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[102,105,108,112],{"text":23,"config":103},{"href":104,"dataGaLocation":40,"dataGaName":23},"/solutions/continuous-integration/",{"text":69,"config":106},{"href":74,"dataGaLocation":40,"dataGaName":107},"gitlab duo agent platform - product menu",{"text":109,"config":110},"Source Code Management",{"href":111,"dataGaLocation":40,"dataGaName":109},"/solutions/source-code-management/",{"text":113,"config":114},"Automated Software Delivery",{"href":99,"dataGaLocation":40,"dataGaName":115},"Automated software delivery",{"title":117,"description":118,"link":119,"items":124},"Security","Deliver code faster without compromising security",{"config":120},{"href":121,"dataGaName":122,"dataGaLocation":40,"icon":123},"/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[125,129,134],{"text":126,"config":127},"Application Security Testing",{"href":121,"dataGaName":128,"dataGaLocation":40},"Application security testing",{"text":130,"config":131},"Software Supply Chain Security",{"href":132,"dataGaLocation":40,"dataGaName":133},"/solutions/supply-chain/","Software supply chain security",{"text":135,"config":136},"Software Compliance",{"href":137,"dataGaName":138,"dataGaLocation":40},"/solutions/software-compliance/","software compliance",{"title":140,"link":141,"items":146},"Measurement",{"config":142},{"icon":143,"href":144,"dataGaName":145,"dataGaLocation":40},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[147,151,155],{"text":148,"config":149},"Visibility & Measurement",{"href":144,"dataGaLocation":40,"dataGaName":150},"Visibility and Measurement",{"text":152,"config":153},"Value Stream Management",{"href":154,"dataGaLocation":40,"dataGaName":152},"/solutions/value-stream-management/",{"text":156,"config":157},"Analytics & Insights",{"href":158,"dataGaLocation":40,"dataGaName":159},"/solutions/analytics-and-insights/","Analytics and insights",{"title":161,"items":162},"GitLab for",[163,168,173],{"text":164,"config":165},"Enterprise",{"href":166,"dataGaLocation":40,"dataGaName":167},"/enterprise/","enterprise",{"text":169,"config":170},"Small Business",{"href":171,"dataGaLocation":40,"dataGaName":172},"/small-business/","small business",{"text":174,"config":175},"Public Sector",{"href":176,"dataGaLocation":40,"dataGaName":177},"/solutions/public-sector/","public sector",{"text":179,"config":180},"Pricing",{"href":181,"dataGaName":182,"dataGaLocation":40,"dataNavLevelOne":182},"/pricing/","pricing",{"text":184,"config":185,"link":187,"lists":191,"feature":271},"Resources",{"dataNavLevelOne":186},"resources",{"text":188,"config":189},"View all resources",{"href":190,"dataGaName":186,"dataGaLocation":40},"/resources/",[192,225,243],{"title":193,"items":194},"Getting started",[195,200,205,210,215,220],{"text":196,"config":197},"Install",{"href":198,"dataGaName":199,"dataGaLocation":40},"/install/","install",{"text":201,"config":202},"Quick start guides",{"href":203,"dataGaName":204,"dataGaLocation":40},"/get-started/","quick setup checklists",{"text":206,"config":207},"Learn",{"href":208,"dataGaLocation":40,"dataGaName":209},"https://university.gitlab.com/","learn",{"text":211,"config":212},"Product documentation",{"href":213,"dataGaName":214,"dataGaLocation":40},"https://docs.gitlab.com/","product documentation",{"text":216,"config":217},"Best practice videos",{"href":218,"dataGaName":219,"dataGaLocation":40},"/getting-started-videos/","best practice videos",{"text":221,"config":222},"Integrations",{"href":223,"dataGaName":224,"dataGaLocation":40},"/integrations/","integrations",{"title":226,"items":227},"Discover",[228,233,238],{"text":229,"config":230},"Customer success stories",{"href":231,"dataGaName":232,"dataGaLocation":40},"/customers/","customer success stories",{"text":234,"config":235},"Blog",{"href":236,"dataGaName":237,"dataGaLocation":40},"/blog/","blog",{"text":239,"config":240},"Remote",{"href":241,"dataGaName":242,"dataGaLocation":40},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":244,"items":245},"Connect",[246,251,256,261,266],{"text":247,"config":248},"GitLab Services",{"href":249,"dataGaName":250,"dataGaLocation":40},"/services/","services",{"text":252,"config":253},"Community",{"href":254,"dataGaName":255,"dataGaLocation":40},"/community/","community",{"text":257,"config":258},"Forum",{"href":259,"dataGaName":260,"dataGaLocation":40},"https://forum.gitlab.com/","forum",{"text":262,"config":263},"Events",{"href":264,"dataGaName":265,"dataGaLocation":40},"/events/","events",{"text":267,"config":268},"Partners",{"href":269,"dataGaName":270,"dataGaLocation":40},"/partners/","partners",{"backgroundColor":272,"textColor":273,"text":274,"image":275,"link":279},"#2f2a6b","#fff","Insights for the future of software development",{"altText":276,"config":277},"the source promo card",{"src":278},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":280,"config":281},"Read the latest",{"href":282,"dataGaName":283,"dataGaLocation":40},"/the-source/","the source",{"text":285,"config":286,"lists":288},"Company",{"dataNavLevelOne":287},"company",[289],{"items":290},[291,296,302,304,309,314,319,324,329,334,339],{"text":292,"config":293},"About",{"href":294,"dataGaName":295,"dataGaLocation":40},"/company/","about",{"text":297,"config":298,"footerGa":301},"Jobs",{"href":299,"dataGaName":300,"dataGaLocation":40},"/jobs/","jobs",{"dataGaName":300},{"text":262,"config":303},{"href":264,"dataGaName":265,"dataGaLocation":40},{"text":305,"config":306},"Leadership",{"href":307,"dataGaName":308,"dataGaLocation":40},"/company/team/e-group/","leadership",{"text":310,"config":311},"Team",{"href":312,"dataGaName":313,"dataGaLocation":40},"/company/team/","team",{"text":315,"config":316},"Handbook",{"href":317,"dataGaName":318,"dataGaLocation":40},"https://handbook.gitlab.com/","handbook",{"text":320,"config":321},"Investor relations",{"href":322,"dataGaName":323,"dataGaLocation":40},"https://ir.gitlab.com/","investor relations",{"text":325,"config":326},"Trust Center",{"href":327,"dataGaName":328,"dataGaLocation":40},"/security/","trust center",{"text":330,"config":331},"AI Transparency Center",{"href":332,"dataGaName":333,"dataGaLocation":40},"/ai-transparency-center/","ai transparency center",{"text":335,"config":336},"Newsletter",{"href":337,"dataGaName":338,"dataGaLocation":40},"/company/contact/#contact-forms","newsletter",{"text":340,"config":341},"Press",{"href":342,"dataGaName":343,"dataGaLocation":40},"/press/","press",{"text":345,"config":346,"lists":347},"Contact us",{"dataNavLevelOne":287},[348],{"items":349},[350,353,358],{"text":47,"config":351},{"href":49,"dataGaName":352,"dataGaLocation":40},"talk to sales",{"text":354,"config":355},"Support portal",{"href":356,"dataGaName":357,"dataGaLocation":40},"https://support.gitlab.com","support portal",{"text":359,"config":360},"Customer portal",{"href":361,"dataGaName":362,"dataGaLocation":40},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":364,"login":365,"suggestions":372},"Close",{"text":366,"link":367},"To search repositories and projects, login to",{"text":368,"config":369},"gitlab.com",{"href":54,"dataGaName":370,"dataGaLocation":371},"search login","search",{"text":373,"default":374},"Suggestions",[375,377,381,383,387,391],{"text":69,"config":376},{"href":74,"dataGaName":69,"dataGaLocation":371},{"text":378,"config":379},"Code Suggestions (AI)",{"href":380,"dataGaName":378,"dataGaLocation":371},"/solutions/code-suggestions/",{"text":23,"config":382},{"href":104,"dataGaName":23,"dataGaLocation":371},{"text":384,"config":385},"GitLab on AWS",{"href":386,"dataGaName":384,"dataGaLocation":371},"/partners/technology-partners/aws/",{"text":388,"config":389},"GitLab on Google Cloud",{"href":390,"dataGaName":388,"dataGaLocation":371},"/partners/technology-partners/google-cloud-platform/",{"text":392,"config":393},"Why GitLab?",{"href":82,"dataGaName":392,"dataGaLocation":371},{"freeTrial":395,"mobileIcon":400,"desktopIcon":405,"secondaryButton":408},{"text":396,"config":397},"Start free trial",{"href":398,"dataGaName":45,"dataGaLocation":399},"https://gitlab.com/-/trials/new/","nav",{"altText":401,"config":402},"Gitlab Icon",{"src":403,"dataGaName":404,"dataGaLocation":399},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":401,"config":406},{"src":407,"dataGaName":404,"dataGaLocation":399},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":409,"config":410},"Get Started",{"href":411,"dataGaName":412,"dataGaLocation":399},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/get-started/","get started",{"freeTrial":414,"mobileIcon":418,"desktopIcon":420},{"text":415,"config":416},"Learn more about GitLab Duo",{"href":74,"dataGaName":417,"dataGaLocation":399},"gitlab duo",{"altText":401,"config":419},{"src":403,"dataGaName":404,"dataGaLocation":399},{"altText":401,"config":421},{"src":407,"dataGaName":404,"dataGaLocation":399},{"button":423,"mobileIcon":428,"desktopIcon":430},{"text":424,"config":425},"/switch",{"href":426,"dataGaName":427,"dataGaLocation":399},"#contact","switch",{"altText":401,"config":429},{"src":403,"dataGaName":404,"dataGaLocation":399},{"altText":401,"config":431},{"src":432,"dataGaName":404,"dataGaLocation":399},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":434,"mobileIcon":439,"desktopIcon":441},{"text":435,"config":436},"Back to pricing",{"href":181,"dataGaName":437,"dataGaLocation":399,"icon":438},"back to pricing","GoBack",{"altText":401,"config":440},{"src":403,"dataGaName":404,"dataGaLocation":399},{"altText":401,"config":442},{"src":407,"dataGaName":404,"dataGaLocation":399},{"title":444,"button":445,"config":450},"See how agentic AI transforms software delivery",{"text":446,"config":447},"Watch GitLab Transcend now",{"href":448,"dataGaName":449,"dataGaLocation":40},"/events/transcend/virtual/","transcend event",{"layout":451,"icon":452,"disabled":27},"release","AiStar",{"data":454},{"text":455,"source":456,"edit":462,"contribute":467,"config":472,"items":477,"minimal":683},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":457,"config":458},"View page source",{"href":459,"dataGaName":460,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":463,"config":464},"Edit this page",{"href":465,"dataGaName":466,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":468,"config":469},"Please contribute",{"href":470,"dataGaName":471,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":473,"facebook":474,"youtube":475,"linkedin":476},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[478,525,578,622,649],{"title":179,"links":479,"subMenu":494},[480,484,489],{"text":481,"config":482},"View plans",{"href":181,"dataGaName":483,"dataGaLocation":461},"view plans",{"text":485,"config":486},"Why Premium?",{"href":487,"dataGaName":488,"dataGaLocation":461},"/pricing/premium/","why premium",{"text":490,"config":491},"Why Ultimate?",{"href":492,"dataGaName":493,"dataGaLocation":461},"/pricing/ultimate/","why ultimate",[495],{"title":496,"links":497},"Contact Us",[498,501,503,505,510,515,520],{"text":499,"config":500},"Contact sales",{"href":49,"dataGaName":50,"dataGaLocation":461},{"text":354,"config":502},{"href":356,"dataGaName":357,"dataGaLocation":461},{"text":359,"config":504},{"href":361,"dataGaName":362,"dataGaLocation":461},{"text":506,"config":507},"Status",{"href":508,"dataGaName":509,"dataGaLocation":461},"https://status.gitlab.com/","status",{"text":511,"config":512},"Terms of use",{"href":513,"dataGaName":514,"dataGaLocation":461},"/terms/","terms of use",{"text":516,"config":517},"Privacy statement",{"href":518,"dataGaName":519,"dataGaLocation":461},"/privacy/","privacy statement",{"text":521,"config":522},"Cookie preferences",{"dataGaName":523,"dataGaLocation":461,"id":524,"isOneTrustButton":27},"cookie preferences","ot-sdk-btn",{"title":85,"links":526,"subMenu":535},[527,531],{"text":528,"config":529},"DevSecOps platform",{"href":67,"dataGaName":530,"dataGaLocation":461},"devsecops platform",{"text":532,"config":533},"AI-Assisted Development",{"href":74,"dataGaName":534,"dataGaLocation":461},"ai-assisted development",[536],{"title":537,"links":538},"Topics",[539,543,548,553,558,563,568,573],{"text":540,"config":541},"CICD",{"href":542,"dataGaName":32,"dataGaLocation":461},"/topics/ci-cd/",{"text":544,"config":545},"GitOps",{"href":546,"dataGaName":547,"dataGaLocation":461},"/topics/gitops/","gitops",{"text":549,"config":550},"DevOps",{"href":551,"dataGaName":552,"dataGaLocation":461},"/topics/devops/","devops",{"text":554,"config":555},"Version Control",{"href":556,"dataGaName":557,"dataGaLocation":461},"/topics/version-control/","version control",{"text":559,"config":560},"DevSecOps",{"href":561,"dataGaName":562,"dataGaLocation":461},"/topics/devsecops/","devsecops",{"text":564,"config":565},"Cloud Native",{"href":566,"dataGaName":567,"dataGaLocation":461},"/topics/cloud-native/","cloud native",{"text":569,"config":570},"AI for Coding",{"href":571,"dataGaName":572,"dataGaLocation":461},"/topics/devops/ai-for-coding/","ai for coding",{"text":574,"config":575},"Agentic AI",{"href":576,"dataGaName":577,"dataGaLocation":461},"/topics/agentic-ai/","agentic ai",{"title":579,"links":580},"Solutions",[581,583,585,590,594,597,601,604,606,609,612,617],{"text":126,"config":582},{"href":121,"dataGaName":126,"dataGaLocation":461},{"text":115,"config":584},{"href":99,"dataGaName":100,"dataGaLocation":461},{"text":586,"config":587},"Agile development",{"href":588,"dataGaName":589,"dataGaLocation":461},"/solutions/agile-delivery/","agile delivery",{"text":591,"config":592},"SCM",{"href":111,"dataGaName":593,"dataGaLocation":461},"source code management",{"text":540,"config":595},{"href":104,"dataGaName":596,"dataGaLocation":461},"continuous integration & delivery",{"text":598,"config":599},"Value stream management",{"href":154,"dataGaName":600,"dataGaLocation":461},"value stream management",{"text":544,"config":602},{"href":603,"dataGaName":547,"dataGaLocation":461},"/solutions/gitops/",{"text":164,"config":605},{"href":166,"dataGaName":167,"dataGaLocation":461},{"text":607,"config":608},"Small business",{"href":171,"dataGaName":172,"dataGaLocation":461},{"text":610,"config":611},"Public sector",{"href":176,"dataGaName":177,"dataGaLocation":461},{"text":613,"config":614},"Education",{"href":615,"dataGaName":616,"dataGaLocation":461},"/solutions/education/","education",{"text":618,"config":619},"Financial services",{"href":620,"dataGaName":621,"dataGaLocation":461},"/solutions/finance/","financial services",{"title":184,"links":623},[624,626,628,630,633,635,637,639,641,643,645,647],{"text":196,"config":625},{"href":198,"dataGaName":199,"dataGaLocation":461},{"text":201,"config":627},{"href":203,"dataGaName":204,"dataGaLocation":461},{"text":206,"config":629},{"href":208,"dataGaName":209,"dataGaLocation":461},{"text":211,"config":631},{"href":213,"dataGaName":632,"dataGaLocation":461},"docs",{"text":234,"config":634},{"href":236,"dataGaName":237,"dataGaLocation":461},{"text":229,"config":636},{"href":231,"dataGaName":232,"dataGaLocation":461},{"text":239,"config":638},{"href":241,"dataGaName":242,"dataGaLocation":461},{"text":247,"config":640},{"href":249,"dataGaName":250,"dataGaLocation":461},{"text":252,"config":642},{"href":254,"dataGaName":255,"dataGaLocation":461},{"text":257,"config":644},{"href":259,"dataGaName":260,"dataGaLocation":461},{"text":262,"config":646},{"href":264,"dataGaName":265,"dataGaLocation":461},{"text":267,"config":648},{"href":269,"dataGaName":270,"dataGaLocation":461},{"title":285,"links":650},[651,653,655,657,659,661,663,667,672,674,676,678],{"text":292,"config":652},{"href":294,"dataGaName":287,"dataGaLocation":461},{"text":297,"config":654},{"href":299,"dataGaName":300,"dataGaLocation":461},{"text":305,"config":656},{"href":307,"dataGaName":308,"dataGaLocation":461},{"text":310,"config":658},{"href":312,"dataGaName":313,"dataGaLocation":461},{"text":315,"config":660},{"href":317,"dataGaName":318,"dataGaLocation":461},{"text":320,"config":662},{"href":322,"dataGaName":323,"dataGaLocation":461},{"text":664,"config":665},"Sustainability",{"href":666,"dataGaName":664,"dataGaLocation":461},"/sustainability/",{"text":668,"config":669},"Diversity, inclusion and belonging (DIB)",{"href":670,"dataGaName":671,"dataGaLocation":461},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":325,"config":673},{"href":327,"dataGaName":328,"dataGaLocation":461},{"text":335,"config":675},{"href":337,"dataGaName":338,"dataGaLocation":461},{"text":340,"config":677},{"href":342,"dataGaName":343,"dataGaLocation":461},{"text":679,"config":680},"Modern Slavery Transparency Statement",{"href":681,"dataGaName":682,"dataGaLocation":461},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":684},[685,688,691],{"text":686,"config":687},"Terms",{"href":513,"dataGaName":514,"dataGaLocation":461},{"text":689,"config":690},"Cookies",{"dataGaName":523,"dataGaLocation":461,"id":524,"isOneTrustButton":27},{"text":692,"config":693},"Privacy",{"href":518,"dataGaName":519,"dataGaLocation":461},[695],{"id":696,"title":18,"body":8,"config":697,"content":699,"description":8,"extension":25,"meta":703,"navigation":27,"path":704,"seo":705,"stem":706,"__hash__":707},"blogAuthors/en-us/blog/authors/dov-hershkovitch.yml",{"template":698},"BlogAuthor",{"name":18,"config":700},{"headshot":701,"ctfId":702},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665628/Blog/Author%20Headshots/dhershkovitch-headshot.png","dhershkovitch",{},"/en-us/blog/authors/dov-hershkovitch",{},"en-us/blog/authors/dov-hershkovitch","Iz4JuWpp9w9MyL2i-FC6CmJS1rnfmg76IL873W1AcMU",[709,723,729],{"content":710,"config":721},{"title":711,"description":712,"authors":713,"heroImage":715,"date":716,"body":717,"category":9,"tags":718},"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.",[714],"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/).",[9,719,720],"AI/ML","news",{"featured":11,"template":12,"slug":722},"gitlab-18-11-budget-guardrails-for-gitlab-credits",{"content":724,"config":727},{"title":725,"heroImage":715,"description":726,"date":716,"category":9},"GitLab 18.11 release","This release includes Agentic SAST Vulnerability Resolution, Data Analyst Foundational Agent, CI Expert Agent, and more.",{"featured":11,"template":12,"externalUrl":728},"https://docs.gitlab.com/releases/18/gitlab-18-11-released/",{"content":730,"config":738},{"title":731,"description":732,"authors":733,"heroImage":715,"date":716,"body":735,"category":9,"tags":736},"GitLab 18.11: CI Expert and Data Analyst AI agents target development gaps","Set up CI and query your software development lifecycle data with two new GitLab Duo Agent Platform foundational agents available in GitLab 18.11.",[734],"Corinne Dent","AI-generated code moves faster than the systems around it can keep up with. More code means more merge requests queued, more pipelines to configure, more questions about delivery that nobody has time to answer — and most of the tooling teams rely on wasn't built for this pace.\n\nIn GitLab 18.11, two new foundational agents for Duo Agent Platform address specific gaps in the development lifecycle that AI has largely left untouched:\n* CI Expert Agent (now in beta) focuses on the gap between writing code and getting it into a running pipeline\n* Data Analyst Agent (now generally available) focuses on the gap between shipping code and being able to answer basic questions about how that delivery is actually going.\n\n\nThese are problem areas that couldn't be solved by a general-purpose assistant. A tool running outside GitLab can generate a YAML file or answer a question, but it has no awareness of how your pipelines have historically performed, where failures cluster, or what your actual MR cycle times look like. That context lives in GitLab. These agents do too.\n## Fast CI setup with CI Expert Agent\n\nAI has made it easier than ever to write code. Getting that code into a running pipeline is still something most teams do days, or weeks, later — if at all. The blank-page problem isn't in the editor anymore. The blank page is now in `.gitlab-ci.yml`.\n\nDevelopers who have never configured CI don't know what language detection looks like in YAML, what their test commands should be, or how to validate the result before pushing. Teams either copy a config from a previous project that may not fit, stitch together examples from documentation, or wait for the one person who's done it before. If that person isn't available, CI becomes the thing you'll \"get to later.\" Later becomes never.\n\nWhen CI never happens, the impact shows up everywhere else. Changes ship without a reliable safety net, regressions surface in production instead of in pipelines, and work piles up in bigger, riskier batches because no one wants to be the person who “breaks the build.” Over time, teams normalize working in the dark, often relying on undocumented institutional knowledge and ad-hoc testing, instead of having a fast, predictable feedback loop baked into every change.\n\nCI Expert Agent, now available in beta, removes that friction. It inspects your repository, identifies your language and framework, and proposes a working build and test pipeline tailored to what's actually there — then explains every decision in plain language. The target: a running pipeline in minutes, with no YAML written by hand.\n\nWhat CI Expert Agent does:\n\n* Repo-aware pipeline generation detects language, framework, and test setup \n* Generates valid, runnable build and test configurations   \n* Guided first-pipeline flow with plain-language explanation of each step in Agentic Chat  \n* Native GitLab CI semantics with no config translation required\n\nBecause it runs inside GitLab and sees real pipeline behavior over time, each improvement can build on how teams actually work, not just on static examples.\n\u003Ciframe src=\"https://player.vimeo.com/video/1183458036?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"CI/CD Expert Agent\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cbr>\u003C/br>\n\nCI Expert Agent is available on GitLab.com, Self-Managed, Dedicated; Free, Premium, Ultimate Editions with Duo Agent Platform enabled.\n\n## Query GitLab data in plain language with Data Analyst Agent\n\nAI has sped up how teams ship. Answering basic questions about how that work is going has gotten harder, not easier.\n\nHow long are MRs sitting in review? Which pipelines are slowing teams down? Are deployment targets actually being hit? These questions used to be answerable by glancing at a dashboard. Now, with more code, more teams, and more complexity, the data exists — it's in GitLab — but accessing it still means waiting on an analytics team, filing a dashboard request, or learning GLQL.\n\nData Analyst Agent targets that gap. Ask a natural-language question and get an instant visualization in Agentic Chat. No query language, no dashboard request, no waiting for the answers to be assembled by someone else.\n\nFor example, the agent can answer questions about the following topics for these roles:\n\n* Engineering managers: MR cycle time, throughput by project, where reviews get stuck  \n* Developers: Contribution patterns, flaky tests blocking their MRs, pipeline speed trends  \n* DevOps and platform engineers: Pipeline success/failure rates, runner utilization, deployment frequency  \n* Engineering leadership: Cross-portfolio deployment frequency, project health metrics, lead time comparisons\n\nNow generally available in 18.11, the agent covers MRs, issues, projects, pipelines, and jobs — full software development lifecycle coverage, expanded from the beta scope. Because Data Analyst Agent queries what's already in GitLab, the context is always current, and there's no pipeline to maintain or third-party tool to keep synchronized. Generated GitLab Query Language queries can be copied and used anywhere GitLab Flavored Markdown is supported, with direct export to work items and dashboards on the roadmap.\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1183094817?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"Data Analyst agent demo\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\u003Cbr>\u003C/br>\n\nData Analyst Agent is available on GitLab.com, Self-Managed, Dedicated; Free, Premium and Ultimate Edition with Duo Agent Platform enabled.\n\n## One platform, connected context\n\nBoth agents run inside GitLab, with access to the code, pipelines, issues, and merge requests already there. That's what separates platform-native AI from a disconnected assistant: the context is always current, and it only gets more useful over time. CI Expert Agent and Data Analyst Agent represent two concrete steps toward a platform where AI doesn't just help you write code faster; it helps you understand, ship, and maintain what gets built.\n\n> [Start a free trial of GitLab Duo Agent Platform](https://about.gitlab.com/gitlab-duo/) to experience these foundational AI agents.",[719,737,9],"features",{"featured":27,"template":12,"slug":739},"ci-expert-and-data-analyst-ai-agents-target-development-gaps",{"promotions":741},[742,756,767,778],{"id":743,"categories":744,"header":746,"text":747,"button":748,"image":753},"ai-modernization",[745],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":749,"config":750},"Get your AI maturity score",{"href":751,"dataGaName":752,"dataGaLocation":237},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":754},{"src":755},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":757,"categories":758,"header":759,"text":747,"button":760,"image":764},"devops-modernization",[9,562],"Are you just managing tools or shipping innovation?",{"text":761,"config":762},"Get your DevOps maturity score",{"href":763,"dataGaName":752,"dataGaLocation":237},"/assessments/devops-modernization-assessment/",{"config":765},{"src":766},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":768,"categories":769,"header":770,"text":747,"button":771,"image":775},"security-modernization",[24],"Are you trading speed for security?",{"text":772,"config":773},"Get your security maturity score",{"href":774,"dataGaName":752,"dataGaLocation":237},"/assessments/security-modernization-assessment/",{"config":776},{"src":777},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":779,"paths":780,"header":783,"text":784,"button":785,"image":790},"github-azure-migration",[781,782],"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":786,"config":787},"See how GitLab compares to GitHub",{"href":788,"dataGaName":789,"dataGaLocation":237},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":791},{"src":766},{"header":793,"blurb":794,"button":795,"secondaryButton":800},"Start building faster today","See what your team can do with the intelligent orchestration platform for DevSecOps.\n",{"text":796,"config":797},"Get your free trial",{"href":798,"dataGaName":45,"dataGaLocation":799},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":499,"config":801},{"href":49,"dataGaName":50,"dataGaLocation":799},1776444481436]