GitLab Installation and Updates

3/31/2026

This post details the migration of `packages.gitlab.com` to a new package hosting system, impacting URL formats, GPG key locations, network requirements, and the UI. It outlines the timeline for the transition, the required actions for users with existing installations (re-running installation scripts, updating GPG key references, firewall allowlists, mirroring configurations, and Runner RPM references), and the specific changes in DEB repository URLs, GPG key URLs, installation scripts, direct package download URLs, and GitLab Runner `noarch` RPM package paths. It also highlights the shift in download redirection to Google Cloud Storage and the need to update firewall/proxy allowlists. UI changes and feedback mechanisms are also mentioned.

2/24/2026

This post details the extension of the GPG key used to sign the metadata of GitLab's apt and yum repositories. The current key, with fingerprint F640 3F65 44A3 8863 DAA0 B6E0 3F01 618A 5131 2F3F, has been extended from February 27, 2026, to February 6, 2028. This extension is a security measure to limit exposure in case of compromise and to reduce disruption for users compared to a full key rotation. Instructions are provided for users who have already configured repositories to update their trusted key, while new users will automatically receive the correct key during installation.

2/20/2026

The Omnibus package signing key, previously set to expire on Feb. 14, 2026, has been extended to expire on Feb. 16, 2028. This extension is a periodic measure to comply with GitLab security policies and limit exposure in case of compromise. The extension, rather than a rotation, is chosen to minimize disruption for users who validate package signatures. Users who validate signatures need to update their copy of the package signing key.

12/1/2025

This post details the technical implementation and operational challenges of deploying the world's largest GitLab instance (GitLab.com) up to 12 times daily without downtime. It elaborates on the automated deployment pipeline built using GitLab CI/CD, including the build process for Omnibus packages and Cloud Native GitLab (CNG) images, the creation of auto-deploy branches, and the deployment sequence. It specifically highlights the canary deployment strategy with environment-based validation across Staging Canary, Production Canary, Staging Main, and Production Main stages, including QA checkpoints and traffic monitoring. The post also delves into technical architecture considerations for hybrid infrastructure (VMs and Kubernetes), the challenges of multi-version compatibility during deployments (database schema ahead of code), and the atomic upgrade mechanisms for Gitaly using tableflip.

4/16/2025

This post details the rotation of the GPG key used to sign GitLab Omnibus Linux packages. It explains the purpose of the key for ensuring package integrity, distinguishes it from repository metadata signing keys, and provides instructions for users who validate GPG signatures to update their key. It also specifies the new key fingerprint and provides a URL to download the new key.

11/25/2024

Introduced improved user contribution and membership mapping for group and project imports, enabling post-import reassignment of contributions and memberships. This feature is email-independent and requires user acceptance for attribution. It is available for direct transfer migrations and GitHub, Bitbucket Server, and Gitea importers. Upcoming improvements include CSV-based reassignment and enhanced UI visibility for placeholder limits.

8/28/2024

This post provides a tutorial on migrating from Google Cloud Source Repositories to GitLab. It outlines the steps involved, including creating a GitLab project, generating a personal access token, using Cloud Shell Editor, adding GitLab as a remote, and pushing the repository. It also highlights the benefits of using GitLab, such as its unified DevSecOps platform, Google Cloud integration, and CI/CD capabilities.

5/31/2024

The Omnibus package signing key, used to ensure the integrity of GitLab Omnibus packages, has had its expiration date extended from July 1, 2024, to July 1, 2025. This extension is a security measure to limit exposure should the key be compromised and is done to minimize disruption for users who verify package signatures. Users who validate package signatures need to update their copy of the signing key.

2/1/2024

This post details the migration of Jenkins CI/CD pipelines to GitLab CI/CD. It outlines the benefits of migrating to a unified DevSecOps platform over a DIY DevOps approach with Jenkins, including planning, change management, defining migration goals, prerequisites, and the process of migrating repositories and CI/CD configurations. It emphasizes the advantages of GitLab's integrated SCM and CI/CD capabilities.

11/30/2023

