FIPS-compliant self-managed GitLab

When FIPS-compliant GitLab is required and what it changes

A FIPS requirement usually reaches the GitLab team as a clause in a contract, a control baseline or an assessor's request for FIPS-validated cryptography protecting source code and CI/CD data. Start by confirming which requirement applies and which data it covers. The FBI CJIS Security Policy version 6.1 requires FIPS 140-3 certified modules, or FIPS 197 AES with at least 256-bit keys, for criminal justice information in transit and at rest outside physically secure locations, and it calls for vulnerability scanning at least monthly. Broader federal baselines drawn from NIST SP 800-53 Rev. 5 map to controls such as SC-13 and SC-28, which an assessor will trace into your GitLab design.

FIPS mode changes a specific set of GitLab behaviors. The deployment uses FIPS-enabled container images, password hashing moves to PBKDF2-SHA512, and SSH keys must meet the key type and length rules that FIPS mode enforces. Those changes do not make the whole system compliant. The operating system kernel and crypto libraries, PostgreSQL, Redis, object storage, TLS termination, Runner hosts and any integrations each need their own validation evidence. Before you commit, confirm in GitLab's current FIPS documentation which SSH key types and lengths are accepted, how existing password hashes and user keys are handled during the switch, and which known issues apply to your host operating system.

DeployOpen plans and builds the FIPS-mode deployment, documents the cryptographic configuration, and prepares the control evidence an assessment will ask for. Independent auditors and certification bodies decide whether your environment meets the requirement. Ask for a written scope that lists every component in the boundary, the FIPS validation status you have confirmed for each one, and the evidence each control will need before the assessment begins.

Deployment options for FIPS GitLab and when each fits

This table compares the three practical ways to run self-managed GitLab in FIPS mode: the Linux package on a FIPS-enabled host, FIPS container images, and the Helm chart or Operator. Read each row against your patching cadence, your support arrangement and how much control you need over host cryptography. Confirm every option against the installation methods page for your target GitLab release before you commit.

Decision point	Linux package on FIPS RHEL-family host	FIPS container images on Kubernetes or Docker
Where FIPS is enforced	Host kernel and OpenSSL run in FIPS mode, so the operating system governs the cryptographic modules GitLab uses	Image build supplies FIPS-validated components, so the container runtime and node OS still need their own FIPS review
Host crypto control	High: you select, configure and verify the host crypto policy directly	Medium: you control node images and runtime settings, but the crypto libraries ship inside the image
Patching ownership	Your team patches the OS and applies GitLab package updates on the upgrade stops you plan	Your team rebuilds or pulls image tags and rolls them through the cluster, plus node OS patching
Operational skill needed	Linux administration, package-based upgrades and gitlab.rb configuration	Kubernetes or container operations, image registry management and Helm or Compose configuration
Support and evidence	Host FIPS status is easy to show an assessor with OS-level checks and logs	Evidence spans image provenance, cluster policy and node configuration, so more artifacts to collect
Best fit	Teams with standard RHEL-family estates and existing FIPS hardening practice	Teams already running Kubernetes with image pipelines and a registry they control

How to set up a FIPS GitLab instance step by step

This sequence takes a self-managed GitLab instance from a planned version and upgrade path to a FIPS-enabled host, package, password and SSH policy, TLS and storage configuration, and a set of recorded checks. Each step closes with a verification the reader can repeat and file as evidence.

