commercial-gitlab-webservice-ee

packaged by Chainguard

Chainguard Container for commercial-gitlab-webservice-ee

GitLab Enterprise Edition is a complete DevOps platform providing source code management, CI/CD automation, and collaboration tools, with the Premium and Ultimate feature set including Geo replication and Advanced Search.

Chainguard Containers are regularly-updated, secure-by-default container images.

Download this Container Image

For those with access, this container image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/commercial-gitlab-webservice-ee:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

Compatibility Notes

The commercial-gitlab images are minimal, Wolfi-based replacements for GitLab's Cloud Native (CNG) Enterprise Edition component images, published upstream under registry.gitlab.com/gitlab-org/build/cng. They are built to work with the official GitLab Helm chart.

This image group provides the Enterprise Edition components:

• commercial-gitlab-webservice-ee — the Rails web application, a replacement for gitlab-webservice-ee
• commercial-gitlab-sidekiq-ee — background job processing, a replacement for gitlab-sidekiq-ee
• commercial-gitlab-toolbox-ee — administrative and backup tooling, a replacement for gitlab-toolbox-ee
• commercial-gitlab-workhorse-ee — the HTTP reverse proxy, a replacement for gitlab-workhorse-ee
• commercial-gitlab-geo-logcursor-ee — the Geo log cursor, a replacement for gitlab-geo-logcursor

These are the decomposed Cloud Native components, not the all-in-one gitlab/gitlab-ee Omnibus image. They are intended to be deployed through the GitLab Helm chart, which is how GitLab supports running GitLab on Kubernetes.

The edition-neutral components a GitLab deployment also needs — Gitaly, GitLab Shell, KAS, Pages, the container registry, and the exporter — are not duplicated here. Upstream publishes those without an edition suffix, and Chainguard ships them in the gitlab image group, which these images are designed to be used alongside.

The container configuration matches upstream: the same entrypoint and command, and the same git user with UID 1000. The images differ in that they contain only the packages needed to run each component, so they do not include a package manager or the development tooling that upstream's build leaves in its images.

Running these images requires a valid GitLab Enterprise Edition subscription. Without one, GitLab operates with Free-tier features only.

Prerequisites

Enterprise Edition requires a valid GitLab subscription. Running these images without a licence leaves GitLab operating with Free-tier features only. Refer to GitLab's subscription documentation for how licences are applied.

A GitLab deployment also needs externally managed PostgreSQL, Redis, and object storage. Chart 10.x, which corresponds to GitLab 19.0 and later, removed the bundled subcharts that previously provided them.

Getting Started

Each component runs the process its upstream counterpart runs. To confirm an image is working, run the Workhorse binary directly:

docker run --rm --entrypoint /usr/bin/gitlab-workhorse cgr.dev/ORGANIZATION/commercial-gitlab-workhorse-ee:latest -version

In practice these images are deployed through the GitLab Helm chart, by pointing each component at the Chainguard repository. Create a values file:

cat > values.yaml <<VALUES
global:
  edition: ee
  # Go 1.27 rejects the tlskyber setting the upstream chart sets.
  extraEnv:
    GODEBUG: "tlsmlkem=0"
gitlab:
  webservice:
    image:
      repository: cgr.dev/ORGANIZATION/commercial-gitlab-webservice-ee
      tag: "latest"
    workhorse:
      image: cgr.dev/ORGANIZATION/commercial-gitlab-workhorse-ee
      tag: "latest"
  sidekiq:
    image:
      repository: cgr.dev/ORGANIZATION/commercial-gitlab-sidekiq-ee
      tag: "latest"
  toolbox:
    image:
      repository: cgr.dev/ORGANIZATION/commercial-gitlab-toolbox-ee
      tag: "latest"
VALUES

Then install the chart with that values file:

helm repo add gitlab https://charts.gitlab.io/
helm install gitlab gitlab/gitlab --values values.yaml

Configuration

Configuration is supplied the way upstream expects it. Each component starts through /scripts/entrypoint.sh, which renders the templates found in the directory named by CONFIG_TEMPLATE_DIRECTORY before handing off to the component's process. The Helm chart mounts those templates, so most deployments never set it directly.

Geo is the one component that needs an explicit setting. The log cursor reads DB_SCHEMA_TARGET, which selects the Geo tracking database rather than the main one, and the image sets it to geo already. Enabling Geo on a secondary site is a matter of adding the component to the chart:

cat > geo-values.yaml <<VALUES
global:
  geo:
    enabled: true
    role: secondary
gitlab:
  geo-logcursor:
    image:
      repository: cgr.dev/ORGANIZATION/commercial-gitlab-geo-logcursor-ee
      tag: "latest"
VALUES

Advanced Search needs no configuration in the image. The gitlab-elasticsearch-indexer binary that GitLab shells out to is installed in the Rails-based images, at the version the GitLab release pins, so enabling Advanced Search in the GitLab administration area is sufficient.

Documentation and Resources

• GitLab Helm chart documentation
• GitLab Geo documentation
• GitLab Advanced Search documentation
• Chainguard Academy

What are Chainguard Containers?

Chainguard's free tier of Starter container images are built with Wolfi, our minimal Linux undistro.

All other Chainguard Containers are built with Chainguard OS, Chainguard's minimal Linux operating system designed to produce container images that meet the requirements of a more secure software supply chain.

The main features of Chainguard Containers include:

• Minimal design, without unnecessary software bloat
• Daily builds to ensure container images are up-to-date with available security patches
• High quality build-time SBOMs attesting to the provenance of all artifacts within the image
• Verifiable signatures provided by Sigstore
• Reproducible builds with Cosign and apko (read more about reproducibility)

For cases where you need container images with shells and package managers to build or debug, most Chainguard Containers come paired with a development, or -dev, variant.

In all other cases, including Chainguard Containers tagged as :latest or with a specific version number, the container images include only an open-source application and its runtime dependencies. These minimal container images typically do not contain a shell or package manager.

Although the -dev container image variants have similar security features as their more minimal versions, they include additional software that is typically not necessary in production environments. We recommend using multi-stage builds to copy artifacts from the -dev variant into a more minimal production image.

Need additional packages?

To improve security, Chainguard Containers include only essential dependencies. Need more packages? Chainguard customers can use Custom Assembly to add packages, either through the Console, chainctl, or API.

To use Custom Assembly in the Chainguard Console: navigate to the image you'd like to customize in your Organization's list of images, and click on the Customize image button at the top of the page.

Learn More

Refer to our Chainguard Containers documentation on Chainguard Academy. Chainguard also offers VMs and Libraries — contact us for access.

Trademarks

This software listing is packaged by Chainguard. The trademarks set forth in this offering are owned by their respective companies, and use of them does not imply any affiliation, sponsorship, or endorsement by such companies.