Introduced parallel, asynchronous importers for Bitbucket Server (GitLab 16.1) and Bitbucket Cloud (GitLab 16.6) to overcome timeouts on large projects. Improved error handling to prevent single object errors from stopping the entire import. For Bitbucket Server, fixed issues with merged/closed MRs lacking commit data (GitLab 16.5) and began importing reviewers (GitLab 16.3) and pull request approvals (GitLab 16.6). For Bitbucket Cloud, addressed issues with squashed and merged PRs losing commit data (GitLab 16.6), converted Bitbucket refs to GitLab refs in notes (GitLab 16.6), stopped importing deleted notes (GitLab 16.6), and began importing LFS objects (GitLab 16.5) and pull request reviewers (GitLab 16.6).

6/14/2023

This post details the extension of the Omnibus package signing key's expiration from July 1, 2023, to July 1, 2024. This is a security measure to comply with policies and limit exposure in case of compromise, while avoiding disruptive key rotation for users who verify package integrity. It provides instructions for users who validate signatures to update their key and directs them to documentation for verification procedures.

9/21/2022

This post announces GitLab's achievement of the Amazon Linux 2 Service Ready Partner designation. It details the evidence provided to AWS regarding support, compatibility, and security testing for deploying GitLab on Amazon Linux 2. It also mentions that Amazon Linux 2 RPM packages are available for GitLab from version 15.0 and for GitLab Runner, including ARM64 binaries. The post outlines the rigorous process the Distribution Team follows for packaging and supporting Amazon Linux 2, including CI build environments, compatibility tests, security scanning, and AMI creation.

5/2/2022

This post announces the official support for Amazon Linux 2 as a distribution for GitLab instances and runners, starting with GitLab version 15.0. It details the availability of distro-specific packages for x86 and ARM architectures and outlines the transition plan from the previous workaround of using EL7 packages for Amazon Linux 2. It provides specific instructions and code snippets for users to test and manage this transition in their automation, including how to peg to EL7 packages or adopt the new Amazon Linux 2 packages early. It also highlights the availability of ARM RPM packages for Amazon Linux 2 and the upcoming changes to the `script.rpm.sh` script.

4/18/2022

This post details breaking changes and feature removals in GitLab 15.0, impacting areas such as audit events, API endpoints, OAuth flows, SSH and PAT expiration enforcement, pipeline configurations, authentication methods, feature flags, GraphQL fields, runner status reporting, CI/CD keywords, test coverage settings, container registry authentication, and package settings permissions. Specific removals include audit events for repository push events, pass-by-default requests for the external status check API, OAuth implicit grant, OAuth tokens without expiration, optional enforcement of SSH and PAT expiration, required pipeline configurations from Premium tier, `omniauth-kerberos` gem, `PUSH_RULES_SUPERSEDE_CODE_OWNERS` feature flag, `defaultMergeCommitMessageWithDescription` GraphQL API field, `offline`/`not_connected` runner statuses in API, `artifacts:report:cobertura` keyword, `disable_strict_host_key_checking` default to `false` for SSH executor, `not_connected` runner status API value, `type`/`types` CI/CD keywords, project setting for test coverage parsing, `htpasswd` authentication for Container Registry, and GraphQL permissions for package settings.

3/14/2022

This post details a manual workaround for installing GitLab CE on Raspberry Pi OS 64-bit by manually configuring apt sources to use Debian Buster repositories, as official ARM64 support was still in development at the time of writing. It outlines the steps to fetch the script, update apt, install prerequisites, create a new sources list file, and add the necessary repository entries before performing the standard installation.

12/17/2021

This post details the update of the GitLab Chart and Operator to support Kubernetes 1.22. This involves updating the NGINX Ingress Controller to version 1.0.4, which necessitates dropping support for Kubernetes versions prior to 1.19. Users still requiring support for older versions can deploy up to Chart version 5.5.x. The post explains the technical reasons for this change, referencing the deprecation of the `networking.k8s.io/v1beta1` API and the use of a forked ingress-nginx Chart based on version 4.0.6. It also outlines the impact on users and potential DNS record changes.

11/16/2021

This post details the installation and usage of the GitLab Kubernetes Operator on an OpenShift Container Platform cluster. It covers prerequisites like Prometheus and cert-manager, the application of the Operator CRD, and the creation of a GitLab instance via a Custom Resource file. It also outlines how to obtain the initial root password and log in to the newly deployed GitLab instance.

10/12/2021

Introduced the general availability of the GitLab Operator, which allows for the deployment and operation of production GitLab instances on Kubernetes platforms, including Red Hat OpenShift. The Operator utilizes the Operator pattern to automate Day 1 (installation, configuration) and Day 2 (upgrades with minimized downtime) tasks. It expands upon the Cloud Native Helm Chart by actively securing deployments and keeping components up-to-date, and supports both vanilla Kubernetes and Red Hat OpenShift.