Confirm the target version and upgrade stops
The architect or platform lead picks the target GitLab release from the lines GitLab currently maintains, then maps every required upgrade stop between the installed version and that target. Stops fall at x.2, x.5, x.8 and x.11 in the current pattern, so the plan should list each stop in order. Confirm the maintained lines and stop versions against the upgrade paths documentation before any change. Done means a written version record exists, and the current version reported on the existing instance matches the first step in that plan.
Prepare a FIPS-enabled operating system
The infrastructure team enables FIPS mode on the operating system before GitLab is installed, using the method for the chosen distribution and checking GitLab's supported operating system list for FIPS. Kernel and cryptographic library state must be set first because GitLab and its bundled components inherit it. Confirm the distribution's FIPS procedure with its vendor documentation. Done means the host reports FIPS mode as enabled, for example through fips-mode-setup --check on Red Hat family systems or by reading /proc/sys/crypto/fips_enabled where it returns 1.
Install the FIPS-capable package or image
The platform engineer selects the installation method that GitLab documents for FIPS, such as a FIPS-tagged Linux package or container image, and confirms that the artifact exists for the exact target version. Helm chart and Operator installs need their own confirmation, because FIPS support is not guaranteed across every method. Install on the prepared host, then run gitlab-ctl status and confirm every service is up. Done means services report as running and the installed package version matches the target recorded in step one.
Set password and SSH key policies
The security engineer configures password hashing to the PBKDF2-SHA512 method that GitLab documents for FIPS hosts and sets the minimum SSH key types and lengths the policy requires, using the values confirmed in the current GitLab documentation. Existing passwords and keys may need rehashing or replacement, so the team should plan user communication. Done means a test user's new password is stored in the expected hash format, and a test SSH key of an approved type and length is accepted while a weaker test key is refused.
Configure TLS and approved cipher suites
The network or security engineer installs certificates from the organization's certificate authority and restricts TLS versions and cipher suites to those the FIPS-enabled host and the security baseline allow. The same policy should cover the Container Registry, Pages and any external endpoints the instance exposes. Confirm acceptable protocol and cipher choices with the assessor or the baseline owner. Done means an openssl s_client handshake to the GitLab hostname negotiates an approved protocol and cipher, and the result is saved with the change record.
Connect database and object storage
The platform team points GitLab at its PostgreSQL, Redis and object storage endpoints, confirming that each service uses cryptographic modules acceptable for the data it holds. Where criminal justice information is involved, the FBI CJIS Security Policy version 6.1 requires FIPS 140-3 validated modules or AES with 256-bit keys for data in transit and at rest outside physically secure locations. Done means a test artifact uploads to object storage, a backup runs to completion, and a restore into a scratch environment succeeds.
Run GitLab health and security checks
The operations team runs GitLab's built-in check task, gitlab-rake gitlab:check, and reviews every failing item against the FIPS configuration. The hardening documentation should be applied gradually, starting with application settings and configuration files such as gitlab.rb, and each change is logged. Done means the check task reports no unexplained failures, each accepted exception has a named owner and reason, and the configuration files are stored under version control.
Schedule scanning and archive the evidence
The compliance lead sets a recurring vulnerability scan that covers the host, the GitLab instance and its dependencies, with the cadence set by the control baseline that applies. For CJIS-scoped systems, the policy requires vulnerability scanning at least monthly. The lead also collects the evidence from steps one through seven into one package for the assessor. Done means the first scan report is stored, the evidence package has an index, and the owner has confirmed the scope with the independent auditor or certification body.

Known issues on FIPS hosts and how to plan around them

Keys are often the first surprise on a FIPS host. The operating system's cryptographic policy decides which SSH key algorithms and sizes can be used, and that policy applies to Git over SSH, the GitLab Shell service and any runner or mirror that authenticates with a key. Users who created keys years ago may hold key types the FIPS module no longer accepts, so the failure often appears as a rejected push or clone instead of a clear message from GitLab.

Inventory existing keys: Export the key types and lengths registered for users and deploy keys before you enable FIPS mode, and count how many fall outside the approved set.
Client versions: Older Git clients and OpenSSH builds on developer laptops and build hosts may offer algorithms the FIPS policy rejects, so test the client versions your teams actually use.
Host keys: Confirm which host key types the GitLab server presents and update the known_hosts entries that clients pin, because a changed host key looks like an attack to most clients.
User communication: Publish the supported key types and the steps to generate and register a replacement key before cutover.

Check the key types and minimum sizes that GitLab documents for FIPS hosts in your release, and test a clone and push from every client platform before production cutover. The GitLab hardening recommendations are a useful starting point for the surrounding configuration.

Security and operational considerations for FIPS GitLab

A FIPS build is only as strong as the operational habits around it. The six areas below cover where cryptographic state lives, how it changes over time, and how you confirm it still holds after each change.

Key and secret handling

GitLab keeps encryption keys and secrets in its secrets file, and losing or mismanaging that file can make encrypted database values and CI variables unreadable. Store the secrets file with restricted permissions, keep a separate encrypted copy that is not on the same host as the database backup, and record who can read it. Confirm with GitLab's documentation which keys are generated on first install and which you must supply, and plan rotation as a change-controlled task. Check that any external secrets manager you connect also runs on approved cryptographic modules.

Certificate lifecycle

Every TLS endpoint in the GitLab estate needs a certificate that the FIPS provider can use, including the GitLab web endpoint, the container registry, Runner connections and the identity provider. Confirm the key type and size your certificate authority issues are accepted on the FIPS host before you order them. Track expiry dates for each certificate in one inventory, and rehearse renewal on a staging instance because an expired certificate can stop Git over HTTPS, Runner registration and sign-in at once. Record which internal CA signs each certificate.

FIPS drift during upgrades

Upgrades can silently change the cryptographic posture of a FIPS deployment when a new package, image variant or base operating system replaces the approved one. GitLab requires you to stop at defined upgrade versions, so each stop is a checkpoint where you should confirm the FIPS-enabled kernel or base image, the FIPS image variant and the password hashing and SSH settings are still in place. Run the same checks after every stop, not only at the final version, and record the results in your change ticket.

