TechPrufer
Get started
GitLab
GitLab logoGitLab · Feature trail

On-Premises Deployment Considerations

45 posts · Jan 2015 – Sep 2026

What this trail covers

GitLab 19.0 introduces significant changes to its deployment and dependency management for self-managed instances. Key updates include the replacement of NGINX Ingress with Gateway API and Envoy Gateway as the default networking component, and the removal of bundled PostgreSQL, Redis, and MinIO from the Helm chart. Support for PostgreSQL 16 is dropped in favor of PostgreSQL 17 as the minimum requirement. Additionally, support for Ubuntu 20.04 and Redis 6 is discontinued. The `heroku/builder:24` image replaces `heroku/builder:22` in Auto DevOps, and bundled Mattermost is removed from the Linux package. Support for SUSE distributions is also discontinued. These changes necessitate proactive migration and configuration updates for self-managed deployments to ensure compatibility and continued support.

All GitLab trails
  1. GitLab Dedicated: Compliance for a new regulatory eraThis post details how GitLab Dedicated addresses regulatory compliance (DORA, NIS2, GDPR) by providing a fully isolated, single-tenant SaaS solution. It highlights features like disaster recovery with specific RTO/RPO targets, data sovereignty through region selection and BYOK, and streamlined audit evidence via automated workflows and the Trust Center. It also discusses the limitations of multi-tenant platforms and self-managed solutions in meeting these evolving compliance needs.
  2. Scale software delivery without owning the runner fleetIntroduces 'Hosted Runners for GitLab Dedicated' as a managed CI execution SaaS offering within GitLab Dedicated. This feature eliminates the need for customers to manage their own runner fleet, providing isolated, short-lived VMs for each job, network security via AWS PrivateLink, autoscaling for bursty CI demands, and a 99.9% uptime SLA. It also introduces consumption pricing via GitLab Credits and usage visibility on a dedicated dashboard.
  3. GitLab on Google Cloud: Fully managed, compliant, and AI-readyThis post announces the availability of GitLab as a fully managed platform on Google Cloud, delivered by MSPs. It highlights the integration with Google's latest AI models (Gemini and Gemma) via the GitLab Duo Agent Platform, allowing users to leverage these models within a governed platform. It also details how customers can use their existing Google Cloud commitments to purchase GitLab and Duo Agent Platform through Google Cloud Marketplace, consolidating billing and providing cost controls. The post emphasizes the benefits of running GitLab on Google Cloud for sovereignty, data residency, and AI model access without fragmentation.
  4. A guide to the breaking changes in GitLab 19.0This post details breaking changes in GitLab 19.0 impacting self-managed deployments. It announces the transition from NGINX Ingress to Gateway API with Envoy Gateway as the default networking component, and the removal of bundled PostgreSQL, Redis, and MinIO from the Helm chart. It also mandates PostgreSQL 17 as the minimum version, dropping support for PostgreSQL 16. Support for Ubuntu 20.04 and Redis 6 is discontinued, and the `heroku/builder:24` image replaces `heroku/builder:22` in Auto DevOps. Bundled Mattermost and support for SUSE distributions are removed from the Linux package. Mitigation steps and migration guides are provided for each change.
  5. Why financial services choose single-tenant SaaSThis post details the rationale behind financial institutions choosing single-tenant SaaS solutions like GitLab Dedicated. It highlights the systemic risk and concentration risk associated with shared infrastructure in the financial sector, citing regulatory concerns and data sovereignty challenges. It emphasizes GitLab Dedicated's purpose-built, isolated environment for source code, repositories, and CI/CD pipelines, including secure hosted runners and auto-scaling architecture. The post also details control mechanisms such as BYOK encryption and data residency choices, along with audit trails and logging for compliance with regulations like SOX and GLBA. Operational excellence is achieved through high availability, disaster recovery, and a zero-maintenance approach to CI/CD infrastructure.
  7. Hosted runners for GitLab Dedicated: Now in limited availabilityIntroduces hosted runners for GitLab Dedicated, a fully managed CI/CD infrastructure solution. Highlights reduced operational overhead, automatic scaling, cost optimization, and enterprise-grade security with tenant isolation. Announces native Arm64 support in addition to x86-64 runners, detailing benefits for performance, cost, and multi-architecture development. Lists available runner sizes (Small, Medium, Large, X-Large, 2X-Large) with vCPU, Memory, and Storage configurations. Outlines future plans including general availability in May 2025 with compute minute visualization, network controls, macOS runners, and Windows runners.
  8. How we designed the GitLab Reference ArchitecturesThis post details the design process and ongoing evolution of GitLab Reference Architectures. It outlines the problem of customer deployment hurdles, the goals of performance, availability, scalability, cost-effectiveness, and maintainability, and the iterative process of gathering metrics (RPS), prototyping, and performance testing. It highlights the development of the GitLab Performance Tool and GitLab Environment Toolkit, and the continuous updates to the architectures, including cloud-native variants and cloud provider guidance.
  9. Introducing GitLab Dedicated for GovernmentThis post announces the launch of GitLab Dedicated for Government, a FedRAMP-compliant, single-tenant SaaS offering designed for public sector and highly regulated industries. It highlights the benefits of toolchain consolidation, data residency and protection (including private networking), and being managed and hosted by GitLab. The offering aligns with Secure by Design principles and aims to meet stringent compliance needs.
  10. Atlassian Server ends: Time to move to integrated DevSecOpsThis post details the end-of-life for Atlassian Server products (Bitbucket Server, Bamboo Server, Jira Server) and positions GitLab as an integrated DevSecOps platform alternative. It highlights GitLab's importer tools for migrating from Atlassian products (repositories, Jira issues, Bamboo jobs) and emphasizes the benefits of a unified platform, including reduced complexity, improved developer experience, and enhanced visibility. The post also references GitLab's AI capabilities and its value proposition as a comprehensive DevSecOps solution.
  11. Building GitLab with GitLab: How GitLab.com inspired DedicatedThis post details the technical decisions and implementation strategies for GitLab Dedicated, a single-tenant SaaS offering. It contrasts Dedicated with GitLab.com's multi-tenant architecture, highlighting differences in automation, database choices (AWS managed services vs. self-managed Postgres/Redis), and monitoring (customer-specific vs. shared). It elaborates on the automated deployment process for Dedicated using the GitLab Environment Toolkit (GET), Terraform, and AWS IAM for granular access control, orchestrated by the new Switchboard portal. It also discusses the architectural choice of leveraging AWS managed services for databases and the implications of single-tenancy on monitoring and issue escalation. High availability for all components is a default for smaller Dedicated instances. Unique features like BYOK and PrivateLink networking are also described.
  12. Contributor how-to: Remote Development workspaces and GitLab Developer KitThis post details the technical implementation of running the GitLab Development Kit (GDK) within GitLab's Remote Development workspaces. It explains the behind-the-scenes process of workspace creation, including the role of init containers and the GitLab agent for Kubernetes. It addresses the memory limitations encountered during large repository clones (like the main GitLab project) and proposes using the GDK repository itself as the base for the workspace to mitigate this. The post also describes the creation of a pre-built container image for GDK to speed up installation and the development of a script to generate the `gdk.yml` file dynamically based on the workspace's environment variables. The `.devfile.yaml` configuration is provided, outlining the necessary ports and resource requests for the workspace container.
  13. Cloud infrastructure for on-demand development in GitLabThis post details the technical steps and infrastructure requirements for setting up on-demand, cloud-based development environments using GitLab. It covers the integration of the GitLab agent for Kubernetes, OAuth applications, and TLS certificates. The post provides specific instructions for configuring Kubernetes clusters across various cloud providers (GKE, EKS, AKS, Civo) and self-managed Kubernetes, including the installation of Ingress controllers and workspaces proxy. It also outlines the creation of custom workspace container images and the use of devfile specifications for environment configuration. The technical depth includes setting up DNS records, managing TLS certificates with Let's Encrypt, and configuring OAuth callbacks.
  14. GitLab Dedicated single-tenant SaaS now generally availableThis post announces the general availability of GitLab Dedicated, a single-tenant SaaS offering. It details the compliance features (data residency, isolation, private networking, encryption), security controls (SAML, IP allow lists, private connectivity), and scalability (up to 50,000 users) of the managed platform. It also outlines future plans for integrating AI features while adhering to compliance requirements.
  15. A first look at workspaces: On-demand, cloud-based development environmentsIntroduced Workspaces, a new feature for on-demand, cloud-based development environments. Workspaces are ephemeral, personal development environments in the cloud, defined by code in a `.devfile.yaml` file. They require a cloud platform or self-hosted Kubernetes cluster with the GitLab Agent for Kubernetes installed. Initially, they support the Web IDE and allow for manual authentication to clone private repositories. Future plans include SSH access from desktop IDEs, support for other editors, and usage limits.
  16. GitLab Operator certified by Red Hat OpenShiftThis post announces the certification of the GitLab Operator by Red Hat, enabling GitLab to be installed within OpenShift clusters. It details the benefits of the Operator framework for streamlined installation and upgrades, and mentions future plans for backup, recovery, and auto-scaling. The Red Hat certification process involved aligning with UBI and meeting Red Hat's policy requirements, signifying joint support.
  17. Introducing GitLab Dedicated, our new single-tenant SaaS offeringIntroduces GitLab Dedicated, a new single-tenant SaaS offering that provides enhanced data residency, isolation, and private networking capabilities for enterprise customers with stringent compliance requirements. This offering allows organizations to use GitLab's DevSecOps platform in a fully isolated instance managed by GitLab, deployed in their chosen cloud region, and connected via private networking.
  18. Oracle and GitLab partner for cloud-native app developmentThis post details the partnership between GitLab and Oracle to enable GitLab's DevOps platform to run on Oracle Cloud Infrastructure (OCI). It highlights the benefits of this pairing, including performance enhancements through OCI's latest-generation processors and GPU support for AI/ML workloads, platform breadth with OKE integration and GitOps workflows, enhanced security features of OCI, and value through end-to-end SLAs. The post also discusses support for hybrid and multi-cloud environments, including Oracle's partnership with VMware and GitLab's ability to deploy on vSphere. Finally, it mentions OCI's GovCloud regions and GitLab's pursuit of FedRAMP certification. The post also provides guidance on getting started with GitLab on OCI using Oracle Linux packages, Helm charts, or the GitLab Operator.
  19. How to access GitLab on a private network with TailscaleThis post details the technical steps to integrate a self-hosted GitLab instance on a private network with Tailscale. It covers installing Tailscale, configuring DNS to point a hostname to the private IP address, and setting up HTTPS encryption using Certbot and Let's Encrypt certificates. The post explains the drawbacks of traditional port forwarding and highlights the security and ease-of-use benefits of Tailscale for remote access to private network services.
  20. GitOps with GitLab: Infrastructure provisioning with GitLab and TerraformThis post details the practical implementation of GitOps using GitLab and Terraform for infrastructure provisioning. It covers creating a network and setting up a Kubernetes cluster using Civo, with a focus on infrastructure as code (IaC) principles. The post explains how to configure Terraform to use the GitLab managed Terraform state backend, both for local execution (using direnv and environment variables) and within a GitLab CI/CD pipeline. It also outlines the structure of Terraform projects, separating concerns like network and cluster setup, and discusses best practices for managing Terraform state and configurations.
  21. Ready-To-Run GitLab for 50,000 users with AWS Quick StartThis post introduces the AWS Quick Start for cloud-native hybrid deployments on EKS, building upon GitLab's Reference Architectures and the GitLab Environment Toolkit (GET). It provides a 'bill of materials' for provisioning GitLab on EKS, including tested instance types and counts for EKS nodes, RDS PostgreSQL, Redis Elasticache, and Gitaly Cluster. It also includes GPT testing results and 'Deploy Now' links for simplified provisioning, aiming to enable 'Ready-to-Run' GitLab for up to 50,000 users in a few hours.
  22. How to stand-up a GitLab instance in AWS MarketplaceThis post details the steps to deploy a self-managed GitLab instance in AWS Marketplace, including subscribing to the GitLab Ultimate offering, configuring the EC2 instance and security group, and launching the instance. It also covers the installation of GitLab Runner and Docker Engine on the same instance for CI/CD job execution, and the registration of the runner with the GitLab instance. This contributes to the broader capability of providing flexible deployment options for GitLab.
  23. The next step in performance testing? The GitLab Environment ToolkitThis post introduces the GitLab Environment Toolkit (GET), a new toolkit designed to automate the deployment of GitLab at scale using Terraform and Ansible. GET supports deploying various GitLab Reference Architectures and Cloud Native Hybrid Reference Architectures across GCP, AWS, and Azure, including features like upgrades, Geo support, and zero downtime upgrades. It is built on the principle of 'boring solutions' and complements GitLab Omnibus and Helm Charts by focusing on environment provisioning.
  24. What we learned after a year of GitLab.com on KubernetesThis post details GitLab's year-long effort to migrate GitLab.com services to Kubernetes. It outlines the challenges faced, including increased billing from cross-AZ traffic, managing resource limits and requests for scaling, improving metrics and logging for observability during the transition, and strategies for shifting traffic to the new cluster using a canary stage. The post also discusses the use of Terraform and Helm for managing Kubernetes configuration within GitLab itself, and the lessons learned regarding the importance of detailed log queries, rollback procedures, and combining metrics from legacy VM and Kubernetes environments.
  25. Why AppsFlyer moved from Bitbucket to GitLabThis post details AppsFlyer's migration from Bitbucket to GitLab, including their transition from Mercurial to Git. It highlights the technical challenges and solutions involved in migrating a large number of repositories, such as developing a self-service Fast-Export wrapper and using Slack for synchronization. The post also touches upon the benefits of an open-source, self-managed solution, including the ability to build custom tools and improve workflows, and the transparency offered by GitLab's public issue tracker.
  26. Shifting from on-prem to cloudThis post discusses the reasons organizations choose to maintain on-premises infrastructure, including regulatory compliance, protecting sensitive data, and cost considerations at scale. It also outlines the challenges of on-premises infrastructure such as the required range of expertise, managing software and hardware, and undifferentiated engineering. Strategies for shifting to the cloud, including 'lift-and-shift' and hybrid cloud models, are presented. The discussion highlights that while cloud offers elasticity and reduced operational overhead, on-premises remains a viable option for specific needs, and hybrid models offer a balance.
  27. From idea to production on thousands of cloudsThis post introduces Gravitational's Gravity, a Kubernetes packaging solution that allows developers to build "cluster images" (similar to VM images) that can contain an entire Kubernetes cluster pre-loaded with multiple applications. It explains how GitLab CI/CD can be used for continuous delivery of applications to a single Kubernetes cluster, and how Gravity can then be used to expand that production environment to multiple cloud providers, on-premises data centers, or even air-gapped environments. The post highlights the use of GitLab's Kubernetes integration for single-destination deployments and Gravity for multi-destination deployments, emphasizing consistency and compliance across diverse environments.
  28. GitLab’s journey from Azure to GCPThis post details GitLab's migration from Azure to Google Cloud Platform (GCP). The migration was guided by the core values of efficiency, iteration, and transparency. The initial plan to stop the whole site and copy data was deemed too time-consuming. The team leveraged the developing GitLab Geo feature for replication to a secondary instance in GCP. The plan evolved to use Omnibus for provisioning and migrating file artifacts to Google Cloud Storage (GCS). The failover procedure was meticulously planned and iterated upon using issue templates and merge requests, resulting in over 140 changes to the checklist. The migration resulted in significant improvements in availability (from 99.61% to 99.93%) and reduced error rates and latency. Key learnings include the value of transparency, iterative development, and understanding DevOps lifecycle management from companies like Google.
  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 to address inefficiencies and duplicated work caused by maintaining two separate repositories. The proposal outlines the technical changes, including moving proprietary backend code to an `/ee` directory and keeping frontend assets open-sourced. It also details the historical attempts to manage the two-repository structure and the potential downsides of the proposed change.
  30. What's up with GitLab.com? Check out the latest data on its stabilityThis post details the migration of GitLab.com from Azure to Google Cloud Platform (GCP), highlighting significant improvements in availability and performance. It presents data on reduced downtime, improved mean-time between outage events, and latency histograms showing better request completion times. The post attributes these improvements to a more powerful Gitaly fleet on GCP with enhanced IO performance (SSD vs. magnetic disks, higher IOPS and bandwidth) and a reduction in 'unicorn worker saturation' errors due to better abuse detection, aggressive timeouts, and circuit breakers. It also mentions the ongoing work towards achieving 99.95% availability.
  31. Update on our planned move from Azure to Google Cloud PlatformThis post announces and details the planned migration of GitLab.com from Azure to Google Cloud Platform (GCP). It outlines the technical rationale for choosing GCP (Kubernetes support, long-term plans), expected user benefits (encrypted data at rest, faster caching), and the schedule of maintenance windows for the migration. It also provides specific instructions for users with custom domains on GitLab Pages regarding DNS changes. The post details the various testing phases and dry runs leading up to the actual migration.
  32. Install GitLab with a single click from the new GCP MarketplaceThis post announces the availability of GitLab on the GCP Marketplace for single-click installation on GKE. It also details GitLab's ongoing migration from Azure to GCP, with the goal of running GitLab.com on Kubernetes, and highlights GitLab's Kubernetes integration and Auto DevOps for deploying user applications to Kubernetes.
  33. We’re moving from Azure to Google Cloud PlatformThis post details GitLab's migration from Azure to Google Cloud Platform (GCP). It highlights the strategic decision to leverage GCP for its Kubernetes support (GKE) and its role in improving GitLab.com's performance and reliability. The post outlines the preparation steps, including the use of GitLab Geo for data replication (200TB Git data, 2TB PostgreSQL) and the migration of file artifacts (200TB) to Google Cloud Storage (GCS). It also describes the rehearsal process for the failover procedure, which involves preflight checklists, the failover procedure itself, a test plan, and a failback procedure, all managed via issue templates. The migration is scheduled for July 28, 2018, with a primary focus on data integrity.
  34. Why we are not leaving the cloudThis post details GitLab's decision to remain in the cloud for GitLab.com, reversing an earlier consideration to move to bare metal. It summarizes community feedback received on cost, performance, storage, and network proposals related to the bare metal migration. Key themes from the feedback include the significant operational overhead and expertise required for managing bare metal infrastructure, the importance of application architecture over deployment environment, potential performance trade-offs with certain hardware choices (e.g., 8TB drives, CephFS), and the complexities of networking and storage management in self-hosted environments. The post emphasizes that the decision was based on a comprehensive evaluation of these factors and a commitment to making GitLab.com fast and stable in the cloud.
  35. CodePen, welcome to GitLab!This post details CodePen's migration to a self-managed GitLab instance, highlighting the benefits of control over deployments, enhanced security through self-hosting, and the integration of CI/CD. It also covers the adoption of GitLab Issue Boards and Time Tracking for project management, replacing external tools. The post emphasizes the value of a unified platform for code, CI/CD, and project management, and warns about potential pitfalls during project migration.
  36. Customer story: A creative agency's GitLab wishlistThis post details a customer's experience with self-hosting GitLab for on-premises deployment due to security requirements. It discusses the use of Docker for hosting GitLab and Mattermost, and the team's desire for versioning tools for design files (Photoshop, InDesign). The post also contrasts GitLab's 'from idea to production' end-to-end DevOps platform strategy with GitHub's focus on core Git functionality and third-party integrations.
  37. Proposed server purchase for GitLab.comThis post details GitLab's proposal for purchasing servers to host GitLab.com, moving away from the cloud to bare metal for performance and cost reasons. It outlines the thinking behind chassis selection (SuperMicro 2U Twin2), server counts for various roles (storage, application, database, etc.), CPU choices (Intel Xeon E5-2600v4 series), disk strategy (8TB Seagate HDDs with SSD caching via Bcache), and memory requirements (128GB ECC per node for general use, 1TB for database servers). It also discusses network considerations (10Gbps RJ45) and power/hosting plans. Key questions are posed regarding chassis alternatives, Dell equivalents, disk configurations (JBOD, Bcache), SSD fitment, drive reliability, boot methods (PXE vs. local), SSD series choice, and SSD/Ceph journal co-location.
  38. Customer Story: Why Vaadin chose GitLabThis post details Vaadin's migration from a disparate toolchain (Gitolite, Trac, etc.) to a single GitLab instance for centralized project management, reduced administrative overhead, and improved developer experience. It highlights the ease of installation and migration using Omnibus, the self-service nature of setup, and the simplified maintenance with a single server and configuration file. The post also touches on the importance of developer choice and how GitLab's integrated tooling (issue trackers, code review, cross-linking) improved workflow, collaboration, and communication.
  39. How we knew it was time to leave the cloudThis post details GitLab's decision to move from cloud-hosted CephFS to bare-metal infrastructure due to performance limitations and cost inefficiencies experienced with shared cloud resources. It highlights the challenges of achieving consistent high IOPS on the cloud, the concept of 'noisy neighbors', and the trade-offs between cloud scalability and bare-metal control. The post also emphasizes the importance of observability and detailed monitoring, using Prometheus and custom dashboards to diagnose issues like OSD Journal Latency spikes, which directly impacted system availability.
  40. Announcing GitLab + Mesosphere: 5 reasons to get excitedThis post announces the integration of GitLab with Mesosphere's DC/OS, enabling one-click installation of GitLab within a DC/OS environment. It highlights five key benefits: simplifying complex infrastructure, enabling rapid GitLab instance deployment (minutes vs. hours/days), improving resource utilization through shared computing resources, ensuring high uptime via DC/OS fault tolerance, and providing analytics and reporting through DC/OS dashboards. It also links to a tutorial, solution brief, and webcast for further details.
  41. Get started with OpenShift Origin 3 and GitLabThis post details the technical steps and considerations for deploying GitLab on OpenShift Origin 3. It covers setting up the OpenShift environment using Vagrant, exploring the OpenShift web console and CLI, and troubleshooting common VM issues. The core contribution is the step-by-step guide to deploying GitLab using its official Docker image and an OpenShift template, including creating a new project, importing the template, and configuring the application with separate PostgreSQL and Redis instances.
  42. An inside look at the infrastructure of GitLab.comThis post provides a detailed breakdown of the infrastructure used for GitLab.com in April 2016, including the number of HAProxy load balancers, application stack servers (Nginx, Workhorse, Unicorn + Rails, Redis + Sidekiq), NFS servers, Redis, PostgreSQL, and Elasticsearch servers. It also details the use of Azure Availability Sets for HA and the infrastructure for managing Shared Runners, including autoscaled Docker machines. The post concludes with a total server count for GitLab.com.
  43. Getting started with GitLab and DigitalOceanThis post details how to deploy GitLab Community Edition on a DigitalOcean droplet using a one-click install image. It covers setting up the droplet, configuring domain names and emails (including SSL/TLS), logging in with default credentials, modifying account information, and updating to newer releases. It also provides guidance on creating backups and links to related tutorials for setting up GitLab Runner and adding swap space.
  44. Customer Story: Stack OverflowThis post details how Stack Overflow uses GitLab for source control on-premises. It highlights their adoption of GitLab over Git-web and Kiln due to performance improvements. Key technical details include their use of self-managed GitLab, LDAP integration, and their ongoing analysis of GitLab Geo for multi-datacenter replication. They also mention using Team City for CI instead of GitLab's integrated CI.
  45. Big changes coming to GitHostThis post announces significant changes to GitHost's plans, pricing, and features. New, higher-capacity plans (Business, Business Pro, Corporate) are introduced, and smaller plans are consolidated. Existing subscribers are grandfathered for two years. GitLab Enterprise Edition is now available on GitHost, requiring a license. Configuration of Omniauth providers and LDAP has been simplified through a UI, eliminating the need to edit `gitlab.rb` directly, though a reconfigure is still necessary. The GitHost.io UI has also been redesigned.
  46. Pivotal Cloud Foundry Tile for GitLab EEIntroduces a new tile for Pivotal Cloud Foundry (PCF) that allows for the deployment of GitLab Enterprise Edition (EE) as a pre-configured appliance. The tile simplifies installation via Ops Manager (BOSH), enables high availability by default, and allows for easy scaling by adjusting a single value. Configuration of GitLab and its components, such as Redis, is managed within the PCF environment.
  47. GitLab Mattermost, an open source on-premises Slack alternativeThis post announces the integration of GitLab Mattermost, an open-source, on-premises messaging app, into GitLab Omnibus packages starting with version 7.14. This collaboration with the Mattermost team addresses the need for an on-premises Slack alternative, leveraging GitLab's Omnibus for easy installation and its OAuth provider for seamless integration. It also highlights the deprecation of the older 'wall' feature and the ongoing efforts to improve Mattermost's security and stability.
  48. GitLab AMIThis post announces the availability of GitLab CE AMIs for AWS, simplifying deployment on AWS. It highlights that these AMIs contain the same Omnibus package used to run GitLab.com, making upgrades and maintenance easy. It also links to a post about migrating GitLab.com to AWS.
  49. Why deploy on-premises in the SaaS era?This post argues for the continued relevance and advantages of on-premises deployments in the SaaS era. It highlights key benefits such as containment of intellectual property, easier integration with enterprise systems like LDAP/AD, greater control over infrastructure and maintenance windows, improved performance due to reduced latency for local developers, and increased choice and flexibility in deployment options. It also touches on the potential cost and complexity of retrieving data from cloud vendors.
  50. GitHub Enterprise vs GitLab Enterprise EditionThis post highlights GitLab Enterprise Edition's advantages for enterprise needs, focusing on features like protected branches, UI-based rebasing, LDAP group synchronization, and internally visible projects. It also details operational and scaling benefits, such as storing repositories on separate file servers (NFS/NAS), stateless application servers for easier scaling and high availability, and performance claims of one server handling 25,000 active users. The post also touches on the open-source nature enabling affordable licensing and broader collaboration across functional groups.