6/30/2021

This post details the technical steps for deploying a self-managed GitLab instance in AWS Marketplace. It covers subscribing to the GitLab Ultimate offering, configuring EC2 instances and security groups, launching the instance, and accessing the GitLab UI. Additionally, it provides instructions for installing the GitLab Runner and Docker Engine on the same instance, and registering the runner with GitLab. This contributes to the 'GitLab Installation and Updates' feature thread by demonstrating a specific deployment scenario and the setup of essential CI/CD components.

6/16/2021

This post details the rotation of the GPG key used to sign official GitLab Runner packages due to a security incident where the key and other distribution tokens were not secured according to policy. It provides the old and new GPG key fingerprints, explains the impact on users (none for shared runners, action required for those using package signature verification), and outlines the steps for updating the key. It also clarifies that new users are unaffected but should use the new key for verification.

6/15/2021

Introduced the GitLab Environment Toolkit (GET) for automating the deployment of GitLab Omnibus and Helm Charts at scale. GET utilizes Terraform for provisioning infrastructure (VMs, Kubernetes clusters, supporting services like load balancers and firewalls) across GCP, AWS, and Azure, and Ansible for configuration. It supports various GitLab Reference Architectures (100 to 50,000 users), Cloud Native Hybrid Reference Architectures (GCP), upgrades, Geo, and zero-downtime upgrades. The toolkit is designed to be 'boring' (simple and maintainable) and complements, rather than replaces, GitLab Omnibus and Helm Charts.

6/25/2020

Extended the expiration of the GPG key used to sign Omnibus packages from 2020-07-01 to 2021-07-01. This is a security practice to limit exposure if the key is compromised and to comply with GitLab security practices, while being less obtrusive than generating a new key annually. Users who validate package signatures need to update their copy of the signing key.

3/30/2020

This post details the rotation of the GPG key used to sign GitLab package repository metadata. The existing key is expiring, and a new key with fingerprint `F640 3F65 44A3 8863 DAA0 B6E0 3F01 618A 5131 2F3F` will be active for two years starting April 6, 2020. Existing users who have configured these repositories will need to add the new public key to avoid package fetching failures. New users configuring repositories for the first time after the change will automatically receive the new key.

10/2/2019

This post details the transition to a single codebase for GitLab Community (CE) and Enterprise (EE) Editions. It explains that this consolidation simplifies the contribution workflow by providing a single place for issues and merge requests. The post also clarifies that licenses remain the same (CE under MIT, EE proprietary) and that this change primarily impacts contributions to the main GitLab repository, not other related projects like Charts, GitLab Design System, GitLab UI, Omnibus, or Runner. It highlights the elimination of `ee_compat_check` errors for contributors.

8/23/2019

This post details the decision and technical approach to merge GitLab Community Edition (CE) and Enterprise Edition (EE) into a single codebase. It explains the challenges of maintaining separate repositories, the complexity introduced by merge requests across repositories, and the decision to consolidate into a single repository. The technical solution involved separating proprietary code from shared code using Ruby modules and injection, refactoring large code chunks, and ensuring database schema consistency. The chosen approach was to move all development into the gitlab-ee repository, renaming it to 'gitlab', and archiving gitlab-ce. gitlab-foss will serve as a mirror of the new 'gitlab' repository with proprietary code automatically removed. This involved 55 engineers, over 600 merge requests, and changes to nearly 1.5 million lines of code.

6/7/2019

Proximus details their migration from ClearCase to GitLab CE and subsequently to GitLab EE. They highlight the growth in projects and users, the adoption of GitLab CI, Jira integration, and experimentation with global search. They also mention challenges with pipeline resource consumption and how a feature in GitLab 11.6 helped mitigate this. The post quantifies the reduction in support tickets as a key result.

2/21/2019

This post proposes merging the gitlab-ce and gitlab-ee Rails repositories into a single `gitlab` repository. The motivation is to eliminate duplicated work, reduce conflicts during feature development and release preparation, and save engineering time currently spent on managing two separate codebases. The proposed change involves moving all frontend assets to be open-sourced under MIT license, placing proprietary backend code in an `/ee` directory, and merging documentation. The gitlab-ce distribution will remain open source, and other projects will be unaffected. Downsides include users cloning a larger repository and the presence of unpopulated database tables in the CE distribution.

