Documentation site architecture

The gitlab-docs project hosts the repository which is used to generate the GitLab documentation website and is deployed to It uses the Nanoc static site generator.


While the source of the documentation content is stored in GitLab's respective product repositories, the source that is used to build the documentation site from that content is located at

The following diagram illustrates the relationship between the repositories from where content is sourced, the gitlab-docs project, and the published output.

  graph LR
    A --> F
    B --> F
    C --> F
    D --> F
    E --> F
    F -- Build pipeline --> G
    G --> H
    G --> I
    G --> J
    G --> K
    G --> L

You will not find any GitLab docs content in the gitlab-docs repository. All documentation files are hosted in the respective repository of each product, and all together are pulled to generate the docs website:

NOTE: Note: In September 2019, we moved towards a single codebase, as such the docs for CE and EE are now identical. For historical reasons and in order not to break any existing links throughout the internet, we still maintain the CE docs (, although it is hidden from the website, and is now a symlink to the EE docs. When Pages supports redirects, we will be able to remove this completely.


To provide an optimized site structure, design, and a search-engine friendly website, along with a discoverable documentation, we use a few assets for the GitLab Documentation website.



Global navigation

Read through the global navigation documentation to understand:

  • How the global navigation is built.
  • How to add new navigation items.

Using YAML data files

The easiest way to achieve something similar to Jekyll's data files in Nanoc is by using the @items variable.

The data file must be placed inside the content/ directory and then it can be referenced in an ERB template.

Suppose we have the content/_data/versions.yaml file with the content:

- 10.6
- 10.5
- 10.4

We can then loop over the versions array with something like:

<% @items['/_data/versions.yaml'][:versions].each do | version | %>

<h3><%= version %></h3>

<% end &>

Note that the data file must have the yaml extension (not yml) and that we reference the array with a symbol (:versions).

Bumping versions of CSS and JavaScript

Whenever the custom CSS and JavaScript files under content/assets/ change, make sure to bump their version in the frontmatter. This method guarantees that your changes will take effect by clearing the cache of previous files.

Always use Nanoc's way of including those files, do not hardcode them in the layouts. For example use:

<script async type="application/javascript" src="<%= @items['/assets/javascripts/badges.*'].path %>"></script>

<link rel="stylesheet" href="<%= @items['/assets/stylesheets/toc.*'].path %>">

The links pointing to the files should be similar to:

<%= @items['/path/to/assets/file.*'].path %>

Nanoc will then build and render those links correctly according with what's defined in Rules.

Linking to source files

A helper called edit_on_gitlab can be used to link to a page's source file. We can link to both the simple editor and the web IDE. Here's how you can use it in a Nanoc layout:

  • Default editor: <a href="<%= edit_on_gitlab(@item, editor: :simple) %>">Simple editor</a>
  • Web IDE: <a href="<%= edit_on_gitlab(@item, editor: :webide) %>">Web IDE</a>

If you don't specify editor:, the simple one is used by default.

Algolia search engine

The docs site uses Algolia docsearch for its search function. This is how it works:

  1. GitLab is a member of the docsearch program, which is the free tier of Algolia.
  2. Algolia hosts a doscsearch config for the GitLab docs site, and we've worked together to refine it.
  3. That config is parsed by their crawler every 24h and stores the docsearch index on Algolia's servers.
  4. On the docs side, we use a docsearch layout which is present on pretty much every page except, which uses its own layout. In those layouts, there's a JavaScript snippet which initiates docsearch by using an API key and an index name (gitlab) that are needed for Algolia to show the results.

NOTE: For GitLab employees: The credentials to access the Algolia dashboard are stored in 1Password. If you want to receive weekly reports of the search usage, search the Google doc with title "Email, Slack, and GitLab Groups and Aliases", search for docsearch, and add a comment with your email to be added to the alias that gets the weekly reports.

Monthly release process (versions)

The docs website supports versions and each month we add the latest one to the list. For more information, read about the monthly release process.

Review Apps for documentation merge requests

If you are contributing to GitLab docs read how to create a Review App with each merge request.