GitLab

GitLab is an open-core DevOps platform that manages the full software development lifecycle in one application — from code hosting and review to automated pipelines, container registry, and deployment. Used by more than 100,000 organizations, it is the most widely deployed self-hosted alternative to GitHub, giving teams complete control over their code and infrastructure.

The Community Edition (CE) ships under the MIT license and covers the bulk of what most teams need: Git repositories with fine-grained access control, merge requests, a built-in CI/CD engine configured via a .gitlab-ci.yml file, an issue tracker with Kanban boards, wikis, and package/container registries. The Enterprise Edition (EE) adds advanced governance, compliance, and security features on top of the same codebase.

GitLab is built on Ruby on Rails and integrates tightly with PostgreSQL, Redis, Gitaly (its custom Git RPC server), GitLab Shell, and GitLab Workhorse. Deployment is handled via Omnibus packages that bundle all dependencies into a single RPM or DEB, making production setup far simpler than a manual installation. Kubernetes-based deployments via the official Helm chart are also supported for organizations running cloud-native infrastructure.

Because the CE code is open source and the entire application runs on-premises, teams subject to strict data-sovereignty or air-gap requirements — defense, finance, healthcare — can operate GitLab with zero external dependencies, keeping every commit, pipeline log, and secret inside their own network.

What You Get

• Git Repository Management - Host unlimited repositories with branch protection rules, push rules, signed commits, and role-based access control spanning users, groups, and projects.
• Native CI/CD Pipelines - Define pipelines in a .gitlab-ci.yml file with stages, parallel jobs, artifacts, caching, and dynamic child pipelines — executed by distributed GitLab Runners on any infrastructure.
• Merge Requests with Code Review - Review code through inline comments, multi-round review threads, diff comparisons, approval rules, and automated status checks from CI before any merge is allowed.
• Issue Tracker and Kanban Boards - Track work with issues, milestones, labels, epics, and customizable Kanban boards linked directly to commits, merge requests, and releases.
• Container and Package Registries - Host Docker images, npm, Maven, PyPI, Helm, and generic package artifacts in a built-in registry alongside the source code that produces them.
• Built-in Security Scanning - Run SAST, DAST, dependency scanning, container scanning, and secret detection as first-class CI pipeline jobs with results surfaced in merge requests.
• Project Wikis and Documentation - Write and version project documentation in Markdown wikis stored in a dedicated Git repository, accessible alongside the codebase.
• Omnibus and Kubernetes Deployment - Install everything with a single RPM/DEB package that bundles PostgreSQL, Redis, NGINX, and Gitaly, or use the official Helm chart for cloud-native setups.

Common Use Cases

• Air-gapped government or defense deployment - A government contractor installs GitLab CE on-premises with no outbound internet access, hosting classified source code and running CI pipelines entirely within a private network.
• Replacing GitHub in regulated industries - A European bank self-hosts GitLab to satisfy GDPR data-residency requirements, using SSO via SAML and audit logs to demonstrate compliance to auditors.
• Kubernetes microservice delivery pipelines - A cloud-native startup uses GitLab CI/CD with Auto DevOps to automatically build, scan, and deploy a fleet of microservices to GKE on every merge, with environment-specific promotion gates.
• Open source project management - A community project uses GitLab.com’s free tier to manage contributions via merge requests, triage bugs with issue boards, and publish release artifacts to the package registry.
• Internal tooling for platform teams - A platform engineering team uses GitLab to maintain Terraform modules and Ansible playbooks, triggering infrastructure pipelines on merge while enforcing mandatory code-owner approvals.
• Security-first software supply chain - A fintech company uses GitLab’s built-in SAST, dependency scanning, and container scanning to enforce a zero-critical-vulnerability policy at merge time before any code ships to production.

Under The Hood