1/23/2019

This post details the addition of support for Microsoft Exchange and Google Groups as email servers for self-managed GitLab instances. This enables features dependent on incoming email, such as replying to notifications, creating issues/MRs via email, and Service Desk functionality, for users whose email servers do not support sub-addressing but do support catch-all mailboxes. This expands the compatibility of GitLab's incoming email features.

6/8/2016

This post introduces the GitLab Development Kit (GDK) as a tool to simplify the setup of a local development environment for contributing to GitLab. It details the installation of prerequisites, cloning the GDK repository, forking necessary GitLab components (CE, EE, Shell, Workhorse), configuring GDK with these forks, starting the development environment, making code changes, running tests (RSpec, Spinach), and opening merge requests. It highlights the multi-component nature of GitLab (database, Redis, Sidekiq, Rails, Workhorse, Shell) and how GDK manages them.

4/27/2016

This post details the process of deploying GitLab Community Edition on a DigitalOcean droplet using the GitLab One-Click Install Image and the Omnibus installer. It covers the requirements for hardware, the steps to create a GitLab droplet, configure domain names and emails, log into GitLab, and modify account information. It also touches upon updating to newer releases and creating backups.

3/21/2016

This post introduces and explains the Omnibus GitLab package as a solution to simplify GitLab installation and upgrades. It details the 'Omnibus concept' from Chef, where a single binary package includes all dependencies and components, ensuring predictable behavior. The post contrasts this with the complexity of installing GitLab from source, highlighting the length and potential stress of manual installations and upgrades. It outlines the benefits of Omnibus for both users (ease of installation, configuration, and upgrades) and maintainers (consistent environments, easier support, streamlined releases). The post also discusses alternatives considered, such as Docker images, native Debian/Fedora packages (mentioning ongoing community efforts), and configuration management tools, explaining the trade-offs and why Omnibus remains the primary solution for frequent GitLab updates. It concludes by encouraging contributions to the Omnibus project and offering support for platform-specific packaging efforts.

3/14/2016

This post introduces GitLab.com as a hosted solution, eliminating the need for manual installation. It highlights the introduction of 'Omnibus' as a tool for simplified installation and updates of GitLab on self-hosted servers, reducing installation time significantly. It also details the embedded nature of Continuous Integration (CI) within GitLab, explaining the role of 'runners' in executing tests and builds, and the availability of 'Shared Runners' on GitLab.com.

6/25/2015

This post details the critical role of the Release Manager in GitLab's monthly release cycle, highlighting the complexity of coordinating thousands of commits across multiple repositories (CE, EE, CI, runners, Omnibus). It traces the evolution of the release process from manual, undesirable tasks to a highly automated, CI-oriented system. Key improvements include the removal of code freeze, automated repository syncing, automated package building via Omnibus, and automated deployment infrastructure. The post also discusses the ongoing challenge of finding volunteers for the Release Manager role, despite the significant improvements in the process.

6/12/2015

This post addresses a security vulnerability (CVE-2014-9390) related to installing GitLab from source, specifically when Git is also compiled from source. It advises users who installed from source to check their Git version and upgrade if necessary to prevent their GitLab server from being used to deliver 'poisoned' Git repositories. It reinforces the recommendation to use Omnibus packages for a more secure and simplified installation.

6/5/2015

This post details the internal architecture of GitLab's web server (Unicorn) and its memory management (unicorn-worker-killer). It explains how Unicorn handles web requests with a multi-process architecture for better CPU utilization and fault tolerance, and how unicorn-worker-killer manages memory leaks in worker processes by automatically restarting them. This information is crucial for understanding the operational aspects and stability of self-managed GitLab installations.

6/4/2015

This post details a significant outage on GitLab.com in May 2015, caused by a backup script issue and exacerbated by insufficient on-call engineer training and documentation following a recent infrastructure upgrade. It highlights the challenges of managing a complex, multi-server infrastructure and the critical need for robust backup strategies, automated validation, and well-trained operations teams to ensure service availability. The post outlines immediate steps taken, such as removing the problematic freeze/unfreeze steps from backups and implementing regular operations drills.

5/7/2015

