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