[{"data":1,"prerenderedAt":795},["ShallowReactive",2],{"/en-us/blog/one-third-of-what-we-learned-about-ipos-in-taking-gitlab-public":3,"navigation-en-us":37,"banner-en-us":436,"footer-en-us":446,"blog-post-authors-en-us-Sid Sijbrandij":688,"blog-related-posts-en-us-one-third-of-what-we-learned-about-ipos-in-taking-gitlab-public":706,"assessment-promotions-en-us":746,"next-steps-en-us":785},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":25,"isFeatured":12,"meta":26,"navigation":27,"path":28,"publishedDate":20,"seo":29,"stem":33,"tagSlugs":34,"__hash__":36},"blogPosts/en-us/blog/one-third-of-what-we-learned-about-ipos-in-taking-gitlab-public.yml","One Third Of What We Learned About Ipos In Taking Gitlab Public",[7],"sid-sijbrandij",null,"news",{"slug":11,"featured":12,"template":13},"one-third-of-what-we-learned-about-ipos-in-taking-gitlab-public",false,"BlogPost",{"title":15,"description":16,"authors":17,"heroImage":19,"date":20,"body":21,"category":9,"tags":22},"Everything we learned about IPOs in taking GitLab public - Part 4","GitLab co-founder and CEO Sid Sijbrandij shares insights about the process of going public.",[18],"Sid Sijbrandij","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671861/Blog/Hero%20Images/gitlab-logo-500.jpg","2022-10-14","\nIt was this time last year that GitLab (NASDAQ: GTLB) went public and was the first company to [publicly live stream](https://vimeo.com/650088717?embedded=true&source=vimeo_logo&owner=115027220) the entire end-to-end listing day at Nasdaq. To celebrate our 1 year anniversary, I shared an overview of what we learned through our S-1 filing and initial public offering (IPO) process with Sifted, a media outlet focused on topics for startups and innovators (and invested in by the venerable Financial Times), in a three-part series:\n\n1. [Going public in the US? This is the most important document in the process](https://sifted.eu/articles/gitlab-part-one-going-public-us/)\n2. [‘More cowbell!’: Publicly livestreaming GitLab’s Nasdaq listing day & celebrating](https://sifted.eu/articles/gitlabs-nasdaq-listing-part-two/)\n3. [Powered by cookies, not airplanes: Pricing and allocating IPO shares](https://sifted.eu/articles/gitlab-part-three-allocating-ipo-shares/)\n\nBut there is so much more to share around preparing the S-1 filing and initial steps for setting the IPO in motion, including how to work with insurance providers, what to expect from your board, and more - all of which I am including in this blog post.\n\nPart 4 of the series below will cover these areas.\n\n![GitLab team celebrating IPO](https://about.gitlab.com/images/blogimages/teamnasdaq.jpg)\nTeam members celebrating in NYC and remotely\n\n\n## Preparing the S-1 filing\n\nTo get started, here are some things we learned throughout the GitLab IPO:\n\n- **Cheap stock**: We learned that it is common when the SEC reviews the IPO filing to comment on [“cheap stock.”](https://www.pwc.com/us/en/services/consulting/deals/library/cheap-stock.html) Cheap stock refers to equity awards issued to employees ahead of an IPO at a value far less than the IPO price. Cheap stock issues can delay an IPO or stock listing and may result in a cheap stock charge, which is an incremental and often unforeseen stock-based compensation expense. Cheap stock concerns can impact the company’s registration timeline, so it is important to ensure that it is clear to the SEC how your company has been assessing fair-market value for stock-based compensation issued prior to the potential IPO. We reviewed our assumptions we used for valuing the stock for granting and determined our assumptions of the timing of the IPO should have had a higher weighting and took a charge to the company but not to team members.\n\n- **Physical addresses not necessary**: Physical addresses aren’t necessary to file for an IPO. We have been a 100% remote workforce since inception and, as of July 31, 2021, had approximately 1,350 team members in over 65 countries. Operating remotely allows us access to a global talent pool, providing a strong competitive advantage. We wrote [Address Not Applicable in our S-1 filing](https://www.sec.gov/Archives/edgar/data/1653482/000162828021018818/gitlab-sx1.htm#:~:text=Employer%20Identification%20Number) where the address was requested. Initially we received a comment from the SEC regarding an address where investors could send communications to the company, but after providing an explanation about being 100% remote we were able to use the email address reach.gitlab@gitlab.com in the footnote on the cover page.\n\n- **Work remote-first with your S-1 drafting process**: Typically, drafting the S-1 is done in-person over many weeks. The process would involve going to the \"financial printer\" and sitting in a room together and flipping through hardcopy pages one by one. (In San Francisco, the most commonly used financial printer is situated near a sushi restaurant and it’s a custom to convene for sushi afterwards.) Even during the pandemic, some companies were still meeting in person in small groups. We drove a highly efficient process that minimized travel using Zoom, Slack, Workiva, and Google Workspace that spanned just three weeks for our initial S-1 draft. Even auditor reviews were handled remotely. This would typically require a combination of management, outside counsel, and the bankers passing drafts back and forth. Instead, we hosted real-time drafting sessions over Zoom and used shared Google Docs with multiple stakeholders doing real-time editing. We followed the [GitLab process](https://handbook.gitlab.com/) and the way the company works remotely for the S-1. Finally, because we didn’t hold meetings in person, we were able to pull in SMEs (subject matter experts) from throughout the legal and finance teams to answer questions during the diligence process with the bankers. At other companies, this process would have been handled by the Chief Legal Officer and the Chief Financial Officer. This leant itself to more diversity of thought than would typically be possible when constrained by the size of a meeting room. (The one obvious downside is that we didn’t get together afterwards for sushi.)\n\n- **Efficient process for responding to SEC comments**: When you file an S-1 confidentially, the SEC routinely [provides comments back](https://www.sec.gov/divisions/corpfin/cffilingreview). These comments are expected. The S-1 filing is intended to create market transparency by educating all investors. Comments from the SEC seek to ensure that a S-1 is in-depth enough to make investors feel informed. We were able to address the initial 16 comments (an unusually small number) from the SEC and refile quickly. We responded to the first set of comments in one week. This is quite fast to respond to an initial set of comments – 2 weeks is more typical.\n\n- **Founder letter**: These are common in S-1 documents. Most are one or two pages. My [founder letter](/blog/gitlab-inc-takes-the-devops-platform-public/#foundersletter) is longer at 4 pages (though Google’s 2004 letter is over twice as long based on word count). It included a [10-point plan to maintain our startup ethos](https://www.sec.gov/Archives/edgar/data/1653482/000162828021020056/gitlab-424b4.htm) (page 96) inspired by [Amazon’s Day 1 letter](https://s2.q4cdn.com/299287126/files/doc_financials/annual/Shareholderletter97.pdf) explained in a [blog post](https://aws.amazon.com/executive-insights/content/how-amazon-defines-and-operationalizes-a-day-1-culture/) and repeated verbatim in every annual filing since.\n\n- **File the S-1 confidentially**: Form S-1 is a filing required by the U.S. Securities and Exchange Commission for companies planning on going public. Public filings often lead to unsolicited public speculation about the company. Thanks to the [JOBS Act](https://www.sec.gov/spotlight/jobs-act.shtml), if your company meets certain requirements, you can confidentially submit the S-1 form. If your company decides not to go forward with an investor roadshow and IPO, the confidentiality preserves optionality.\n\n- **Know when to be quiet**: There is a [specific quiet period window](https://www.investor.gov/introduction-investing/investing-basics/glossary/quiet-period) leading up to the IPO  and continuing after the listing day when team members and people affiliated with your company (ex. board members) cannot be perceived as hyping the company. We were advised as a best practice to start our Quiet Period once we selected bankers for our IPO. The Quiet Period then continued through the 25 days after our stock started being publicly traded, which included the day of the IPO. It’s important to ensure compliance with laws and regulations governing the IPO and being a public company even before the company is public. The road to IPO is littered with horror stories and unintentional consequences as a result of [“gun jumping”](https://www.investopedia.com/terms/g/gunjumping.asp#:~:text=Gun%2Djumping%20flouts%20the%20rule,its%20IPO%20will%20be%20delayed.). This refers to selectively using financial information that has not been publicly announced. Delaying initial public offerings when companies are ready to go public can significantly disrupt innovation and the negative effects can last for years. One internet giant risked a delayed IPO when an interview granted to Playboy magazine months prior (disclosing key factors about their business) was later published during their quiet period. Another prominent San Francisco-based tech company had its IPO delayed when the CEO granted an interview for an article appearing in the New York Times that the SEC found to violate gun jumping rules. To minimize the risk of violating such laws and regulations, we followed best practices to limit statements to the IPO registration statement and vetted and approved press releases and started vetting our communications as though we were a public company months if not a full year or more before we actually went public. This is because during the IPO process the SEC may scrutinize every statement made by the company or individuals on the company’s behalf, even simple ones. The more communications, the greater the risk of saying something that shouldn’t be said.\nFor example, I couldn’t respond to people who sent their congratulations publicly on social media the day we listed. However, if you look at the [#EveryoneCanContribute hashtag](https://twitter.com/search?q=%23everyonecancontribute&src=typed_query), you’ll notice we did have a flurry of team member celebration tweets on October 14, 2021. To ensure compliance, celebration tweets were pre-written by our communications team and approved by our Legal team.\n\n![GitLab branding in NYC](https://about.gitlab.com/images/blogimages/nycnasdaq.jpg)\nGitLab branding outside the Nasdaq building in Times Square\n\n\n## Setting the IPO in Motion\n\nOur banking partners who were experienced in IPOs commented that it was one of the most efficient S-1 drafting processes that they’ve seen. We were happy that this process, which typically takes six months, happened in four. To set up a right foundation for a successful IPO requires that the right processes and people (internally and externally) are in place:\n\n**Be transparent with Directors and Officers (D&O) insurance providers**. Directors and Officers insurance is expensive and the institutions which provide these services bid for your business after learning about your company through their own research as well as presentations and time spent with company representatives, usually from the Legal and Finance teams. We were unsure how our transparency would be perceived by the D&O insurers. However, our public [handbook](https://handbook.gitlab.com/) made it easier for D&O insurance providers to understand our business and processes. The GitLab Legal team created a bug bounty program that gave all team members a way to contribute to public company readiness by assisting in spotting and fixing “bugs” in our handbook. Bug bounty participants were rewarded with company swag.\n\n**Some board members might leave you**. Once a company IPOs, board members are subject to restrictions on their overall trading activities (e.g. tighter trading windows) with regard to the company’s stock. Due to these restrictions, earlier board members/investors may shift off the board, as new board members come on. This can add fresh perspectives on the board and help guide the company during the important post-IPO growth stage\n\n**Analysts depend on the bank you pick**. Banks that help with IPOs will make [analysts available](https://www.investopedia.com/articles/financialcareers/11/sell-side-buy-side-analysts.asp) to cover your company. Therefore, we looked for banks that were associated with analysts whom we wanted to cover GitLab. This is significant as it supports increased brand and marketing awareness. Once that’s determined, you should consider analyst coverage when selecting additional banks to help with your IPO.\n\n**Lead-left bank**. The lead-left bank, also called the managing underwriter, is listed first among the other underwriters, in the upper left-hand corner of the cover page of the S-1 filing. In our case it is Goldman Sachs per our [S1 cover page](https://www.sec.gov/Archives/edgar/data/1653482/000162828021018818/gitlab-sx1.htm#:~:text=Employer%20Identification%20Number). Getting left placement is a big deal because it means the bank receives the largest percentage of the deal allocation and generally leads the process from the banking side. Their industry reputation reflects on the company choosing them for this role. You will have several other banks involved to spread the risk of underwriting, reduce single bank exposure, and lower financial commitment to the IPO.\n\n**SAFE Framework**. We worked hard to educate team members early on to ensure they were empowered to make responsible decisions as a public company. Our SAFE framework is an acronym and mnemonic for how team members should think about transparency and what they can share publicly. (It stands for Sensitive, Accurate, Financial, and Effect.) GitLab team members have embraced the [SAFE Framework](https://handbook.gitlab.com/handbook/legal/safe-framework/) including creating a SAFE Slack channel staffed by our Legal team where team members can seek answers as well as flag things that are of concern. In terms of company communications, when we want to keep something internal, we say, “Keep this information SAFE.” We’ll also put this flag in decks, videos, Slack messages, and other communications. It is also a required part of our onboarding and training process. We’ve even created a SAFE Slack emoji:\n\n![:safe-tanuki:](https://about.gitlab.com/images/blogimages/safetanuki.png)\n\n**Reg FD training**. In addition to our SAFE framework, to prepare our team members we also took into account that we are a geographically diverse group, with more than a third of our company based outside of the U.S. We wanted to be mindful that not everyone would be familiar with U.S. Securities laws and may not understand some of the requirements GitLab would be subject to as a public company. This is why we created and had all team members go through Regulation Fair Disclosure (Reg FD) training as well as How to Avoid Insider Trading training. (We also have this training set up to recur annually.) We are not aware of another company that trains their entire company on Reg FD, as it is usually just provided to certain individuals who are authorized to speak on behalf of the company.\n\n**Timing an IPO**. The timing of an IPO requires a mixture of art and science. There are a number of conversations between the company’s retained investment bankers and buy side investors surrounding market conditions. An element of this involves the company’s investment bankers learning in which types of companies these investors may be interested. For example, if the growth rate of a potential new IPO is less than X, and/or the new IPO is unprofitable, then there may be no appetite for that particular IPO and naturally, a better outlook would likely inspire greater interest. Through continuous conversations, overall investor appetite is gleaned. Then it comes down to picking a specific day of the week and time of year, avoiding holidays. Companies must consider a time in which the most investors are available and paying attention. IPO days typically take place Tuesday through Thursday. And they don’t tend to be priced in the summer as investors are usually on vacation and not paying as much attention to the market. Labor Day through Thanksgiving is a popular time for IPOs. You also want to be mindful of the timing of your IPO relative to quarterly results as you want investors to consider your next fiscal year as the basis of valuing your company.\n\nWhen choosing a date for GitLab, we knew if we waited until after October 31, 2021, we would need to re-file, because of the filing date of our S-1 filing. We took all of these factors into consideration and chose October 14, 2021, as our IPO day. The date was serendipitous as GitLab’s [Friends & Family Day](https://handbook.gitlab.com/handbook/company/family-and-friends-day/) took place on Friday, October 15, 2021, and the company was also celebrating its 10 year anniversary in that time frame since the first commit to the GitLab open source project took place on October 8, 2011.\n\n**Bring down call.** Each time a company is about to file an amended Form S-1, investment bankers and attorneys gather on a “bring down” call. During this call, attorneys will ask a series of questions about material information, permissions, security, risks, concerns, etc., with the goal to achieve an “all clear.” With each new call, they’ll ask if the company has anything materially new to disclose. This was all done remotely.\n\n**Securing the Opening Bell.** Choosing the opening bell is generally preferred over the closing bell to provide a full day of celebration. We approached our listing day as a marketing event and a way to celebrate with team members and contributors globally, so securing the opening bell was important. This would allow us to reach the maximum amount of time zones. If you have a date in mind and stick with that date in the days leading up to the listing, you’ll be more likely to attain the opening vs. closing bell.\n\nWhile the timing at the moment for IPOs may not be in many companies’ favor, I know many amazing companies have been founded during times of economic uncertainty, such as Electronic Arts (1982) and Slack (2009). I’m looking forward to seeing the next generation of innovative ideas come to market and experience the same growth and excitement that we were able to capture and I hope that this educational series may help them when the time is right.\n\nThank you again, sincerely, to everyone who helped us along the road.\n",[23,24,9],"inside GitLab","events","yml",{},true,"/en-us/blog/one-third-of-what-we-learned-about-ipos-in-taking-gitlab-public",{"title":15,"description":16,"ogTitle":15,"ogDescription":16,"noIndex":12,"ogImage":19,"ogUrl":30,"ogSiteName":31,"ogType":32,"canonicalUrls":30},"https://about.gitlab.com/blog/one-third-of-what-we-learned-about-ipos-in-taking-gitlab-public","https://about.gitlab.com","article","en-us/blog/one-third-of-what-we-learned-about-ipos-in-taking-gitlab-public",[35,24,9],"inside-gitlab","uhNj9FI5qeHon_vrtvVU9NakYyqQ_2w7MI9_CCvusqI",{"data":38},{"logo":39,"freeTrial":44,"sales":49,"login":54,"items":59,"search":366,"minimal":397,"duo":416,"pricingDeployment":426},{"config":40},{"href":41,"dataGaName":42,"dataGaLocation":43},"/","gitlab logo","header",{"text":45,"config":46},"Get free trial",{"href":47,"dataGaName":48,"dataGaLocation":43},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":50,"config":51},"Talk to sales",{"href":52,"dataGaName":53,"dataGaLocation":43},"/sales/","sales",{"text":55,"config":56},"Sign in",{"href":57,"dataGaName":58,"dataGaLocation":43},"https://gitlab.com/users/sign_in/","sign in",[60,87,182,187,287,347],{"text":61,"config":62,"cards":64},"Platform",{"dataNavLevelOne":63},"platform",[65,71,79],{"title":61,"description":66,"link":67},"The intelligent orchestration platform for DevSecOps",{"text":68,"config":69},"Explore our Platform",{"href":70,"dataGaName":63,"dataGaLocation":43},"/platform/",{"title":72,"description":73,"link":74},"GitLab Duo Agent Platform","Agentic AI for the entire software lifecycle",{"text":75,"config":76},"Meet GitLab Duo",{"href":77,"dataGaName":78,"dataGaLocation":43},"/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":80,"description":81,"link":82},"Why GitLab","See the top reasons enterprises choose GitLab",{"text":83,"config":84},"Learn more",{"href":85,"dataGaName":86,"dataGaLocation":43},"/why-gitlab/","why gitlab",{"text":88,"left":27,"config":89,"link":91,"lists":95,"footer":164},"Product",{"dataNavLevelOne":90},"solutions",{"text":92,"config":93},"View all Solutions",{"href":94,"dataGaName":90,"dataGaLocation":43},"/solutions/",[96,120,143],{"title":97,"description":98,"link":99,"items":104},"Automation","CI/CD and automation to accelerate deployment",{"config":100},{"icon":101,"href":102,"dataGaName":103,"dataGaLocation":43},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[105,109,112,116],{"text":106,"config":107},"CI/CD",{"href":108,"dataGaLocation":43,"dataGaName":106},"/solutions/continuous-integration/",{"text":72,"config":110},{"href":77,"dataGaLocation":43,"dataGaName":111},"gitlab duo agent platform - product menu",{"text":113,"config":114},"Source Code Management",{"href":115,"dataGaLocation":43,"dataGaName":113},"/solutions/source-code-management/",{"text":117,"config":118},"Automated Software Delivery",{"href":102,"dataGaLocation":43,"dataGaName":119},"Automated software delivery",{"title":121,"description":122,"link":123,"items":128},"Security","Deliver code faster without compromising security",{"config":124},{"href":125,"dataGaName":126,"dataGaLocation":43,"icon":127},"/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[129,133,138],{"text":130,"config":131},"Application Security Testing",{"href":125,"dataGaName":132,"dataGaLocation":43},"Application security testing",{"text":134,"config":135},"Software Supply Chain Security",{"href":136,"dataGaLocation":43,"dataGaName":137},"/solutions/supply-chain/","Software supply chain security",{"text":139,"config":140},"Software Compliance",{"href":141,"dataGaName":142,"dataGaLocation":43},"/solutions/software-compliance/","software compliance",{"title":144,"link":145,"items":150},"Measurement",{"config":146},{"icon":147,"href":148,"dataGaName":149,"dataGaLocation":43},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[151,155,159],{"text":152,"config":153},"Visibility & Measurement",{"href":148,"dataGaLocation":43,"dataGaName":154},"Visibility and Measurement",{"text":156,"config":157},"Value Stream Management",{"href":158,"dataGaLocation":43,"dataGaName":156},"/solutions/value-stream-management/",{"text":160,"config":161},"Analytics & Insights",{"href":162,"dataGaLocation":43,"dataGaName":163},"/solutions/analytics-and-insights/","Analytics and insights",{"title":165,"items":166},"GitLab for",[167,172,177],{"text":168,"config":169},"Enterprise",{"href":170,"dataGaLocation":43,"dataGaName":171},"/enterprise/","enterprise",{"text":173,"config":174},"Small Business",{"href":175,"dataGaLocation":43,"dataGaName":176},"/small-business/","small business",{"text":178,"config":179},"Public Sector",{"href":180,"dataGaLocation":43,"dataGaName":181},"/solutions/public-sector/","public sector",{"text":183,"config":184},"Pricing",{"href":185,"dataGaName":186,"dataGaLocation":43,"dataNavLevelOne":186},"/pricing/","pricing",{"text":188,"config":189,"link":191,"lists":195,"feature":274},"Resources",{"dataNavLevelOne":190},"resources",{"text":192,"config":193},"View all resources",{"href":194,"dataGaName":190,"dataGaLocation":43},"/resources/",[196,229,247],{"title":197,"items":198},"Getting started",[199,204,209,214,219,224],{"text":200,"config":201},"Install",{"href":202,"dataGaName":203,"dataGaLocation":43},"/install/","install",{"text":205,"config":206},"Quick start guides",{"href":207,"dataGaName":208,"dataGaLocation":43},"/get-started/","quick setup checklists",{"text":210,"config":211},"Learn",{"href":212,"dataGaLocation":43,"dataGaName":213},"https://university.gitlab.com/","learn",{"text":215,"config":216},"Product documentation",{"href":217,"dataGaName":218,"dataGaLocation":43},"https://docs.gitlab.com/","product documentation",{"text":220,"config":221},"Best practice videos",{"href":222,"dataGaName":223,"dataGaLocation":43},"/getting-started-videos/","best practice videos",{"text":225,"config":226},"Integrations",{"href":227,"dataGaName":228,"dataGaLocation":43},"/integrations/","integrations",{"title":230,"items":231},"Discover",[232,237,242],{"text":233,"config":234},"Customer success stories",{"href":235,"dataGaName":236,"dataGaLocation":43},"/customers/","customer success stories",{"text":238,"config":239},"Blog",{"href":240,"dataGaName":241,"dataGaLocation":43},"/blog/","blog",{"text":243,"config":244},"Remote",{"href":245,"dataGaName":246,"dataGaLocation":43},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":248,"items":249},"Connect",[250,255,260,265,269],{"text":251,"config":252},"GitLab Services",{"href":253,"dataGaName":254,"dataGaLocation":43},"/services/","services",{"text":256,"config":257},"Community",{"href":258,"dataGaName":259,"dataGaLocation":43},"/community/","community",{"text":261,"config":262},"Forum",{"href":263,"dataGaName":264,"dataGaLocation":43},"https://forum.gitlab.com/","forum",{"text":266,"config":267},"Events",{"href":268,"dataGaName":24,"dataGaLocation":43},"/events/",{"text":270,"config":271},"Partners",{"href":272,"dataGaName":273,"dataGaLocation":43},"/partners/","partners",{"backgroundColor":275,"textColor":276,"text":277,"image":278,"link":282},"#2f2a6b","#fff","Insights for the future of software development",{"altText":279,"config":280},"the source promo card",{"src":281},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":283,"config":284},"Read the latest",{"href":285,"dataGaName":286,"dataGaLocation":43},"/the-source/","the source",{"text":288,"config":289,"lists":291},"Company",{"dataNavLevelOne":290},"company",[292],{"items":293},[294,299,305,307,312,317,322,327,332,337,342],{"text":295,"config":296},"About",{"href":297,"dataGaName":298,"dataGaLocation":43},"/company/","about",{"text":300,"config":301,"footerGa":304},"Jobs",{"href":302,"dataGaName":303,"dataGaLocation":43},"/jobs/","jobs",{"dataGaName":303},{"text":266,"config":306},{"href":268,"dataGaName":24,"dataGaLocation":43},{"text":308,"config":309},"Leadership",{"href":310,"dataGaName":311,"dataGaLocation":43},"/company/team/e-group/","leadership",{"text":313,"config":314},"Team",{"href":315,"dataGaName":316,"dataGaLocation":43},"/company/team/","team",{"text":318,"config":319},"Handbook",{"href":320,"dataGaName":321,"dataGaLocation":43},"https://handbook.gitlab.com/","handbook",{"text":323,"config":324},"Investor relations",{"href":325,"dataGaName":326,"dataGaLocation":43},"https://ir.gitlab.com/","investor relations",{"text":328,"config":329},"Trust Center",{"href":330,"dataGaName":331,"dataGaLocation":43},"/security/","trust center",{"text":333,"config":334},"AI Transparency Center",{"href":335,"dataGaName":336,"dataGaLocation":43},"/ai-transparency-center/","ai transparency center",{"text":338,"config":339},"Newsletter",{"href":340,"dataGaName":341,"dataGaLocation":43},"/company/contact/#contact-forms","newsletter",{"text":343,"config":344},"Press",{"href":345,"dataGaName":346,"dataGaLocation":43},"/press/","press",{"text":348,"config":349,"lists":350},"Contact us",{"dataNavLevelOne":290},[351],{"items":352},[353,356,361],{"text":50,"config":354},{"href":52,"dataGaName":355,"dataGaLocation":43},"talk to sales",{"text":357,"config":358},"Support portal",{"href":359,"dataGaName":360,"dataGaLocation":43},"https://support.gitlab.com","support portal",{"text":362,"config":363},"Customer portal",{"href":364,"dataGaName":365,"dataGaLocation":43},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":367,"login":368,"suggestions":375},"Close",{"text":369,"link":370},"To search repositories and projects, login to",{"text":371,"config":372},"gitlab.com",{"href":57,"dataGaName":373,"dataGaLocation":374},"search login","search",{"text":376,"default":377},"Suggestions",[378,380,384,386,390,394],{"text":72,"config":379},{"href":77,"dataGaName":72,"dataGaLocation":374},{"text":381,"config":382},"Code Suggestions (AI)",{"href":383,"dataGaName":381,"dataGaLocation":374},"/solutions/code-suggestions/",{"text":106,"config":385},{"href":108,"dataGaName":106,"dataGaLocation":374},{"text":387,"config":388},"GitLab on AWS",{"href":389,"dataGaName":387,"dataGaLocation":374},"/partners/technology-partners/aws/",{"text":391,"config":392},"GitLab on Google Cloud",{"href":393,"dataGaName":391,"dataGaLocation":374},"/partners/technology-partners/google-cloud-platform/",{"text":395,"config":396},"Why GitLab?",{"href":85,"dataGaName":395,"dataGaLocation":374},{"freeTrial":398,"mobileIcon":403,"desktopIcon":408,"secondaryButton":411},{"text":399,"config":400},"Start free trial",{"href":401,"dataGaName":48,"dataGaLocation":402},"https://gitlab.com/-/trials/new/","nav",{"altText":404,"config":405},"Gitlab Icon",{"src":406,"dataGaName":407,"dataGaLocation":402},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":404,"config":409},{"src":410,"dataGaName":407,"dataGaLocation":402},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":412,"config":413},"Get Started",{"href":414,"dataGaName":415,"dataGaLocation":402},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/compare/gitlab-vs-github/","get started",{"freeTrial":417,"mobileIcon":422,"desktopIcon":424},{"text":418,"config":419},"Learn more about GitLab Duo",{"href":420,"dataGaName":421,"dataGaLocation":402},"/gitlab-duo/","gitlab duo",{"altText":404,"config":423},{"src":406,"dataGaName":407,"dataGaLocation":402},{"altText":404,"config":425},{"src":410,"dataGaName":407,"dataGaLocation":402},{"freeTrial":427,"mobileIcon":432,"desktopIcon":434},{"text":428,"config":429},"Back to pricing",{"href":185,"dataGaName":430,"dataGaLocation":402,"icon":431},"back to pricing","GoBack",{"altText":404,"config":433},{"src":406,"dataGaName":407,"dataGaLocation":402},{"altText":404,"config":435},{"src":410,"dataGaName":407,"dataGaLocation":402},{"title":437,"button":438,"config":443},"See how agentic AI transforms software delivery",{"text":439,"config":440},"Watch GitLab Transcend now",{"href":441,"dataGaName":442,"dataGaLocation":43},"/events/transcend/virtual/","transcend event",{"layout":444,"icon":445},"release","AiStar",{"data":447},{"text":448,"source":449,"edit":455,"contribute":460,"config":465,"items":470,"minimal":677},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":450,"config":451},"View page source",{"href":452,"dataGaName":453,"dataGaLocation":454},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":456,"config":457},"Edit this page",{"href":458,"dataGaName":459,"dataGaLocation":454},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":461,"config":462},"Please contribute",{"href":463,"dataGaName":464,"dataGaLocation":454},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":466,"facebook":467,"youtube":468,"linkedin":469},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[471,518,572,616,643],{"title":183,"links":472,"subMenu":487},[473,477,482],{"text":474,"config":475},"View plans",{"href":185,"dataGaName":476,"dataGaLocation":454},"view plans",{"text":478,"config":479},"Why Premium?",{"href":480,"dataGaName":481,"dataGaLocation":454},"/pricing/premium/","why premium",{"text":483,"config":484},"Why Ultimate?",{"href":485,"dataGaName":486,"dataGaLocation":454},"/pricing/ultimate/","why ultimate",[488],{"title":489,"links":490},"Contact Us",[491,494,496,498,503,508,513],{"text":492,"config":493},"Contact sales",{"href":52,"dataGaName":53,"dataGaLocation":454},{"text":357,"config":495},{"href":359,"dataGaName":360,"dataGaLocation":454},{"text":362,"config":497},{"href":364,"dataGaName":365,"dataGaLocation":454},{"text":499,"config":500},"Status",{"href":501,"dataGaName":502,"dataGaLocation":454},"https://status.gitlab.com/","status",{"text":504,"config":505},"Terms of use",{"href":506,"dataGaName":507,"dataGaLocation":454},"/terms/","terms of use",{"text":509,"config":510},"Privacy statement",{"href":511,"dataGaName":512,"dataGaLocation":454},"/privacy/","privacy statement",{"text":514,"config":515},"Cookie preferences",{"dataGaName":516,"dataGaLocation":454,"id":517,"isOneTrustButton":27},"cookie preferences","ot-sdk-btn",{"title":88,"links":519,"subMenu":528},[520,524],{"text":521,"config":522},"DevSecOps platform",{"href":70,"dataGaName":523,"dataGaLocation":454},"devsecops platform",{"text":525,"config":526},"AI-Assisted Development",{"href":420,"dataGaName":527,"dataGaLocation":454},"ai-assisted development",[529],{"title":530,"links":531},"Topics",[532,537,542,547,552,557,562,567],{"text":533,"config":534},"CICD",{"href":535,"dataGaName":536,"dataGaLocation":454},"/topics/ci-cd/","cicd",{"text":538,"config":539},"GitOps",{"href":540,"dataGaName":541,"dataGaLocation":454},"/topics/gitops/","gitops",{"text":543,"config":544},"DevOps",{"href":545,"dataGaName":546,"dataGaLocation":454},"/topics/devops/","devops",{"text":548,"config":549},"Version Control",{"href":550,"dataGaName":551,"dataGaLocation":454},"/topics/version-control/","version control",{"text":553,"config":554},"DevSecOps",{"href":555,"dataGaName":556,"dataGaLocation":454},"/topics/devsecops/","devsecops",{"text":558,"config":559},"Cloud Native",{"href":560,"dataGaName":561,"dataGaLocation":454},"/topics/cloud-native/","cloud native",{"text":563,"config":564},"AI for Coding",{"href":565,"dataGaName":566,"dataGaLocation":454},"/topics/devops/ai-for-coding/","ai for coding",{"text":568,"config":569},"Agentic AI",{"href":570,"dataGaName":571,"dataGaLocation":454},"/topics/agentic-ai/","agentic ai",{"title":573,"links":574},"Solutions",[575,577,579,584,588,591,595,598,600,603,606,611],{"text":130,"config":576},{"href":125,"dataGaName":130,"dataGaLocation":454},{"text":119,"config":578},{"href":102,"dataGaName":103,"dataGaLocation":454},{"text":580,"config":581},"Agile development",{"href":582,"dataGaName":583,"dataGaLocation":454},"/solutions/agile-delivery/","agile delivery",{"text":585,"config":586},"SCM",{"href":115,"dataGaName":587,"dataGaLocation":454},"source code management",{"text":533,"config":589},{"href":108,"dataGaName":590,"dataGaLocation":454},"continuous integration & delivery",{"text":592,"config":593},"Value stream management",{"href":158,"dataGaName":594,"dataGaLocation":454},"value stream management",{"text":538,"config":596},{"href":597,"dataGaName":541,"dataGaLocation":454},"/solutions/gitops/",{"text":168,"config":599},{"href":170,"dataGaName":171,"dataGaLocation":454},{"text":601,"config":602},"Small business",{"href":175,"dataGaName":176,"dataGaLocation":454},{"text":604,"config":605},"Public sector",{"href":180,"dataGaName":181,"dataGaLocation":454},{"text":607,"config":608},"Education",{"href":609,"dataGaName":610,"dataGaLocation":454},"/solutions/education/","education",{"text":612,"config":613},"Financial services",{"href":614,"dataGaName":615,"dataGaLocation":454},"/solutions/finance/","financial services",{"title":188,"links":617},[618,620,622,624,627,629,631,633,635,637,639,641],{"text":200,"config":619},{"href":202,"dataGaName":203,"dataGaLocation":454},{"text":205,"config":621},{"href":207,"dataGaName":208,"dataGaLocation":454},{"text":210,"config":623},{"href":212,"dataGaName":213,"dataGaLocation":454},{"text":215,"config":625},{"href":217,"dataGaName":626,"dataGaLocation":454},"docs",{"text":238,"config":628},{"href":240,"dataGaName":241,"dataGaLocation":454},{"text":233,"config":630},{"href":235,"dataGaName":236,"dataGaLocation":454},{"text":243,"config":632},{"href":245,"dataGaName":246,"dataGaLocation":454},{"text":251,"config":634},{"href":253,"dataGaName":254,"dataGaLocation":454},{"text":256,"config":636},{"href":258,"dataGaName":259,"dataGaLocation":454},{"text":261,"config":638},{"href":263,"dataGaName":264,"dataGaLocation":454},{"text":266,"config":640},{"href":268,"dataGaName":24,"dataGaLocation":454},{"text":270,"config":642},{"href":272,"dataGaName":273,"dataGaLocation":454},{"title":288,"links":644},[645,647,649,651,653,655,657,661,666,668,670,672],{"text":295,"config":646},{"href":297,"dataGaName":290,"dataGaLocation":454},{"text":300,"config":648},{"href":302,"dataGaName":303,"dataGaLocation":454},{"text":308,"config":650},{"href":310,"dataGaName":311,"dataGaLocation":454},{"text":313,"config":652},{"href":315,"dataGaName":316,"dataGaLocation":454},{"text":318,"config":654},{"href":320,"dataGaName":321,"dataGaLocation":454},{"text":323,"config":656},{"href":325,"dataGaName":326,"dataGaLocation":454},{"text":658,"config":659},"Sustainability",{"href":660,"dataGaName":658,"dataGaLocation":454},"/sustainability/",{"text":662,"config":663},"Diversity, inclusion and belonging (DIB)",{"href":664,"dataGaName":665,"dataGaLocation":454},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":328,"config":667},{"href":330,"dataGaName":331,"dataGaLocation":454},{"text":338,"config":669},{"href":340,"dataGaName":341,"dataGaLocation":454},{"text":343,"config":671},{"href":345,"dataGaName":346,"dataGaLocation":454},{"text":673,"config":674},"Modern Slavery Transparency Statement",{"href":675,"dataGaName":676,"dataGaLocation":454},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":678},[679,682,685],{"text":680,"config":681},"Terms",{"href":506,"dataGaName":507,"dataGaLocation":454},{"text":683,"config":684},"Cookies",{"dataGaName":516,"dataGaLocation":454,"id":517,"isOneTrustButton":27},{"text":686,"config":687},"Privacy",{"href":511,"dataGaName":512,"dataGaLocation":454},[689],{"id":690,"title":18,"body":8,"config":691,"content":693,"description":8,"extension":25,"meta":701,"navigation":27,"path":702,"seo":703,"stem":704,"__hash__":705},"blogAuthors/en-us/blog/authors/sid-sijbrandij.yml",{"template":692},"BlogAuthor",{"role":694,"name":18,"bio":695,"config":696},"Co-founder, Chief Executive Officer and Board Chair of GitLab Inc.","Sid Sijbrandij (pronounced see-brandy) is the Co-founder, Chief Executive Officer and Board Chair of GitLab Inc., the most comprehensive AI-powered DevSecOps platform. GitLab's single application helps organizations deliver software faster and more efficiently while strengthening their security and compliance.\n\nSid's career path has been anything but traditional. He spent four years building recreational submarines for U-Boat Worx and while at Ministerie van Justitie en Veiligheid he worked on the Legis project, which developed several innovative web applications to aid lawmaking. He first saw Ruby code in 2007 and loved it so much that he taught himself how to program. In 2012, as a Ruby programmer, he encountered GitLab and discovered his passion for open source. Soon after, Sid commercialized GitLab, and by 2015 he led the company through Y Combinator's Winter 2015 batch. Under his leadership, the company has grown with an estimated 30 million+ registered users from startups to global enterprises.\n\nSid studied at the University of Twente in the Netherlands where he received an M.S. in Management Science. Sid was named one of the greatest minds of the pandemic by Forbes for spreading the gospel of remote work.",{"headshot":697,"twitter":698,"linkedin":699,"ctfId":700},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665383/Blog/Author%20Headshots/sytses-headshot.png","https://twitter.com/sytses","https://www.linkedin.com/in/sijbrandij","sytses",{},"/en-us/blog/authors/sid-sijbrandij",{},"en-us/blog/authors/sid-sijbrandij","ZdVvFbtL6NKLtKZEjFCVOecdpvuPzX3wmEZBrC6pRWg",[707,719,733],{"content":708,"config":717},{"title":709,"description":710,"authors":711,"heroImage":713,"date":714,"body":715,"category":9,"tags":716},"Introducing the GitLab Managed Service Provider (MSP) Partner Program","Build a profitable, services-led DevSecOps practice - backed by GitLab.",[712],"Karishma Kumar","https://res.cloudinary.com/about-gitlab-com/image/upload/v1772047747/ntihfmnu2fepamqemaas.png","2026-02-26","*This blog is written for managed service providers (MSPs) looking to build a GitLab practice. If you’re a developer or engineering leader, this is the program that can empower the partners who help teams like yours scale and move faster.*\n\nMany organizations know they need a modern DevSecOps platform. What they often don't have is the bandwidth to deploy, manage, and continuously optimize one while shipping software at the pace the business demands. That's a real opportunity for MSPs, and now GitLab has a defined program to support them.\n\nWe're excited to introduce the **GitLab MSP Partner Program**, a new global program that enables qualified MSPs to deliver GitLab as a fully managed service to their customers.\n\n## Why this matters for partners and customers\n\nFor the first time, GitLab has a formally defined, globally available program built specifically for MSPs. This means clear requirements, structured enablement, dedicated support, and real financial benefits, so partners can confidently invest in building a GitLab managed services practice.\n\nThe timing is right. Organizations are accelerating their DevSecOps journeys, but many are navigating complex migrations, sprawling toolchains, and growing security requirements on top of their core work of building and shipping software.\n\nGitLab MSP partners handle the operational side of running the platform, including deployment, migration, administration, and ongoing support, so development teams can stay focused on what they do best.\n\n## What MSP partners get\n\n**Financial benefits**: MSP partners earn GitLab partner margins plus an additional MSP premium on all transactions, new business, and renewals. You also retain 100% of the service fees you charge customers for deployment, migration, training, enablement, and strategic consulting. That's multiple recurring revenue streams built around a single platform.\n\n**Enablement and education**: Partners have access to quarterly technical bootcamps covering version updates, new features, best practices, ongoing roadmap updates, and peer sharing. Recommended cloud certifications (AWS Solutions Architect Associate, GCP Associate Cloud Engineer) round out the technical foundation.\n\n**Go-to-market support**: MSPs receive a GitLab Certified MSP Partner badge, co-brandable assets, eligibility for joint customer case studies, a Partner Locator listing, and access to Marketing Development Funds (MDF) for qualified demand generation activities.\n\n## What customers can expect\n\nCustomers working with a GitLab MSP partner get a structured, managed DevSecOps experience, documented and repeatable implementation methodologies, regular business reviews, and support with clearly defined response and escalation paths.\n\nThe result: Development teams can stay focused on building great software while their MSP partner focuses on running and optimizing the platform.\n\n## A new opportunity around AI\n\nOrganizations are increasingly looking to safely introduce AI into their software development workflows, and even experienced teams can benefit from a structured approach to rolling it out at scale. GitLab MSP partners are well-positioned to guide customers through GitLab Duo Agent Platform as part of a broader managed services offering.\n\nBy combining GitLab's DevSecOps platform with MSP-delivered operational expertise, customers can experiment with AI-assisted workflows in a governed environment, meet data residency and compliance requirements, and scale AI adoption across teams without overburdening internal resources.\n\n## Is this right for your business?\n\nThe GitLab MSP Partner Program is a strong fit if you:\n\n* Already deliver managed services in cloud, infrastructure, or application operations  \n* Want to add high-value DevSecOps to your portfolio  \n* Have or want to build technical talent interested in modern development platforms  \n* Prefer long-term customer relationships over one-time transactions\n\nIf you're already a GitLab Select and Professional Services Partner, the MSP program gives you a structured way to turn your existing expertise into a repeatable managed offering.\n\n## Getting started\n\nThe program launches with the **Certified MSP Partner** designation. There's no minimum ARR or customer count required to join. Here's how the path looks:\n\n1. **Confirm fit** - Verify you meet the business and technical requirements outlined in the [handbook page](https://handbook.gitlab.com/handbook/resellers/channel-program-guide/#the-gitlab-managed-service-provider-msp-partner-program).  \n2. **Apply via the GitLab Partner Portal** - Submit your application with business and technical documentation.  \n3. **Complete 90-day onboarding** - A structured onboarding journey covers contracts, technical enablement, sales training, and your first customer engagement.  \n4. **Launch your managed offering** - Package your services, set your SLAs, and begin engaging customers.\n\nCompleted applications are reviewed within approximately three business days.\n\n> Interested in building a GitLab managed services practice? New partners can apply [to become a GitLab Partner](https://about.gitlab.com/partners/). Existing partners can reach out to your GitLab representative to learn more about the program and tell us about the solutions you're currently offering customers through your MSP practice!\n",[553,9,273],{"featured":12,"template":13,"slug":718},"introducing-the-gitlab-managed-service-provider-msp-partner-program",{"content":720,"config":731},{"title":721,"authors":722,"date":726,"body":727,"category":9,"tags":728,"description":729,"heroImage":730},"DevSecOps-as-a-Service on Oracle Cloud Infrastructure by Data Intensity",[723,724,712,725],"Biju Thomas","Matt Genelin","Ryan Palmaro","2026-02-10","At GitLab, we know that many organizations choose GitLab Self-Managed for the control, customization, and security it provides. However, managing underlying infrastructure can be a significant operational challenge — especially for teams who want to focus on delivering software, not maintaining platforms.\n\nThat's why we're excited to work with [Oracle Cloud Infrastructure (OCI)](https://www.oracle.com/cloud/) and [Data Intensity](https://www.dataintensity.com/services/security-services/devsecops/), a trusted Oracle managed services provider, to offer a new managed service option, DevSecOps-as-a-Service, that brings together the best of both worlds: the control of GitLab Self-Managed with the operational ease of a fully managed service.\n\n## Why GitLab Self-Managed?\n\nGitLab Self-Managed gives you complete ownership of your DevSecOps platform. You control where your data lives, how your instance is configured, and can customize it to meet specific compliance, security, or operational requirements. This level of control is essential for organizations with strict regulatory requirements, data residency needs, or specific integration must-haves.\n\nThe challenge for some customers running on GitLab Self-Managed means managing servers, handling upgrades, ensuring high availability, and implementing disaster recovery. All require specialized expertise and dedicated resources.\n\n## A managed path to GitLab Self-Managed\n\nData Intensity's DevSecOps-as-a-Service on OCI removes these operational burdens while preserving the control benefits of GitLab Self-Managed. Instead of building and maintaining infrastructure yourself, you get a standalone GitLab instance managed by Data Intensity's team of experts, running on OCI's high-performance cloud infrastructure.\n\nHere's what's included:\n\n* Standalone GitLab instance on OCI infrastructure\n* 24x7 monitoring, alarming, and support\n* Quarterly patching scheduled during your chosen maintenance windows\n* Automated backups and disaster recovery protection\n\n## Scaling with your organization\n\nData Intensity’s managed service is designed to grow with your team, offering tiered architectures to match your specific user capacity and recovery requirements:\n\n| **Feature**        | **Standard**    | **Premier**     | **Premier +**   |\n|--------------------|-----------------|-----------------|-----------------|\n| **User Capacity**  | Up to 1,000     | Up to 2,000     | Up to 3,000     |\n| **Performance**    | 20 requests/sec | 40 requests/sec | 60 requests/sec |\n| **Availability**   | 99.9%           | 99.95%          | 99.99%          |\n| **Recovery (RTO)** | 48 hours        | 8 hours         | 4 hours         |\n\nFor more information, visit Data Intensity’s website to learn more about [DevSecOps-as-a-Service](https://www.dataintensity.com/services/security-services/devsecops/).\n\n## Why OCI for GitLab?\nOracle Cloud Infrastructure (OCI) provides a robust foundation for running GitLab Self-Managed, offering a secure, high-performance environment at a significantly lower cost than other hyperscalers. Organizations migrating workloads to OCI commonly realize infrastructure cost reductions of 40-50%, making it easier to fund and scale deployments.\n\nOCI supports a wide range of deployment models, from public cloud regions to specialized environments such as Government and EU Sovereign Clouds, as well as dedicated infrastructure deployed behind your firewall. These options come with consistent pricing, tooling, and operational experience, enabling teams to standardize GitLab deployments across regulated, hybrid, and global environments.\n\nThe combination of GitLab's comprehensive DevSecOps platform, OCI's high-performance infrastructure, and Data Intensity's managed services expertise provides a turnkey solution that lets your teams focus on what matters: building great software.\n\n## Is this right for your organization?\nConsider Data Intensity's DevSecOps-as-a-Service if you:\n* Want GitLab Self-Managed but need to minimize operational overhead\n* Require specific compliance, security, or data residency requirements\n* Need guaranteed SLAs and professional disaster recovery capabilities\n* Prefer predictable costs and expert management over building in-house infrastructure expertise\n* Are already using or planning to use OCI for your cloud infrastructure\n* Prioritize flexibility and control\n* Want a dedicated instance that’s managed externally but offers the control of a self-managed environment\n\n## Getting started\nOrganizations interested in running GitLab Self-Managed on OCI through Data Intensity's DevSecOps-as-a-Service can contact Data Intensity via the [Data Intensity website](https://www.dataintensity.com/services/security-services/devsecops/) to discuss specific requirements and begin deployment planning.\n\nModernizing your DevSecOps doesn't have to be complex. Data Intensity provides optional migration of code repositories and customizations to ensure a smooth transition to OCI.\n\nAs GitLab continues expanding our partner ecosystem, solutions like this demonstrate our commitment to giving organizations choice in how they deploy and manage GitLab — whether that's SaaS, self-managed, or managed services through trusted partners.",[273,521],"Run GitLab Self-Managed with minimal overhead. Data Intensity delivers DevSecOps-as-a-Service on OCI with expert management and disaster recovery.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098794/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%289%29_DoeBNJVrhv9FpF3WCsHNc_1750098793762.png",{"featured":27,"template":13,"slug":732},"devsecops-as-a-service-on-oracle-cloud-infrastructure-by-data-intensity",{"content":734,"config":744},{"title":735,"description":736,"authors":737,"heroImage":739,"date":740,"body":741,"category":9,"tags":742},"How we built and automated our new Japanese GitLab Docs site","Learn about our AI-assisted localization infrastructure – with docs-as-code principles – that expands access to critical product documentation.",[738],"Daniel Sullivan","https://res.cloudinary.com/about-gitlab-com/image/upload/v1758812952/yxhgljkwljld0lyizmaz.png","2025-12-11","Today we are thrilled to announce the release of GitLab product documentation in Japanese at [docs.gitlab.com/ja-jp](http://docs.gitlab.com/ja-jp). This major step marks our first move toward making GitLab's extensive documentation accessible to our users worldwide.\n\n![Japanese GitLab Docs site](https://res.cloudinary.com/about-gitlab-com/image/upload/v1765299500/hya4bog8gllk1kimduac.png)\n\n## The unique challenge of the Japanese market\n\nJapan represents one of the world's largest economies and is a critical market for enterprise software. However, it also presents a distinctive challenge: despite its technological sophistication and massive developer community, English proficiency remains a significant barrier for many users.\n\nJapan's developers and DevSecOps teams often face challenges with English-only documentation, [as indicated by the country's ranking on the EF English Proficiency Index](https://www.ef.edu/epi/regions/asia/japan/). This language barrier can significantly impact the speed of learning and ultimately influence the decision to evaluate, adopt, and champion a platform within Japanese organizations.\n\nWe've heard directly from our Japanese customers and partners that English-only documentation wasn't merely an inconvenience, it was a barrier preventing them from getting the most out of GitLab. The impact rippled through every stage of the user journey: From initial evaluation where teams struggled to assess GitLab's capabilities, to daily operations where finding solutions took longer than necessary, to staying current with new features and best practices.\n\nIn a market as competitive and mature as in Japan, this language barrier directly affected GitLab's market penetration. When Japanese companies evaluate enterprise software, the availability of comprehensive Japanese documentation signals long-term commitment to the market. It demonstrates that a provider isn't just making a token effort, but is genuinely invested in supporting Japanese users throughout their entire journey.\n\nTo address this challenge and demonstrate our commitment to the Japanese market, we built localization infrastructure from the ground up, integrating with how we create and maintain documentation at GitLab.\n\n## Localization built on docs-as-code principles\n\nGitLab's documentation is treated like any other code contribution, residing alongside product code in GitLab projects and managed via merge requests. This system ensures documentation is version-controlled, collaboratively reviewed, and automatically tested through CI/CD pipelines, which includes checks for issues with language, formatting, and links. Both the English and Japanese documentation sites are dynamically generated using the Hugo static site generator and deployed after merging changes, guaranteeing users always access the latest information.\n\nThe documentation is extensive and comprehensive, drawing content from various source projects, including GitLab, GitLab Runner, Omnibus GitLab, GitLab Charts, GitLab Operator, and GitLab CLI (glab) ([see architecture for details](https://gitlab.com/gitlab-org/technical-writing/docs-gitlab-com/-/blob/main/doc/architecture.md)). This sheer scale and rapid update velocity presented a significant localization challenge. To keep pace with the continuous evolution of these source English projects, we had to design a localization infrastructure for our GitLab product documentation that could handle these unique complexities and provide an enterprise-grade solution for a fully localized site, all while adhering to our CI/CD pipeline requirements.\n\n## How we localized GitLab Documentation\n\nFor our initial Japanese localization, we adopted a strategy of integrating new folders within our existing English content structure. Specifically, we introduced `doc-locale/ja-jp` folders within each project that stores source Markdown files. This architecture [keeps the translations right alongside their source content](https://gitlab.com/gitlab-org/gitlab/-/tree/master/doc-locale/ja-jp) while maintaining a clear organizational separation. Not only that, but it also enables us to apply the same robust version control, established review and collaboration workflows, and even some of the automated quality checks used for our English documentation to the translated content.  \n\nThis [internationalization infrastructure built for Japanese documentation](https://handbook.gitlab.com/handbook/marketing/localization/tech_docs_localization/#multilingual-hugo-docs-implementation) provides a scalable foundation for future language expansion. With the architecture, tooling, and processes now in place, we are well-positioned to support additional languages as we continue our commitment to making GitLab accessible to users worldwide.\n\n## An AI-assisted  translation workflow that balances speed and quality\n\nWe adopted a strategic, phased approach to processing the content through translation, prioritizing pages based on their English-language page views. The highest-traffic pages underwent AI translation first, followed by comprehensive human linguistic review, and we intentionally paused subsequent phases until these priority pages completed the full human review cycle. This deliberate sequencing allowed us to build a robust, curated translation memory and termbase from our most important content. These linguistic assets accelerated and improved quality across all remaining content. In parallel, this initial phase served as our testing ground on the technical infrastructure on the GitLab side. We used it to iterate and reinforce our CI/CD pipelines, refine our translation and post-editing AI scripts, and solidify our Translation MR review process.\n\nTo provide our international users with the most current documentation while guaranteeing high-quality translated content, [we implemented an AI-assisted translation workflow with human post-editing](https://handbook.gitlab.com/handbook/marketing/localization/tech_docs_localization/#translation-workflow), consisting of:\n\n* Phase 1: AI-powered translation. We built a custom AI translation system enriched with GitLab-specific context including style guides, GitLab UI content translations, terminology databases, and original file context. This system intelligently handles GitLab's specialized markdown syntax (GLFM) and protects elements like placeholder variables, alert boxes, Hugo shortcodes, and GitLab-specific references that standard translation tools can't process out of the box.   \n* Phase 2: Human linguistic review. Professional Japanese translators specialized in technical content then review and refine the AI translations. They work with GitLab's Japanese style guide, translation memory, and terminology database to ensure accuracy, natural language flow, and cultural appropriateness. These human-reviewed translations progressively replace the AI versions on the site.\n\n## Technical challenges and solutions\n\nLocalizing GitLab's extensive documentation, while maintaining our docs-as-code principles and CI/CD-driven publishing workflow, required significant technical innovation. The challenges extended beyond translation itself: we needed to preserve complex markdown syntax, maintain automated testing standards, ensure seamless content fallbacks, and create sustainable processes for continuous updates across multiple source projects.\n\nThe English **markdown file syntax complexity** led us to developing custom code and regex in our Translation Management System (TMS) to protect codeblocks, URLs, and other functional elements that should not be exposed for translation.\n\n![Translation Management System](https://res.cloudinary.com/about-gitlab-com/image/upload/v1765299311/x3oglow15o5z6xthgxfn.png)\n\nDue to the dynamics of how the English content is generated, we established an **English fallback mechanism.** Essentially, when the Japanese translation is not ready yet, the localized site seamlessly displays English content with translated navigation and UI, preventing 404s and maintaining language context via Hugo’s rendering system.\n\nWe enhanced the localized navigation and linking so that it adjusts dynamically and would persist the locale. We added **anchor IDs** in the translated files by pre-processing the English file before it’s sent for translation. That improves the experience for people navigating to a docs page from a link. The consistent anchor ID means they can change to either language and still land in the correct place in the page.\n\n![English fallback mechanism](https://res.cloudinary.com/about-gitlab-com/image/upload/v1765299310/uqimyjm0ltvpcnc7bowk.png)\n\n[We also extended CI/CD pipelines](https://gitlab.com/groups/gitlab-com/localization/-/work_items/109) to test localized content in Translation MRs following the same quality standards as the English docs. It allows us to catch invalid Hugo shortcodes, spaces inside links, or bare URLs. It also identifies orphaned files and redirects files with no target files. You can see the jobs that run on the MRs containing translated documentation [on the GitLab project  `.gitlab/ci/docs.gitlab-ci.yml` file](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/docs.gitlab-ci.yml). \n\nA centralized translation request system orchestrates the workflow, monitors the English files, identifies new and updated content, routes files for translation, automatically creates translation merge requests, tracks file status in translation requests and maintains an audit trail. To get docs translated [we processed 430 Translation MRs](https://gitlab.com/groups/gitlab-com/localization/tech-docs-forked-projects/prod/-/merge_requests/?sort=updated_asc&state=merged&label_name%5B%5D=gitlab-translation-service&label_name%5B%5D=translation-upstream%3A%3A%20complete&first_page_size=100) with files ranging from 1-10 in each Translation MR.\n\n![Translation MRs](https://res.cloudinary.com/about-gitlab-com/image/upload/v1765299311/fgbrtapbmclj4pvdjh9k.png)\n\nThe result is a Japanese documentation experience that stays synchronized with English content updates, giving users faster access to critical information. Users can discover and navigate content fully in their language, with English appearing only for content that’s still in translation. They can trust GitLab’s quality standards while accessing the latest features quickly. All of this creates a sustainable, scalable foundation for future languages and documentation growth.\n\nLearn more about all the technical details in our [GitLab Product Documentation Handbook page](https://handbook.gitlab.com/handbook/marketing/localization/tech_docs_localization/).\n\n## Visit our Japanese docs site\n\nWhether you're a longtime GitLab user or just getting started, we hope this localized documentation makes your DevSecOps journey smoother and more accessible.\n\nThis is just the beginning of our localization efforts, and your feedback is invaluable in helping us improve. If you notice any translation issues, have suggestions for improvement, or simply want to share your experience using the Japanese documentation, please don't hesitate to reach out. You can provide comments in our [feedback issue](https://gitlab.com/gitlab-com/localization/docs-site-localization/-/work_items/782).\n\nAs we continue evolving this localization infrastructure, our immediate priorities include enhancing the search experience for Japanese users, and accelerating our continuous localization workflow to minimize the time gap between English updates and their Japanese translations. Thank you to our Japanese community for your continued support and patience as we work to serve you better. We're committed to making GitLab the best DevSecOps platform for Japanese teams, and comprehensive Japanese documentation is a crucial step in that journey.\n\n> Start exploring today at [docs.gitlab.com/ja-jp](https://docs.gitlab.com/ja-jp)!",[743,9],"product",{"featured":27,"template":13,"slug":745},"how-we-built-and-automated-our-new-japanese-gitlab-docs-site",{"promotions":747},[748,762,773],{"id":749,"categories":750,"header":752,"text":753,"button":754,"image":759},"ai-modernization",[751],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":755,"config":756},"Get your AI maturity score",{"href":757,"dataGaName":758,"dataGaLocation":241},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":760},{"src":761},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":763,"categories":764,"header":765,"text":753,"button":766,"image":770},"devops-modernization",[743,556],"Are you just managing tools or shipping innovation?",{"text":767,"config":768},"Get your DevOps maturity score",{"href":769,"dataGaName":758,"dataGaLocation":241},"/assessments/devops-modernization-assessment/",{"config":771},{"src":772},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":774,"categories":775,"header":777,"text":753,"button":778,"image":782},"security-modernization",[776],"security","Are you trading speed for security?",{"text":779,"config":780},"Get your security maturity score",{"href":781,"dataGaName":758,"dataGaLocation":241},"/assessments/security-modernization-assessment/",{"config":783},{"src":784},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":786,"blurb":787,"button":788,"secondaryButton":793},"Start building faster today","See what your team can do with the intelligent orchestration platform for DevSecOps.\n",{"text":789,"config":790},"Get your free trial",{"href":791,"dataGaName":48,"dataGaLocation":792},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":492,"config":794},{"href":52,"dataGaName":53,"dataGaLocation":792},1772652078106]