This post introduces a version check functionality for GitLab. This feature aims to combat the problem of outdated servers by making them visible to users. The version check works by loading an image from version.gitlab.com on the /help page, which indicates the update status (green for up-to-date, yellow for out-of-date, red for missing security updates). The image request includes the GitLab version and server hostname (though the hostname is later revised to be inferred from the HTTP referer header). The functionality is opt-out and aims to provide insights into GitLab usage to improve the platform, while acknowledging the trade-offs in maintenance and operational capacity.

5/1/2015

This post announces the availability of GitLab Omnibus packages for Debian 8, enabling early adopters to run GitLab on this new platform. It provides installation instructions using `curl` and `apt-get`.

3/11/2015

Introduced Amazon Machine Images (AMIs) for GitLab CE, simplifying deployment on AWS. These AMIs are pre-configured with the GitLab CE Omnibus package, allowing users to launch a GitLab instance with a single command (`sudo gitlab-ctl reconfigure`). This leverages the same Omnibus package used to run GitLab.com on AWS.

3/9/2015

This post details a complex data migration of GitLab.com from on-premises hardware to AWS. It highlights the challenges of moving 9TB of data with minimal downtime, exploring DRBD as a solution for live data synchronization and detailing the intricate networking setup (IPIP tunnels, IPsec) required to bridge the on-premises and AWS environments. It also touches upon the use of DRBD for high availability and the transition to AWS EBS for easier backups.

2/6/2015

This post argues for the consolidation of multiple code collaboration tools into a single platform, specifically highlighting GitLab Enterprise Edition as a solution. It details the challenges of managing disparate systems (collaboration friction, complex security, integration overhead, multiple support agreements) and presents the benefits of a unified approach: improved cross-team collaboration, simplified security management, reduced administrative burden, and lower commercial overhead. It also addresses potential caveats like vendor lock-in and workflow restrictions, suggesting GitLab's scalability and Git's flexibility as solutions. Finally, it encourages users to explore GitLab's offerings and migration tools.

1/20/2015

This post positions GitLab Enterprise Edition as a strong competitor to GitHub Enterprise, highlighting its advantages in focusing on enterprise needs (e.g., protected branches, UI-based rebasing, LDAP synchronization, internally visible projects), ease of operation and scaling (simple architecture, stateless application server, high performance, ability to modify), and inclusive pricing that enables broader organizational access. It implicitly reinforces the ongoing efforts to simplify installation and operation by emphasizing these as key differentiators.

1/3/2015

This post details a significant shift in GitLab.com's hosting strategy, moving from Amazon's AWS to self-hosted hardware to manage costs and gain more control over performance. It highlights the specific hardware used (HP DL180 G6 servers with substantial cores, RAM, and storage) and the custom DRBD tooling developed for failover. It also foreshadows a future return to AWS for scalability.

12/30/2014

This post highlights a critical issue encountered during a database migration for GitLab 7.6, specifically a failure in MySQL when removing columns that had a composite index. It details how a seemingly simple migration that worked in PostgreSQL failed in MySQL due to the database's behavior in rebuilding indexes. The post explains the fix by adding a check for index existence before removal and emphasizes the importance of thorough testing across different database backends during the update process.

12/8/2014

This post introduces UDP log shipping as a feature within GitLab Enterprise Edition (7.1 and up) Omnibus packages. It addresses the operational challenge of managing logs in large GitLab instances by providing a fast, lightweight, and non-blocking method for sending logs to a separate server, preventing log-related issues from impacting the main GitLab instance. The post details the configuration process and explains the underlying technology (svlogd and remote_syslog) that enables this functionality.

11/6/2014

This post announces the integration of GitLab CI Coordinator into the GitLab Omnibus packages. This significantly simplifies the installation and setup of GitLab CI for users who are already using or adopting the Omnibus installation method, allowing them to have a CI Coordinator running on their GitLab server with minimal configuration steps.

2/14/2014

Introduced three new simplified installation options: an official GitLab Chef cookbook, GitLab Packer virtual machines, and GitLab Omnibus packages. The Omnibus packages, built using `omnibus-ruby`, allow for installation with a single command (`apt-get install -y openssh-server postfix dpkg -i gitlab_6.6.0.pre1.omnibus.2-1.ubuntu.12.04_amd64.deb gitlab-ctl reconfigure`). Initial Omnibus packages have reduced feature support (e.g., no application backups or HTTPS).