TechPrufer
Get started
GitLab
GitLab logoGitLab · Feature trail

GitLab Installation and Updates

47 posts · Feb 2014 – May 2026

What this trail covers

GitLab's installation and update processes are continuously refined to support a wider range of hardware and operating system configurations. This includes efforts to enable official support for ARM64 architectures and provide optimized installation methods for platforms like Raspberry Pi OS, even when official support is still in development. The omnibus-gitlab package is the primary method for installation. This post details a migration of the package hosting system for `packages.gitlab.com` to extend the Omnibus package signing key expiration to 2025, ensuring continued integrity checks for package distribution.

All GitLab trails
  1. Consolidate your GitLab stack with Gitaly on KubernetesThis post announces the general availability of Gitaly on Kubernetes, a significant infrastructure evolution. It details the technical challenges of running Gitaly in Kubernetes, such as cgroup management with containerd and handling pod restarts. Solutions implemented include using an init container to mount and write to `/sys/fs/cgroup` and configuring client retries to mitigate downtime during upgrades. Benchmark results comparing VM-based and Kubernetes-based Gitaly are presented, highlighting near-identical success rates for common Git operations.
  2. Changes to packages.gitlab.com: What you need to knowThis post details a migration of the `packages.gitlab.com` infrastructure to a new package hosting system. Key changes include: updated DEB repository URLs for `gitlab/*` repos to include the distribution codename as a path segment, updated GPG key URL from `https://packages.gitlab.com/gpg.key` to `https://packages.gitlab.com/gpgkey/gpg.key`, redirection of package downloads from AWS CloudFront to Google Cloud Storage (requiring firewall/proxy allowlist updates for `https://storage.googleapis.com/packages-ops`), changes to direct package download URLs, and a move of GitLab Runner `noarch` RPM packages from the `noarch` architecture path to `x86_64`. The post emphasizes re-running installation scripts and updating configurations before September 30, 2026, when backwards compatibility will be removed.
  3. GPG key used to sign GitLab package repositories' metadata has been extendedThis post details the extension of the GPG key used to sign the metadata for GitLab's apt and yum repositories. The key's expiration date has been extended from February 27, 2026, to February 6, 2028. This is a proactive measure to maintain security policies and minimize disruption to users by avoiding a key rotation, which would require all users to update their trusted keys. Users who configured repositories before the extension date are advised to update their key according to documentation.
  4. GitLab extends Omnibus package signing key expiration to 2028This post details the extension of the Omnibus package signing key's expiration from February 14, 2026, to February 16, 2028. This is a security measure to comply with policies and limit exposure if the key is compromised. The extension is preferred over rotation to minimize disruption for users. Users who validate package signatures need to update their copy of the key. Instructions and links to the public key are provided.
  5. Guide: Migrate from Azure DevOps to GitLabThis post details the planning and execution phases for migrating from Azure DevOps to GitLab, focusing on repository migration (using Congregate or built-in import), pipeline migration (Azure Pipelines to GitLab CI/CD), and migration of other assets like work items, boards, artifacts, and container images. It highlights the importance of inventorying assets, understanding tool capabilities (Congregate vs. built-in import), planning organizational structure in GitLab, and managing authentication and permissions. The post also touches on the use of AI-based pipeline conversion and the differences in permissions models between the two platforms.
  7. Deploying the world's largest GitLab instance 12 times dailyThis post details the zero-downtime deployment pipeline for GitLab.com, which deploys up to 12 times daily using GitLab CI/CD, handling both containerized and VM workloads, and employing a canary strategy for progressive rollouts and validation. It addresses multi-version compatibility challenges during database migrations and code deployments, ensuring seamless updates for millions of users.
  8. GitLab rotating Omnibus Linux package signing keyThis post details the rotation of the GPG key used to sign Omnibus Linux packages. It explains the purpose of the signing key for package integrity, distinguishes it from repository metadata signing keys, and provides instructions for users who validate package signatures to update their key. It also specifies the new key fingerprint and provides a URL to download the new key.
  9. Streamline migrations with user contribution and membership mappingIntroduced 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.
  10. GitLab extends Omnibus package signing key expiration to 2025This post details the extension of the Omnibus package signing key expiration from July 1, 2024, to July 1, 2025. This is a security policy compliance measure to limit exposure should the key be compromised. The extension is preferred over rotation to minimize disruption for users who verify package integrity. Instructions are provided for users who validate package signatures, including how to update their copy of the public key or find it on GPG keyservers and packages.gitlab.com.
  11. Jenkins-to-GitLab migration made easyThis 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.
  12. Enhanced migration from Bitbucket Server and Bitbucket Cloud to GitLabIntroduced 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).
  13. GitLab extends Omnibus package signing key expiration to 2024The Omnibus package signing key's expiration has been extended from July 1, 2023, to July 1, 2024. This annual extension is a security policy to limit exposure if the key is compromised. The extension is preferred over rotation to minimize disruption for users who verify package integrity. Users who validate package signatures need to update their copy of the key. Instructions and URLs for obtaining the public key are provided.
  14. GitLab is now an Amazon Linux 2 Service Ready PartnerThis post announces GitLab's achievement of Amazon Linux 2 Service Ready Partner status, signifying comprehensive support, compatibility testing, and security testing for deploying GitLab on Amazon Linux 2. It details the rigorous process undertaken by the Distribution Team, including setting up distro-specific CI build and test environments, performing extensive compatibility and security scans, and preparing distro-specific packages and AMIs. It also highlights the availability of Amazon Linux 2 RPM packages for GitLab and GitLab Runner since version 15.0.
  15. Mobile DevOps: Code signing with project-level secure filesIntroduced Project-level Secure Files in GitLab 15.0, enabling secure storage of binary files (keystores, signing certificates, provisioning profiles) outside version control. Detailed the process of uploading these files and using the `glab CLI` within CI/CD jobs to download and utilize them for mobile code signing.
  16. Amazon Linux 2 support and distro-specific packages for GitLabThis 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.
  17. GitLab.com is moving to 15.0 with a few breaking changesThis 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.
  18. Installing GitLab on Raspberry Pi 64-bit OSThis post details a manual workaround for installing GitLab CE on Raspberry Pi OS (64-bit) when official ARM64 support is not yet available. It outlines the steps to manually add Debian Buster repositories to `apt` sources to enable installation, bypassing the standard script's limitations. This contributes to the broader effort of expanding GitLab's installation compatibility to new platforms.
  19. GitLab Chart works towards Kubernetes 1.22This 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.
  20. How to install and use the GitLab Kubernetes OperatorThis 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.
  21. GitLab's Kubernetes Operator for OpenShift now availableIntroduced 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.
  22. How to stand-up a GitLab instance in AWS MarketplaceThis 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.
  23. The GPG key used to sign GitLab Runner packages has been rotatedThis post details the rotation of the GPG key used to sign GitLab Runner packages due to a security incident where the key and other distribution tokens were not secured according to policy. While no evidence of unauthorized package modification was found, the GPG key and other tokens have been rotated out of an abundance of caution. Users who employ package signature verification are instructed to update their GPG keys. New users should download the new key. Shared runner users are unaffected.
  24. The next step in performance testing? The GitLab Environment ToolkitIntroduced 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.
  25. GitLab extends package signing key expiration to 2022This post details the extension of the GPG key expiration for signing GitLab 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 avoid the overhead of generating a new key annually. Users who validate package signatures need to update their copy of the key. Instructions and links to the public key and documentation are provided.
  26. The GPG key used to sign GitLab package repositories' metadata is changingThis post announces the rotation of the GPG key used to sign the metadata for GitLab omnibus and gitlab-runner package repositories. The existing key (fingerprint 1A4C 919D B987 D435 9396 38B9 1421 9A96 E15E 78F) expires on April 15, 2020. A new key (fingerprint F640 3F65 44A3 8863 DAA0 B6E0 3F01 618A 5131 2F3F) will be active for two years. The change will occur on April 6, 2020. Existing users who have configured these repositories will need to install the new public key to continue fetching packages. New users will automatically receive the new key through the installation scripts. Instructions for updating the key are provided in the official documentation.
  27. Contributing to GitLab after move to a single codebaseThis post details the technical implications of merging GitLab CE and EE into a single codebase for contributors. It clarifies that this change does not impact contributions to other GitLab projects (Charts, Design System, UI, Omnibus, Runner). It also states that licensing remains the same (CE under MIT, EE proprietary) and highlights the benefits of a single codebase for efficiency, reduced duplicate work, and simplified contribution workflows (single place for issues and MRs, elimination of `ee_compat_check` errors). It provides instructions for re-submitting MRs against the new GitLab project.
  28. Why GitLab uses one codebase for Community & EnterpriseThis 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.
  29. GitLab might move to a single Rails codebaseThis 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.
  30. Microsoft Exchange & Google Groups now supported by GitLabThis 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.
  31. Getting Started with GitLab Development KitThis post details the setup of the GitLab Development Kit (GDK) for developers contributing to GitLab. It outlines the installation of prerequisites, cloning the GDK repository, forking GitLab repositories for contributions, and running the GDK to start a local development environment. It also covers making changes, refreshing the browser, restarting GDK, and running tests (spinach, rspec). Finally, it explains the process of opening a merge request.
  32. Customer Story: ChargeThis post details how Charge, a telecommunications company, migrated from raw git with git+ssh to GitLab Community Edition to improve their engineering workflow, speed up development, and meet industry security requirements. They host 25 internal git repositories on GitLab CE, using a Postgres database with daily backups, Google OAuth integration, webhooks, and git hooks for their build server. The migration resulted in decreased deployment times from an hour to a couple of minutes and increased confidence in deployments.
  33. Getting started with GitLab and DigitalOceanThis 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.
  34. Using the Omnibus GitLab package to ship GitLabThis post details the rationale and technical considerations behind using the omnibus-gitlab package for shipping GitLab. It explains the 'fat binary' concept of Omnibus, contrasting it with traditional Unix design principles and the challenges of installing GitLab from source. The benefits for both users (ease of installation, configuration, and upgrades) and maintainers (consistent environments, simplified support, simultaneous platform packaging) are highlighted. Alternatives considered, such as Docker images and native Debian/Fedora packages, are discussed, along with their limitations in the context of GitLab's monthly release cycle and packaging expertise. The post concludes that omnibus-gitlab is the best current option for frequent, simplified GitLab updates, while acknowledging ongoing efforts to explore other installation methods like native Debian packages.
  35. GitLab: In case you missed itThis post introduces the author's new role as a Developer Advocate at GitLab and provides an overview of GitLab's features for those who haven't followed its development. It highlights GitLab.com as a free, unrestricted hosting option, explains GitLab's terminology (e.g., 'projects' instead of 'repositories', 'merge requests' instead of 'pull requests'), introduces CI/CD as an embedded feature, explains the role of 'runners' for executing CI jobs, and details the ease of installation and updates using 'Omnibus'. It also mentions smaller features like 'Merge when build succeeds' and 'GitLab Pages' for static website hosting. The post concludes by pointing to the GitLab Direction page for future vision and announces upcoming webcasts and meetups.
  36. Did you install GitLab from source? Check your Git versionThis 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.
  37. How GitLab uses Unicorn and unicorn-worker-killerThis 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.
  38. GitLab.com outage on 2015-05-29This 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.
  39. Version Check FunctionalityThis 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.
  40. GitLab on Debian 8GitLab Omnibus packages for Debian 8 are now available with every release, enabling early adopters to run GitLab on the new Debian version. Installation instructions are provided using `curl` and `apt-get`.
  41. GitLab AMIIntroduced 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.
  42. Moving all your data, 9TB editionThis 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.
  43. Why move to a single code collaboration tool?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.
  44. GitHub Enterprise vs GitLab Enterprise EditionThis 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.
  45. The hardware that powers 100,000 git repositoriesThis 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.
  46. GitLab got bit: MySQL fails at Rails migrations that work in PostgreSQLThis 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.
  47. How you can send your logs ballistically using UDPThis 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.
  48. GitLab Omnibus packages now include GitLab CIThis 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.
  49. GitLab is now simple to installIntroduced three new installation options: an official GitLab Chef cookbook (supporting Ubuntu/RHEL, MySQL/PostgreSQL, Chef Solo/Server/Vagrant, and AWS Opsworks), GitLab Packer virtual machines (Ubuntu 12.04 image available, CentOS 6.5 coming soon, with Digital Ocean and AWS examples), and GitLab Omnibus packages (deb for Ubuntu 12.04, RPM for CentOS 6). The Omnibus packages are for pre-production use initially, with plans to update them for stable releases and expanded feature support. The Omnibus packages leverage omnibus-ruby for packaging.