Backup encryption

A GitLab backup bundles the database, repositories, uploads and the secrets file, so it carries the most sensitive material in the instance. Encrypt backups with a cryptographic module your assessor accepts, and store the keys apart from the backup target. Test a full restore onto a FIPS host at a planned interval, because a backup that restores only on a non-FIPS system may not meet your requirements. Ask your team to confirm whether the backup tooling, object storage client and transport each use approved algorithms.

Runner trust boundaries

CI/CD jobs receive project variables and tokens, and a Runner host that does not share the FIPS posture of the GitLab server can weaken protections for that data. Decide which Runner hosts are allowed to handle protected branches and sensitive variables, and place them in their own network segment with least-privilege access to the GitLab server. Keep Runner versions aligned with GitLab, as GitLab advises, and confirm that Docker or autoscaling images used by jobs contain only approved cryptographic libraries.

Monitoring crypto configuration

Configuration drift is hard to see without a baseline, so record the FIPS mode state, cipher and key settings, and certificate inventory as a known-good snapshot after each change. Compare the live instance against that snapshot on a schedule, and alert on authentication failures or configuration edits in the GitLab audit and system logs. Assign one owner to review these results, and confirm with your assessor which evidence format they accept for ongoing monitoring of cryptographic settings.

Limits to confirm before committing to FIPS mode

FIPS mode narrows what you can run and how you prove it. The checks below sit between the GitLab build and the evidence your assessor will ask for, and each one should be answered in writing before the scope is signed.

Validated versus FIPS-compatible components

Ask GitLab which parts of the stack use cryptographic modules that carry a FIPS 140-3 validation certificate, and which parts are only designed to work with FIPS-enabled libraries. These are different claims. A component that is FIPS-compatible may still need its own evidence. Get the list for the GitLab version you will deploy, including bundled PostgreSQL, Redis and Gitaly, and confirm whether each one is in your scope.

Supported OS and kernel combinations

FIPS mode depends on the operating system's crypto policy and kernel, not only on GitLab. Ask GitLab and your OS vendor which distribution, release and kernel pairings are tested with FIPS enabled for your chosen install method. A combination that boots and passes a smoke test may still be unsupported. Record the exact OS build in your system security plan so the evidence matches what runs.

Runner and third-party integration support

GitLab Runner, container images, external registries, secrets managers and chat or issue integrations each make their own TLS and SSH choices. Ask which of them you can run in FIPS mode without a workaround, and whether the Runner executors you plan to use (shell, Docker or autoscaling) have been tested with FIPS hosts. Any integration that falls outside FIPS mode needs a documented exception.

Password and SSH key rules for users

FIPS mode changes which password hashes and SSH key types work. Confirm with GitLab how existing user passwords are rehashed, what happens to accounts created before the switch, and which SSH key lengths and algorithms are accepted for Git over SSH. Plan a communication to developers before cutover, because keys that worked before may be rejected after it.

Assessor acceptance of the module certificate

A validation certificate proves a module was tested, not that your deployment uses it correctly. Ask your assessor whether they accept the module certificate as evidence, or whether they also want configuration proof, a FIPS-enabled kernel check and a record of which algorithms are in use. Agree this before you build, because the answer decides which logs, screenshots and test results you must collect.

Upgrade and patch impact on validation

A FIPS-validated build can change when you update packages, GitLab versions or the OS. Ask whether an upgrade keeps the same validated configuration, whether a new GitLab release needs a fresh check, and how security patches are delivered to FIPS hosts. GitLab's upgrade stops and patch cadence mean this check repeats throughout the life of the instance, so budget time for it.

Questions buyers ask about FIPS GitLab cost, effort and scope

What drives the cost of a FIPS GitLab deployment?

The main drivers are the number of instances and environments, the install method and reference architecture, how much hardening and validation work is in scope, and whether the host operating system and container images must be FIPS-enabled for your assessment. Costs fall into four groups: the partner's fixed-scope fee for design, configuration, testing and handover; your cloud or data center charges; GitLab subscriptions, which the pricing page lists at 0 US dollars for Free and 29 US dollars per user per month billed annually for Premium, with higher tiers custom priced; and internal staff time. Ask for a quote that itemizes each group and states what is excluded, including who maintains the FIPS configuration after go-live.

Can our internal team implement FIPS GitLab without a partner?