Architecture GitLab is structured as a layered monolith with clear domain boundaries rather than a distributed microservices system. The Rails application is divided into controllers, service objects, finders, policies, and serializers — each with a narrowly defined responsibility. Authorization is handled by a declarative policy system (DeclarativePolicy gem) where conditions are evaluated with memoized scoring, making access control logic composable and testable in isolation. The GraphQL layer sits alongside the REST API and enforces complexity limits, timeout budgets, and pagination contracts at the schema level, reducing the risk of runaway queries. Gitaly — a separate Go-based gRPC service — owns all Git operations, ensuring the Rails process never touches the filesystem directly for repository data.

Tech Stack The backend runs on Ruby on Rails 7.2 (with a Gemfile.next tracking Rails 8.0) backed by PostgreSQL accessed through ActiveRecord and a large custom migration system. Redis handles caching, Sidekiq job queuing, and ActionCable WebSocket sessions. The frontend is Vue.js with a migration from Vue 2 to Vue 3 in progress, using Apollo Client for GraphQL queries and a custom component library (GitLab UI / Pajamas design system). Go is used for Workhorse (the reverse-proxy/large-file handler) and Gitaly. The CI runner is a separate Go binary. Jest and RSpec are the primary test frameworks for frontend and backend respectively.

Code Quality The codebase demonstrates comprehensive testing discipline with RSpec specs mirroring the full app structure — models, services, controllers, policies, GraphQL types, and API endpoints all have corresponding spec directories. Every Ruby file carries # frozen_string_literal: true as a default, and the project enforces RuboCop, ESLint, Haml-lint, and SCSS-lint in CI. Service objects follow a consistent #execute convention with typed return values. The policies layer uses condition caching and scope declarations to prevent N+1 authorization checks. Error handling in services uses structured result objects rather than rescue-heavy controllers, making failure paths explicit and testable.

What Makes It Unique GitLab’s most technically distinctive aspect is the depth of its CI/CD engine relative to the rest of the platform. Pipelines can generate child pipelines dynamically from artifacts, allowing matrix builds that scale to thousands of jobs without static YAML configuration. The Workhorse integration intercepts large file uploads (LFS objects, artifacts, registry pushes) at the reverse-proxy layer before they reach Rails, preventing application-server blocking — an architectural pattern rare in web frameworks of this size. The declarative policy system means authorization rules are unit-testable as plain Ruby, not embedded in controller callbacks, which makes security auditing tractable across a codebase with hundreds of resource types.

Self-Hosting

GitLab’s Community Edition is licensed under the MIT Expat license for the core codebase, with documentation under Creative Commons CC BY-SA 4.0. This means you can run CE commercially, modify it, and distribute it without royalty obligations. The Enterprise Edition code lives in the ee/ directory under a source-available but proprietary license — you can read and contribute to it, but running EE features requires a paid subscription from GitLab Inc. The practical implication for self-hosters is that the MIT-licensed CE is genuinely free to use in production at any scale, while EE features (advanced security dashboards, compliance frameworks, merge trains, SAML group sync) require purchasing a license.

Operating GitLab yourself is a meaningful infrastructure commitment. The Omnibus package simplifies initial installation considerably, but a production-grade deployment requires dedicated PostgreSQL (16.5+ recommended), Redis, object storage for artifacts and LFS, and enough RAM to keep Sidekiq workers and Puma processes responsive — GitLab recommends a minimum of 8 GB RAM for a small team and substantially more for hundreds of active users. You are responsible for regular database vacuuming and index maintenance, managing PostgreSQL upgrades during GitLab version bumps, configuring backups (rake gitlab:backup:create) and verifying restore procedures, and keeping all bundled components (Gitaly, Workhorse, Runner) at compatible versions. The upgrade path is well-documented but must follow a specific sequence of intermediate versions for major upgrades.

Compared to GitLab.com (the hosted SaaS offering), self-hosting means you own the hardware cost and operational burden but gain complete data sovereignty and no per-user pricing above the CE tier. GitLab.com provides automatic version updates, geo-distributed storage, managed Runners with shared compute, and enterprise SLAs — none of which come with a CE self-hosted install. If your organization needs high availability, GitLab EE supports multi-node Patroni clusters and Gitaly Cluster, but configuring and operating those adds further complexity that GitLab.com handles transparently.