[{"data":1,"prerenderedAt":703},["ShallowReactive",2],{"/en-us/blog/how-to-configure-sidekiq-for-gitlab-at-scale/":3,"navigation-en-us":32,"banner-en-us":449,"footer-en-us":464,"Craig Miskell":675,"next-steps-en-us":688},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"seo":8,"content":16,"config":22,"_id":25,"_type":26,"title":27,"_source":28,"_file":29,"_stem":30,"_extension":31},"/en-us/blog/how-to-configure-sidekiq-for-gitlab-at-scale","blog",false,"",{"title":9,"description":10,"ogTitle":9,"ogDescription":10,"noIndex":6,"ogImage":11,"ogUrl":12,"ogSiteName":13,"ogType":14,"canonicalUrls":12,"schema":15},"How to configure Sidekiq for specialized or large-scale GitLab instances","This tutorial unpacks how to configure Sidekiq that suits your GitLab deployment.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667068/Blog/Hero%20Images/sidekiqmountain.jpg","https://about.gitlab.com/blog/how-to-configure-sidekiq-for-gitlab-at-scale","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to configure Sidekiq for specialized or large-scale GitLab instances\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Craig Miskell\"}],\n        \"datePublished\": \"2021-09-27\",\n      }",{"title":9,"description":10,"authors":17,"heroImage":11,"date":19,"body":20,"category":21},[18],"Craig Miskell","2021-09-27","\nConfiguring Sidekiq in your own deployment of GitLab is a little complicated, but entirely possible. In this blog post, we share how to set up Sidekiq for GitLab in special cases and at a large scale by sharing some exmaples that may be useful to you.\n\n## Why consider special configuration?\n\nWhile Sidekiq (both in general, and in a GitLab deployment) will usually _just work_ most of the time, there can be some sharp edges and limits. Raw scale is a clear and obvious driver for needing to take action, and although it may be fine to simply scale out multiple Sidekiq nodes each listening to all the queues, at some point:\n\n1. The uniqueness of workload distribution and job characteristics may require dedicated workers, either sharded on job attributes (as for GitLab.com), or specific workers (based on your workloads), or\n1. Simple saturation on Redis means you need to listen to fewer queues\n\n**[We share [all we learned about configuring Sidekiq on GitLab.com](/blog/specialized-sidekiq-configuration-lessons-from-gitlab-dot-com/)]**\n\n### Example: Demo systems\n\nIn early 2021, our Demo Systems team were running a GitLab deployment for training purposes. Many users would join a training session where the first task was to import a sample project into the provided GitLab instance to work on further during the class. Imports are implemented with a Sidekiq job because they can take anything from a few seconds to hours. What the Demo Systems team found was that the default Sidekiq configuration simply couldn't keep up. The deployment wasn't huge, and neither was the user count, it was the very specific usage of the system that ran into difficulties. So, the team split off a dedicated Sidekiq VM for running imports, with suitably tuned concurrency (based on CPU contention), CPU + memory, and number of workers.\n\n**[[Discover how we scaled our use of Sidekiq on a GitLab instance](/blog/scaling-our-use-of-sidekiq/)]**\n\nThe key lesson here is that large scale isn't always the driver for customizing Sidekiq configuration, and the reason may be specific to your workloads, which means first you have to be able to identify the pain points.\n\n### Using metrics to identify problems\n\n{: #using-metrics-to-identify-problems}\nUser experience may tell you something isn't going well, but how do you tell where the actual problem lies? The GitLab UI exposes the Sidekiq UI to administrators, at `/admin/background_jobs` – in the 'Queues' tab, you can see how many jobs are currently pending, and a breakdown by queue. However, that is a snapshot of a point-in-time, and stored metrics/graphs are better for long term visibility, particularly for figuring out what happened an hour ago when someone reported slow pipelines, or to debug that thing that happens twice a day but never when anyone is watching.\n\nTo get some visibility, consider installing [gitlab-exporter](https://gitlab.com/gitlab-org/gitlab-exporter/) on (or pointed to) your Redis nodes, with:\n\n* `probe_queues` enabled to get the `sidekiq_queue_size` metric, and/or\n* `probe_jobs_limit` to get `sidekiq_enqueued_jobs`.\n\n`sidekiq_queue_size` reports the length of the all the Sidekiq queues in Redis (equivalent to the data exposed by the Sidekiq UI), but now it's exposed as a Prometheus metric for scraping and graphing. `sidekiq_enqueued_jobs` deserializes the job descriptions as well, meaning it can look inside a routing rule-based named queue with more than one class of jobs in it, and report the distribution of work by class. It has to limit (hence the name) the inspection to the first 1000 jobs in any given queue to contain the potential impact of blocking Redis with many calls to [LRANGE](https://redis.io/commands/lrange) with large responses. Usually this situation is fine. If you have > 1000 jobs in any given queue for a non-trivial amount of time, just knowing what's at the head of the queue is likely sufficient and `sidekiq_queue_size` will still show you the full magnitude of the backlog.\n\nIf we were to really simplify it - because there are always exceptions - both those metrics should be at or close to 0 most of the time. In practice, there's often small, brief spikes when batches of work land and cannot be processed immediately, and it may be quite acceptable for some large/slow jobs to be queued for some significant time (e.g., project exports). But a prolonged backlog (or perpetual growth) indicates some class of work is not being processed, either at all, or \"fast enough\" to keep up. If your team is encountering these problems, it might be time to customize your Sidekiq configuration.\n\nHowever the backlog in queues may not be the whole story – queuing might be occurring because all your Sidekiq workers are busy with long-running jobs, causing all the other jobs to stall. To observe that you need the `sidekiq_running_jobs` metric, which can be scraped from the [sidekiq exporter](https://docs.gitlab.com/ee/administration/monitoring/prometheus/gitlab_metrics.html#sidekiq-metrics). This is enabled by default on port 8082 for Omnibus, and 3807 in Kubernetes when using our helmcharts. Graphing `sum by (worker) (sidekiq_running_jobs)` will show you what your Sidekiq workers are actively up to right now, and may highlight which worker/queue is causing the problem.\n\nConsider also keeping an eye on your Redis CPU usage – on a modern CPU at smaller scales there's a lot of headroom, but if you're at the point of considering a specialized Sidekiq configuration, now is the time to add a little monitoring and alerting so it doesn't sneak up on you in the future. We use [Process Exporter](https://github.com/ncabatoff/process-exporter) inspecting the `redis-server` process, with `threads=true` (on the command line) to get per-thread details. In Prometheus we use `sum by (threadname) (rate(namedprocess_namegroup_thread_cpu_seconds_total[1m]))`. On Redis 6, the core thread is named 'redis-server'. As always, set your alert level so that you won't get false positives, but will have plenty of headway before saturation becomes a real problem.\n\n### How to customize your Sidekiq configuration\n\nAfter identifying one or more queues/workers that are backed up, the main task is to get more Sidekiq processing power deployed. As mentioned above, it may be sufficient to simply add one or more [Sidekiq nodes](https://docs.gitlab.com/ee/administration/sidekiq/index.html) or Sidekiq workload in Kubernetes, allowing you to listen to all the queues in a default configuration. If you choose this approach, make sure you're keeping an eye on Redis CPU per the [metrics](#using-metrics-to-identify-problems) above.\n\nAn alternative is to choose to provision some dedicated Sidekiq processing for just the problem work. It could even be said that any complex configuration of Sidekiq for GitLab is just the result of a series of these decisions, progressively adding dedicated processing for specific workloads with a \"catchall\" or \"default\" workload picking up the rest, so I'll describe just one such step and you can take it as far as you need.\n\nThere is a critical decision to make first, and that's whether to:\n\n1. use queue-selectors on the workers and continue with a queue per worker for all jobs, or\n1. use routing rules.\n\nAnd if using routing rules, decide whether to:\n\n1. Go entirely to one-queue-per-shard, or\n1. Use a mix of custom-named queues and the default worker-named queues.\n\nHaving worked in this area for a little over a year now, **I strongly recommend using routing rules and one-queue-per-shard** for the following reasons:\n\n1. Routing rules are more obvious in their effect/ordering than trying to configure disjointed sets of queues across Sidekiq workloads,\n1. Correlating the target queue names in routing rules with the names of queues listened to by workers is simpler,\n1. There is *far* less complexity in configuring the default/catchall workers,\n1. Load on Redis is significantly reduced with fewer named queues.\n\nIt may be easier to see why with an example. In the next section, we run through an example where we assume that you want to provide dedicated resources for `project_exports` because it sees heavy use, and Sidekiq is regularly spending all it's time on that. We'll skip the early phase and assume that you have identified from metrics that the queue name is project_export.\n\n#### Using queue-selectors only\n\nLet's say you want to continue to use one queue per worker and configure each Sidekiq workload to listen to a subset of jobs using queue selectors. The syntax and location for configuring queue selectors is available in our documentation under [Queue selector](https://docs.gitlab.com/ee/administration/sidekiq/extra_sidekiq_processes.html) and [Worker matcher query](https://docs.gitlab.com/ee/administration/sidekiq/processing_specific_job_classes.html) sections.\n\nAfter creating your new, dedicated Sidekiq workload, configure this in `gitlab.rb` on that workload:\n\n```ruby\nsidekiq['enable'] = true\nsidekiq['queue_selector'] = true\nsidekiq['queue_groups'] = [ 'name=project_export' ]\n```\n\nKeep in mind that this will only run one Sidekiq process which, while multithreaded with one job potentially executing on each thread, can only use one CPU – read up on [multiple processes](https://docs.gitlab.com/ee/administration/sidekiq/extra_sidekiq_processes.html) and [concurrency threading](https://about.gitlab.com/blog/specialized-sidekiq-configuration-lessons-from-gitlab-dot-com/) for a little more detail, but in short, if you had a 4 CPU VM and you wanted to run 4 project_export processes, you'd configure gitlab.rb like this:\n\n```ruby\nsidekiq['enable'] = true\nsidekiq['queue_selector'] = true\nsidekiq['queue_groups'] = [ 'name=project_export', 'name=project_export', 'name=project_export', 'name=project_export' ]\n```\n\nThis also reveals another approach. If your existing workload is running somewhere with spare CPU you could add processes with different sets of queues, gaining some control of workload prioritization without having to deploy new compute resources. For example:\n\n```ruby\nsidekiq['enable'] = true\nsidekiq['queue_selector'] = true\nsidekiq['queue_groups'] = [ 'name=project_export', 'name!=project_export' ]\n```\n\nThis may look a little odd at first glance, but it means that one process will be listening to `project_export`, and the other will be listening to every queue that _isn't_ project_export.\n\nA couple of caveats:\n\n1. Concurrency (threading) is set once in `gitlab.rb`, so all jobs running on that node will need to be compatible with that concurrency. Read up on [Concurrency (threading) in the previous blog post](/blog/specialized-sidekiq-configuration-lessons-from-gitlab-dot-com/) to learn more.\n1. Using the GitLab helmcharts, each pod only runs one process, so there you'd adjust maxReplicas instead.\n\nSpeaking of helmcharts, these have the queue-selector configured with the [`queues`](https://docs.gitlab.com/charts/charts/gitlab/sidekiq/#queues) attribute of the pod:\n\n```\nqueues: name=project_export\n```\n\nWhere, despite being named `queues`, it can take the full queue-selector expression.\n\nAfter these configurations, your new workload will be listening exclusively to the `project_export` queue/worker. But what is to stop your original workload from also running `project_export`? Absolutely nothing! A default/baseline workload of Sidekiq for GitLab will listen on all the queues. This **may** be acceptable in a simple case – you've provided additional capacity dedicated to the named queue, and occasionally those jobs will still run on the original Sidekiq. In practice, because of the way Sidekiq uses BRPOP with a randomized order of queues, and how Redis distributes work when clients are already waiting on a named queue, the new dedicated workload will most likely pick up the **vast** majority of the work on that queue. But this may not isolate problem work as much as you desire. This could also lead to difficulty in reasoning clearly about what the system is going to do as your customization grows and becomes more specific. Therefore, I strongly recommend that you ensure the sets of queues are disjoint (that is, no overlap). The final step is to configure your original/default Sidekiq with either:\n\n```ruby\nsidekiq['enable'] = true\nsidekiq['negate'] = true\nsidekiq['queue_selector'] = true\nsidekiq['queue_groups'] = [ 'name=project_export' ]\n\n```\n\nor\n\n```ruby\nsidekiq['enable'] = true\nsidekiq['queue_selector'] = true\nsidekiq['queue_groups'] = [ \"name!=project_export\" ]\n```\n\nThen, as you add more customized workloads in future steps, you would extend the expression to exclude the work that is being picked up elsewhere, e.g., in the negate case if you had added a further workload executing only `feature_category=importers`:\n\n```ruby\nsidekiq['negate'] = true\nsidekiq['queue_groups'] = [ 'name=project_export&feature_category=importers' ]\n```\n\nThis is where setting `negate` to \"true\" can be better – this catchall/default expression can be a simple concatenation of the expressions used on every other workload, separated with `&`. The expression may end up complex, but it can be generated trivially with code. Not using negate and inverting the operators works for simple cases, but may run into difficulty expressing edge cases when the individual expressions become more nuanced or complicated.\n\n#### Use routing rules\n\nAnother option is to use [routing rules](https://docs.gitlab.com/ee/administration/sidekiq/processing_specific_job_classes.html) to achieve the same thing. First, add a new Sidekiq workload configured with:\n\n```ruby\nsidekiq['enable'] = true\nsidekiq['queue_selector'] = false # This is the default and is included only to be explicit\nsidekiq['queue_groups'] = [ 'export' ]\n```\n\nAs in the queue-selector approach, you can run more than one by repeating the expression in queue_groups:\n\n```ruby\nsidekiq['queue_groups'] = [ 'export', 'export', 'export', 'export' ]\n```\n\nWhen using [helm charts](https://docs.gitlab.com/charts/charts/gitlab/sidekiq/index.html#queues) it would be simply the following in the Sidekiq pod definition:\n\n```yaml\nqueues: name=export\n```\n\nThis is simply explicitly naming queues, but having made up an arbitrary named \"export\" rather than using a queue name derived from the job class. Next, and most importantly, add the following to `gitlab.rb` on **all** your workloads. In the queue-selector approach, we only had to configure the Sidekiq workload, but here we need to ensure that **everywhere that enqueues Sidekiq jobs has the routing rules** – meaning anywhere running the Rails portion of GitLab, i.e., puma (web) as well as Sidekiq:\n\n```ruby\nsidekiq['routing_rules'] = [\n  ['name=project_export', 'export'],\n  ['*', nil]\n]\n```\n\nAnd when using [helmcharts](https://docs.gitlab.com/charts/charts/globals.html#sidekiq-routing-rules-settings) deployment:\n\n```yaml\nglobal:\n  appConfig:\n    sidekiq:\n      routingRules:\n      - [\"name=project_export\", \"export\"]\n      - [\"*\", null]\n```\n\nSome caveats:\n\n1. You most likely want a workload listening to the new queue **before** reconfiguring the routing rules, otherwise jobs will be put into the queue with nothing ready to execute them.\n1. The destination name (`export`) is arbitrary, but must match exactly in Sidekiq queue configuration and the routing rules.\n1. In `gitlab.rb` we use \"nil\", but in YAML we must use \"null\".\n\nBy using null/nil as the target for `*` this example continues to use the default worker-per-queue strategy for all the other jobs. So you will have gained routing/prioritization control, but Redis will still be doing a lot of work to listen to the other 440+ queues. To avoid that, you can change the target of the final `*` routing rule to \"default\", e.g.\n\n```ruby\nsidekiq['routing_rules'] = [\n  ['name=project_export', 'export'],\n  ['*', 'default']\n]\n```\n\nIn this context \"default\" is literal. Conveniently there is a built-in 'default' queue that GitLab Sidekiq listens to, although nothing uses it out of the box. These rules will route all remaining jobs to that queue and the original/default Sidekiq workload will pick them up immediately. Then, at your convenience, you can reconfigure the original Sidekiq workload to listen **only** to \"default\" in the same way you configured the new workload to listen to \"export\", and gain the performance benefit in Redis.\n\n#### Edge cases\n\nThe routing rules example above is simplified slightly for clarity. In practice there are still a small set of queues that need to remain in their **original** dedicated named queue for a variety of reasons. We're working on resolving the blockers, but that may take a while to work through. You can follow along in [this issue](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1087), or you can keep an eye on the routingRules [configuration for GitLab.com](https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/gitlab-com/-/blob/master/releases/gitlab/values/gprd.yaml.gotmpl) – special cases will be at the very top of the rules, routed by worker_name or name, and there will be a comment about why and a link to any related issues, which will help you determine if each is relevant to your needs. Some special cases may be there for GitLab.com-specific reasons and may not be generally applicable. In the long term we expect the list of special cases to reduce, not increase.\n\nAlso take into consideration that the special cases may be used for features that you do not use. Specifically:\n\n1. EmailReceiverWorker & ServiceDeskEmailReceiverWorker are for [Incoming email](https://docs.gitlab.com/ee/administration/incoming_email.html)\n1. ProjectImportScheduleWorker is for project mirroring\n\nSo you might be able to just ignore them, or route them to a queue that no worker is listening to and alert if `sidekiq_queue_size` is above zero on those queues.\n\n### Migrating when using routing rules\n\nThere is one more thing to note. When migrating an active GitLab deployment (rather than configuring this from scratch on a fresh GitLab deployment) the order of steps taken is important, and there's one additional step I haven't mentioned yet:\n\n1. Ensure a Sidekiq workload is listening to the new queues\n1. Change the routing rules\n1. Run the Sidekiq job migration [Rake task](https://docs.gitlab.com/ee/administration/sidekiq/sidekiq_job_migration.html)\n   * Any jobs that are scheduled for the future will be migrated to the new queue for correct execution\n1. Stop listening to queues that are no longer in use\n\nThese steps will ensure a clean migration. If you do not do step 3, then at future times deferred jobs will be picked up out of their holding place in Redis and might be scheduled to a queue that no Sidekiq is listening to anymore. This is exactly the process we took on GitLab.com when migrating our configuration to one queue per shard.\n\n## Simplifying complex Sidekiq configurations\n\nAny complicated Sidekiq configuration can be broken down into a series of these individual migrations, identifying (using metrics) queues or workers that need specialized handling, spinning up a workload to run them, and then sending/routing the jobs to this new workload.\n\nCover image by [Jerry Zhang](https://unsplash.com/@z734923105) on [Unsplash](https://www.unsplash.com)\n{: .note}\n","engineering",{"slug":23,"featured":6,"template":24},"how-to-configure-sidekiq-for-gitlab-at-scale","BlogPost","content:en-us:blog:how-to-configure-sidekiq-for-gitlab-at-scale.yml","yaml","How To Configure Sidekiq For Gitlab At Scale","content","en-us/blog/how-to-configure-sidekiq-for-gitlab-at-scale.yml","en-us/blog/how-to-configure-sidekiq-for-gitlab-at-scale","yml",{"_path":33,"_dir":34,"_draft":6,"_partial":6,"_locale":7,"data":35,"_id":445,"_type":26,"title":446,"_source":28,"_file":447,"_stem":448,"_extension":31},"/shared/en-us/main-navigation","en-us",{"logo":36,"freeTrial":41,"sales":46,"login":51,"items":56,"search":386,"minimal":417,"duo":436},{"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,101,197,202,307,367],{"text":58,"config":59,"cards":61,"footer":84},"Platform",{"dataNavLevelOne":60},"platform",[62,68,76],{"title":58,"description":63,"link":64},"The most comprehensive AI-powered DevSecOps Platform",{"text":65,"config":66},"Explore our Platform",{"href":67,"dataGaName":60,"dataGaLocation":40},"/platform/",{"title":69,"description":70,"link":71},"GitLab Duo (AI)","Build software faster with AI at every stage of development",{"text":72,"config":73},"Meet GitLab Duo",{"href":74,"dataGaName":75,"dataGaLocation":40},"/gitlab-duo/","gitlab duo ai",{"title":77,"description":78,"link":79},"Why GitLab","10 reasons why Enterprises choose GitLab",{"text":80,"config":81},"Learn more",{"href":82,"dataGaName":83,"dataGaLocation":40},"/why-gitlab/","why gitlab",{"title":85,"items":86},"Get started with",[87,92,97],{"text":88,"config":89},"Platform Engineering",{"href":90,"dataGaName":91,"dataGaLocation":40},"/solutions/platform-engineering/","platform engineering",{"text":93,"config":94},"Developer Experience",{"href":95,"dataGaName":96,"dataGaLocation":40},"/developer-experience/","Developer experience",{"text":98,"config":99},"MLOps",{"href":100,"dataGaName":98,"dataGaLocation":40},"/topics/devops/the-role-of-ai-in-devops/",{"text":102,"left":103,"config":104,"link":106,"lists":110,"footer":179},"Product",true,{"dataNavLevelOne":105},"solutions",{"text":107,"config":108},"View all Solutions",{"href":109,"dataGaName":105,"dataGaLocation":40},"/solutions/",[111,136,158],{"title":112,"description":113,"link":114,"items":119},"Automation","CI/CD and automation to accelerate deployment",{"config":115},{"icon":116,"href":117,"dataGaName":118,"dataGaLocation":40},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[120,124,128,132],{"text":121,"config":122},"CI/CD",{"href":123,"dataGaLocation":40,"dataGaName":121},"/solutions/continuous-integration/",{"text":125,"config":126},"AI-Assisted Development",{"href":74,"dataGaLocation":40,"dataGaName":127},"AI assisted development",{"text":129,"config":130},"Source Code Management",{"href":131,"dataGaLocation":40,"dataGaName":129},"/solutions/source-code-management/",{"text":133,"config":134},"Automated Software Delivery",{"href":117,"dataGaLocation":40,"dataGaName":135},"Automated software delivery",{"title":137,"description":138,"link":139,"items":144},"Security","Deliver code faster without compromising security",{"config":140},{"href":141,"dataGaName":142,"dataGaLocation":40,"icon":143},"/solutions/security-compliance/","security and compliance","ShieldCheckLight",[145,148,153],{"text":146,"config":147},"Security & Compliance",{"href":141,"dataGaLocation":40,"dataGaName":146},{"text":149,"config":150},"Software Supply Chain Security",{"href":151,"dataGaLocation":40,"dataGaName":152},"/solutions/supply-chain/","Software supply chain security",{"text":154,"config":155},"Compliance & Governance",{"href":156,"dataGaLocation":40,"dataGaName":157},"/solutions/continuous-software-compliance/","Compliance and governance",{"title":159,"link":160,"items":165},"Measurement",{"config":161},{"icon":162,"href":163,"dataGaName":164,"dataGaLocation":40},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[166,170,174],{"text":167,"config":168},"Visibility & Measurement",{"href":163,"dataGaLocation":40,"dataGaName":169},"Visibility and Measurement",{"text":171,"config":172},"Value Stream Management",{"href":173,"dataGaLocation":40,"dataGaName":171},"/solutions/value-stream-management/",{"text":175,"config":176},"Analytics & Insights",{"href":177,"dataGaLocation":40,"dataGaName":178},"/solutions/analytics-and-insights/","Analytics and insights",{"title":180,"items":181},"GitLab for",[182,187,192],{"text":183,"config":184},"Enterprise",{"href":185,"dataGaLocation":40,"dataGaName":186},"/enterprise/","enterprise",{"text":188,"config":189},"Small Business",{"href":190,"dataGaLocation":40,"dataGaName":191},"/small-business/","small business",{"text":193,"config":194},"Public Sector",{"href":195,"dataGaLocation":40,"dataGaName":196},"/solutions/public-sector/","public sector",{"text":198,"config":199},"Pricing",{"href":200,"dataGaName":201,"dataGaLocation":40,"dataNavLevelOne":201},"/pricing/","pricing",{"text":203,"config":204,"link":206,"lists":210,"feature":294},"Resources",{"dataNavLevelOne":205},"resources",{"text":207,"config":208},"View all resources",{"href":209,"dataGaName":205,"dataGaLocation":40},"/resources/",[211,244,266],{"title":212,"items":213},"Getting started",[214,219,224,229,234,239],{"text":215,"config":216},"Install",{"href":217,"dataGaName":218,"dataGaLocation":40},"/install/","install",{"text":220,"config":221},"Quick start guides",{"href":222,"dataGaName":223,"dataGaLocation":40},"/get-started/","quick setup checklists",{"text":225,"config":226},"Learn",{"href":227,"dataGaLocation":40,"dataGaName":228},"https://university.gitlab.com/","learn",{"text":230,"config":231},"Product documentation",{"href":232,"dataGaName":233,"dataGaLocation":40},"https://docs.gitlab.com/","product documentation",{"text":235,"config":236},"Best practice videos",{"href":237,"dataGaName":238,"dataGaLocation":40},"/getting-started-videos/","best practice videos",{"text":240,"config":241},"Integrations",{"href":242,"dataGaName":243,"dataGaLocation":40},"/integrations/","integrations",{"title":245,"items":246},"Discover",[247,252,256,261],{"text":248,"config":249},"Customer success stories",{"href":250,"dataGaName":251,"dataGaLocation":40},"/customers/","customer success stories",{"text":253,"config":254},"Blog",{"href":255,"dataGaName":5,"dataGaLocation":40},"/blog/",{"text":257,"config":258},"Remote",{"href":259,"dataGaName":260,"dataGaLocation":40},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":262,"config":263},"TeamOps",{"href":264,"dataGaName":265,"dataGaLocation":40},"/teamops/","teamops",{"title":267,"items":268},"Connect",[269,274,279,284,289],{"text":270,"config":271},"GitLab Services",{"href":272,"dataGaName":273,"dataGaLocation":40},"/services/","services",{"text":275,"config":276},"Community",{"href":277,"dataGaName":278,"dataGaLocation":40},"/community/","community",{"text":280,"config":281},"Forum",{"href":282,"dataGaName":283,"dataGaLocation":40},"https://forum.gitlab.com/","forum",{"text":285,"config":286},"Events",{"href":287,"dataGaName":288,"dataGaLocation":40},"/events/","events",{"text":290,"config":291},"Partners",{"href":292,"dataGaName":293,"dataGaLocation":40},"/partners/","partners",{"backgroundColor":295,"textColor":296,"text":297,"image":298,"link":302},"#2f2a6b","#fff","Insights for the future of software development",{"altText":299,"config":300},"the source promo card",{"src":301},"/images/navigation/the-source-promo-card.svg",{"text":303,"config":304},"Read the latest",{"href":305,"dataGaName":306,"dataGaLocation":40},"/the-source/","the source",{"text":308,"config":309,"lists":311},"Company",{"dataNavLevelOne":310},"company",[312],{"items":313},[314,319,325,327,332,337,342,347,352,357,362],{"text":315,"config":316},"About",{"href":317,"dataGaName":318,"dataGaLocation":40},"/company/","about",{"text":320,"config":321,"footerGa":324},"Jobs",{"href":322,"dataGaName":323,"dataGaLocation":40},"/jobs/","jobs",{"dataGaName":323},{"text":285,"config":326},{"href":287,"dataGaName":288,"dataGaLocation":40},{"text":328,"config":329},"Leadership",{"href":330,"dataGaName":331,"dataGaLocation":40},"/company/team/e-group/","leadership",{"text":333,"config":334},"Team",{"href":335,"dataGaName":336,"dataGaLocation":40},"/company/team/","team",{"text":338,"config":339},"Handbook",{"href":340,"dataGaName":341,"dataGaLocation":40},"https://handbook.gitlab.com/","handbook",{"text":343,"config":344},"Investor relations",{"href":345,"dataGaName":346,"dataGaLocation":40},"https://ir.gitlab.com/","investor relations",{"text":348,"config":349},"Trust Center",{"href":350,"dataGaName":351,"dataGaLocation":40},"/security/","trust center",{"text":353,"config":354},"AI Transparency Center",{"href":355,"dataGaName":356,"dataGaLocation":40},"/ai-transparency-center/","ai transparency center",{"text":358,"config":359},"Newsletter",{"href":360,"dataGaName":361,"dataGaLocation":40},"/company/contact/","newsletter",{"text":363,"config":364},"Press",{"href":365,"dataGaName":366,"dataGaLocation":40},"/press/","press",{"text":368,"config":369,"lists":370},"Contact us",{"dataNavLevelOne":310},[371],{"items":372},[373,376,381],{"text":47,"config":374},{"href":49,"dataGaName":375,"dataGaLocation":40},"talk to sales",{"text":377,"config":378},"Get help",{"href":379,"dataGaName":380,"dataGaLocation":40},"/support/","get help",{"text":382,"config":383},"Customer portal",{"href":384,"dataGaName":385,"dataGaLocation":40},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":387,"login":388,"suggestions":395},"Close",{"text":389,"link":390},"To search repositories and projects, login to",{"text":391,"config":392},"gitlab.com",{"href":54,"dataGaName":393,"dataGaLocation":394},"search login","search",{"text":396,"default":397},"Suggestions",[398,400,404,406,410,414],{"text":69,"config":399},{"href":74,"dataGaName":69,"dataGaLocation":394},{"text":401,"config":402},"Code Suggestions (AI)",{"href":403,"dataGaName":401,"dataGaLocation":394},"/solutions/code-suggestions/",{"text":121,"config":405},{"href":123,"dataGaName":121,"dataGaLocation":394},{"text":407,"config":408},"GitLab on AWS",{"href":409,"dataGaName":407,"dataGaLocation":394},"/partners/technology-partners/aws/",{"text":411,"config":412},"GitLab on Google Cloud",{"href":413,"dataGaName":411,"dataGaLocation":394},"/partners/technology-partners/google-cloud-platform/",{"text":415,"config":416},"Why GitLab?",{"href":82,"dataGaName":415,"dataGaLocation":394},{"freeTrial":418,"mobileIcon":423,"desktopIcon":428,"secondaryButton":431},{"text":419,"config":420},"Start free trial",{"href":421,"dataGaName":45,"dataGaLocation":422},"https://gitlab.com/-/trials/new/","nav",{"altText":424,"config":425},"Gitlab Icon",{"src":426,"dataGaName":427,"dataGaLocation":422},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":424,"config":429},{"src":430,"dataGaName":427,"dataGaLocation":422},"/images/brand/gitlab-logo-type.svg",{"text":432,"config":433},"Get Started",{"href":434,"dataGaName":435,"dataGaLocation":422},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/compare/gitlab-vs-github/","get started",{"freeTrial":437,"mobileIcon":441,"desktopIcon":443},{"text":438,"config":439},"Learn more about GitLab Duo",{"href":74,"dataGaName":440,"dataGaLocation":422},"gitlab duo",{"altText":424,"config":442},{"src":426,"dataGaName":427,"dataGaLocation":422},{"altText":424,"config":444},{"src":430,"dataGaName":427,"dataGaLocation":422},"content:shared:en-us:main-navigation.yml","Main Navigation","shared/en-us/main-navigation.yml","shared/en-us/main-navigation",{"_path":450,"_dir":34,"_draft":6,"_partial":6,"_locale":7,"title":451,"button":452,"image":456,"config":459,"_id":461,"_type":26,"_source":28,"_file":462,"_stem":463,"_extension":31},"/shared/en-us/banner","is now in public beta!",{"text":80,"config":453},{"href":454,"dataGaName":455,"dataGaLocation":40},"/gitlab-duo/agent-platform/","duo banner",{"config":457},{"src":458},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1753720689/somrf9zaunk0xlt7ne4x.svg",{"layout":460},"release","content:shared:en-us:banner.yml","shared/en-us/banner.yml","shared/en-us/banner",{"_path":465,"_dir":34,"_draft":6,"_partial":6,"_locale":7,"data":466,"_id":671,"_type":26,"title":672,"_source":28,"_file":673,"_stem":674,"_extension":31},"/shared/en-us/main-footer",{"text":467,"source":468,"edit":474,"contribute":479,"config":484,"items":489,"minimal":663},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":469,"config":470},"View page source",{"href":471,"dataGaName":472,"dataGaLocation":473},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":475,"config":476},"Edit this page",{"href":477,"dataGaName":478,"dataGaLocation":473},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":480,"config":481},"Please contribute",{"href":482,"dataGaName":483,"dataGaLocation":473},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":485,"facebook":486,"youtube":487,"linkedin":488},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[490,513,570,599,633],{"title":58,"links":491,"subMenu":496},[492],{"text":493,"config":494},"DevSecOps platform",{"href":67,"dataGaName":495,"dataGaLocation":473},"devsecops platform",[497],{"title":198,"links":498},[499,503,508],{"text":500,"config":501},"View plans",{"href":200,"dataGaName":502,"dataGaLocation":473},"view plans",{"text":504,"config":505},"Why Premium?",{"href":506,"dataGaName":507,"dataGaLocation":473},"/pricing/premium/","why premium",{"text":509,"config":510},"Why Ultimate?",{"href":511,"dataGaName":512,"dataGaLocation":473},"/pricing/ultimate/","why ultimate",{"title":514,"links":515},"Solutions",[516,521,524,526,531,536,540,543,547,552,554,557,560,565],{"text":517,"config":518},"Digital transformation",{"href":519,"dataGaName":520,"dataGaLocation":473},"/topics/digital-transformation/","digital transformation",{"text":146,"config":522},{"href":141,"dataGaName":523,"dataGaLocation":473},"security & compliance",{"text":135,"config":525},{"href":117,"dataGaName":118,"dataGaLocation":473},{"text":527,"config":528},"Agile development",{"href":529,"dataGaName":530,"dataGaLocation":473},"/solutions/agile-delivery/","agile delivery",{"text":532,"config":533},"Cloud transformation",{"href":534,"dataGaName":535,"dataGaLocation":473},"/topics/cloud-native/","cloud transformation",{"text":537,"config":538},"SCM",{"href":131,"dataGaName":539,"dataGaLocation":473},"source code management",{"text":121,"config":541},{"href":123,"dataGaName":542,"dataGaLocation":473},"continuous integration & delivery",{"text":544,"config":545},"Value stream management",{"href":173,"dataGaName":546,"dataGaLocation":473},"value stream management",{"text":548,"config":549},"GitOps",{"href":550,"dataGaName":551,"dataGaLocation":473},"/solutions/gitops/","gitops",{"text":183,"config":553},{"href":185,"dataGaName":186,"dataGaLocation":473},{"text":555,"config":556},"Small business",{"href":190,"dataGaName":191,"dataGaLocation":473},{"text":558,"config":559},"Public sector",{"href":195,"dataGaName":196,"dataGaLocation":473},{"text":561,"config":562},"Education",{"href":563,"dataGaName":564,"dataGaLocation":473},"/solutions/education/","education",{"text":566,"config":567},"Financial services",{"href":568,"dataGaName":569,"dataGaLocation":473},"/solutions/finance/","financial services",{"title":203,"links":571},[572,574,576,578,581,583,585,587,589,591,593,595,597],{"text":215,"config":573},{"href":217,"dataGaName":218,"dataGaLocation":473},{"text":220,"config":575},{"href":222,"dataGaName":223,"dataGaLocation":473},{"text":225,"config":577},{"href":227,"dataGaName":228,"dataGaLocation":473},{"text":230,"config":579},{"href":232,"dataGaName":580,"dataGaLocation":473},"docs",{"text":253,"config":582},{"href":255,"dataGaName":5,"dataGaLocation":473},{"text":248,"config":584},{"href":250,"dataGaName":251,"dataGaLocation":473},{"text":257,"config":586},{"href":259,"dataGaName":260,"dataGaLocation":473},{"text":270,"config":588},{"href":272,"dataGaName":273,"dataGaLocation":473},{"text":262,"config":590},{"href":264,"dataGaName":265,"dataGaLocation":473},{"text":275,"config":592},{"href":277,"dataGaName":278,"dataGaLocation":473},{"text":280,"config":594},{"href":282,"dataGaName":283,"dataGaLocation":473},{"text":285,"config":596},{"href":287,"dataGaName":288,"dataGaLocation":473},{"text":290,"config":598},{"href":292,"dataGaName":293,"dataGaLocation":473},{"title":308,"links":600},[601,603,605,607,609,611,613,617,622,624,626,628],{"text":315,"config":602},{"href":317,"dataGaName":310,"dataGaLocation":473},{"text":320,"config":604},{"href":322,"dataGaName":323,"dataGaLocation":473},{"text":328,"config":606},{"href":330,"dataGaName":331,"dataGaLocation":473},{"text":333,"config":608},{"href":335,"dataGaName":336,"dataGaLocation":473},{"text":338,"config":610},{"href":340,"dataGaName":341,"dataGaLocation":473},{"text":343,"config":612},{"href":345,"dataGaName":346,"dataGaLocation":473},{"text":614,"config":615},"Sustainability",{"href":616,"dataGaName":614,"dataGaLocation":473},"/sustainability/",{"text":618,"config":619},"Diversity, inclusion and belonging (DIB)",{"href":620,"dataGaName":621,"dataGaLocation":473},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":348,"config":623},{"href":350,"dataGaName":351,"dataGaLocation":473},{"text":358,"config":625},{"href":360,"dataGaName":361,"dataGaLocation":473},{"text":363,"config":627},{"href":365,"dataGaName":366,"dataGaLocation":473},{"text":629,"config":630},"Modern Slavery Transparency Statement",{"href":631,"dataGaName":632,"dataGaLocation":473},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":634,"links":635},"Contact Us",[636,639,641,643,648,653,658],{"text":637,"config":638},"Contact an expert",{"href":49,"dataGaName":50,"dataGaLocation":473},{"text":377,"config":640},{"href":379,"dataGaName":380,"dataGaLocation":473},{"text":382,"config":642},{"href":384,"dataGaName":385,"dataGaLocation":473},{"text":644,"config":645},"Status",{"href":646,"dataGaName":647,"dataGaLocation":473},"https://status.gitlab.com/","status",{"text":649,"config":650},"Terms of use",{"href":651,"dataGaName":652,"dataGaLocation":473},"/terms/","terms of use",{"text":654,"config":655},"Privacy statement",{"href":656,"dataGaName":657,"dataGaLocation":473},"/privacy/","privacy statement",{"text":659,"config":660},"Cookie preferences",{"dataGaName":661,"dataGaLocation":473,"id":662,"isOneTrustButton":103},"cookie preferences","ot-sdk-btn",{"items":664},[665,667,669],{"text":649,"config":666},{"href":651,"dataGaName":652,"dataGaLocation":473},{"text":654,"config":668},{"href":656,"dataGaName":657,"dataGaLocation":473},{"text":659,"config":670},{"dataGaName":661,"dataGaLocation":473,"id":662,"isOneTrustButton":103},"content:shared:en-us:main-footer.yml","Main Footer","shared/en-us/main-footer.yml","shared/en-us/main-footer",[676],{"_path":677,"_dir":678,"_draft":6,"_partial":6,"_locale":7,"content":679,"config":683,"_id":685,"_type":26,"title":18,"_source":28,"_file":686,"_stem":687,"_extension":31},"/en-us/blog/authors/craig-miskell","authors",{"name":18,"config":680},{"headshot":681,"ctfId":682},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667372/Blog/Author%20Headshots/cmiskell-headshot.jpg","cmiskell",{"template":684},"BlogAuthor","content:en-us:blog:authors:craig-miskell.yml","en-us/blog/authors/craig-miskell.yml","en-us/blog/authors/craig-miskell",{"_path":689,"_dir":34,"_draft":6,"_partial":6,"_locale":7,"header":690,"eyebrow":691,"blurb":692,"button":693,"secondaryButton":697,"_id":699,"_type":26,"title":700,"_source":28,"_file":701,"_stem":702,"_extension":31},"/shared/en-us/next-steps","Start shipping better software faster","50%+ of the Fortune 100 trust GitLab","See what your team can do with the intelligent\n\n\nDevSecOps platform.\n",{"text":42,"config":694},{"href":695,"dataGaName":45,"dataGaLocation":696},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":47,"config":698},{"href":49,"dataGaName":50,"dataGaLocation":696},"content:shared:en-us:next-steps.yml","Next Steps","shared/en-us/next-steps.yml","shared/en-us/next-steps",1753981624417]