A team with strong Linux, GitLab administration and cryptographic policy experience can do it, but the work touches OS crypto policy, container image selection, SSH settings, password hashing and the upgrade process, and each change has to be verified on the same host type you run in production. Many organizations split the work: the internal team owns the runbooks and day-to-day operations, while an outside partner handles configuration, test evidence and an independent review. Before deciding, confirm that you have at least one person who has taken GitLab through a required upgrade stop and who can own the evidence file.

What does our team need to provide before FIPS GitLab work starts?

The work starts from written requirements, so bring the following to the scoping call:

The regulation or contract that drives FIPS use, such as CJIS Security Policy requirements for criminal justice information or a federal agency contract, and the systems it covers.
Where GitLab will run: cloud accounts, data centers or an air-gapped network.
Your current or planned GitLab version, install method and expected user count.
Your identity provider, backup target and any integrations that must work in FIPS mode.
Access to a staging environment, change windows, and named approvers for configuration changes.

How long does a FIPS GitLab implementation take?

The supplied material does not give a duration for this work, so the timeline should come from the written scope rather than a general estimate. The biggest timing factors are the number of instances, whether you migrate existing data, whether the network is offline, the size of the reference architecture (GitLab's documented range runs from 1,000 to 50,000 users, and it generally recommends high availability from 3,000 users), and how much evidence your assessor expects. Ask for milestones with entry and exit criteria, the point at which your team must provide input, and what happens if a required dependency changes during the project.

What is one-time work and what recurs after a FIPS GitLab go-live?

One-time work includes the design, initial configuration, first validation pass, documentation and runbook creation. Recurring work is larger than most buyers expect. GitLab ships a minor release on the third Thursday of each month and patch releases twice a month, and upgrades must pass through required stops at versions x.2, x.5, x.8 and x.11. Runners should stay aligned with GitLab's major and minor versions. CJIS Security Policy version 6.1 calls for vulnerability scanning at least monthly for systems handling criminal justice information. Each change needs re-verification. A support retainer can cover this work, and you should confirm its scope in writing.

How do GitLab upgrades affect FIPS status?

Upgrades can change container images, operating system packages and default cryptographic behavior, so FIPS status has to be checked again after every upgrade rather than assumed to carry over. Plan each upgrade against the required upgrade stops, test it on a staging copy of the production configuration, and record the before and after results. The maintenance policy also matters: bug fixes are backported only to the current stable release, and security fixes go to the previous two monthly releases as well, so staying on an old version to avoid change increases exposure. Confirm with GitLab which releases ship FIPS-appropriate images before you commit to a version.

Does our GitLab tier affect FIPS support?

The pricing page states that Free, Premium and the top paid tier are all available for self-managed installations, but the material we rely on does not state which tiers include FIPS-specific images or support. Confirm this with GitLab in writing before you choose a tier. Premium adds advanced CI/CD and priority support, and the higher tier adds application security testing, software supply chain security, vulnerability management and compliance features. These matter if your assessment depends on scanning and audit evidence produced inside GitLab. Map each feature you need to a tier and a supported configuration before purchase.

What evidence does DeployOpen provide for a FIPS GitLab deployment?

DeployOpen prepares systems, controls and evidence for compliance assessments, and the deliverables are defined in the written scope. Typical items include configuration records, documented build and hardening decisions, validation test results, runbooks, change records and an evidence map that links each setting to the control it supports, such as the controls in NIST SP 800-53 Rev. 5, the federal control catalog. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work, so ask your assessor early which artifacts they require and confirm they are in the deliverable list.

How DeployOpen scopes and delivers FIPS GitLab

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For FIPS-compliant self-managed GitLab, we start from the controls your assessor will test and work backward to the configuration, images and evidence that prove them.

How we scope

Written scope names the FIPS container images, host operating system and GitLab edition you will run.
Scope lists which authentication, SSH key and password settings must change for FIPS mode.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
Confirm with your assessor which control baseline and evidence set applies to your system.

How we build

We install and configure the FIPS-enabled GitLab path and verify each FIPS-dependent feature works as expected.
We test known issues on FIPS hosts against your planned runners, integrations and backup jobs before go-live.
We record configuration as code so the FIPS settings survive upgrades and rebuilds.
We align the upgrade plan with GitLab's required upgrade stops, so FIPS builds move through supported versions.

How we hand over

You receive runbooks covering configuration, backups, restore tests and FIPS-specific troubleshooting steps.
Test results show which FIPS checks passed, failed or were accepted with a documented exception.
Evidence packs map configuration to the controls in scope, ready for your independent auditor to review.
Knowledge transfer sessions cover day-two tasks for the administrators who will own the instance.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover tracking of GitLab release notes and FIPS-impacting changes before each upgrade.
We can re-run verification after host patches, image changes or GitLab version moves.
DeployOpen prepares evidence for assessments but does not issue audit reports, attestations or certifications.