How to self-host GitLab

GitLab gives teams a complete platform for source code management, CI/CD, project management, and DevSecOps. GitLab's managed platform is the simplest way to get started, but some teams need more control over where GitLab runs, how their data is stored, and how it connects to their existing infrastructure.

Self-hosting GitLab gives you that control, but it also means taking responsibility for the infrastructure behind it. This guide explains why you might self-host GitLab, what you need to run it, and how to deploy a GitLab Community Edition or Enterprise Edition instance using a one-click Northflank template.

GitLab's managed platform is the simplest way to get started with GitLab because GitLab manages the underlying infrastructure for you. Self-hosting becomes useful when your organization needs more control over the environment where GitLab runs.

The main reasons to self-host GitLab include:

• Data control: Keep your Git repositories, project data, and supporting services within infrastructure you control.
• Infrastructure control: Choose where GitLab runs, including the cloud provider, region, and infrastructure configuration.
• Network requirements: Run GitLab within a private network or alongside internal applications and services.
• Security and compliance: Apply your organization's infrastructure, identity, networking, and security controls to your GitLab deployment.
• Customization: Configure GitLab and its supporting infrastructure according to your organization's requirements.
• Cloud flexibility: Use existing cloud infrastructure or commitments rather than relying exclusively on a SaaS environment.
• Operational control: Decide how GitLab is deployed, updated, backed up, monitored, and managed.

The tradeoff is that self-hosting makes your team responsible for operating the GitLab environment. You need to think about storage, backups, updates, networking, security, monitoring, and availability.

For small teams that simply need Git hosting and CI/CD, GitLab's managed platform may be easier. For organizations with infrastructure, security, or data requirements that make a managed SaaS platform unsuitable, self-hosting can provide significantly more control.

For a Docker-based installation, you'll need the following:

• Docker: GitLab is distributed as a Docker image, so you need Docker Engine and Docker Compose if you're following the standard Docker Compose setup.
• A hostname: GitLab requires a hostname that resolves to the server where GitLab is running. The hostname is used to configure GitLab's external_url.
• Persistent storage: GitLab stores its configuration, logs, and application data in /etc/gitlab, /var/log/gitlab, and /var/opt/gitlab. These directories should use persistent storage so data survives container restarts or replacements.
• Sufficient compute and memory: GitLab is a relatively resource-intensive application, so the host needs enough CPU and memory for the GitLab services and the workloads you expect to run.
• Network access: The GitLab instance needs the appropriate ports exposed for web access and, if required, SSH access for Git operations.
• A GitLab edition: You can self-host either GitLab Community Edition or Enterprise Edition, depending on the features and licensing requirements of your organization.

The easiest way to self-host GitLab on Northflank is to use one of the preconfigured GitLab stack templates. You can choose between Community Edition and Enterprise Edition and deploy either directly to Northflank Cloud or to your own cloud through BYOC.

Sign up for Northflank and create a team for your GitLab deployment.

GitLab requires a significant amount of compute and persistent storage to run reliably, so you may need to upgrade your Northflank plan depending on your deployment requirements.

Northflank provides one-click deployment templates for both GitLab Community Edition and GitLab Enterprise Edition:

1. GitLab Community Edition: Deploy the open-source Community Edition.
2. GitLab Enterprise Edition: Deploy Enterprise Edition with its additional enterprise features.

The deployment process is the same for both editions. Choose the edition you want to deploy and click Deploy {edition} now.

For this guide, we'll deploy GitLab Community Edition.

1. The template uses GitLab version 19.0.8-ce.0 by default. You can select a different version in the stack configuration before deploying.
2. Review the stack configuration and click Deploy stack.
3. Northflank provisions the GitLab project, service, persistent volume, and required configuration.
4. Once the deployment is complete, click Resource.
5. Open the GitLab Service.
6. Open the generated public domain to access your GitLab instance.

GitLab can take several minutes to initialize on first startup. The service must complete its initialization and pass its readiness check before the GitLab UI becomes available.

GitLab generates an initial password for the root administrator account when the instance is first initialized. You can retrieve it from the GitLab service shell.

1. From the GitLab Service dashboard, open Observe under Observability.
2. Select Shell.
3. Run the following command: grep 'Password:' /etc/gitlab/initial_root_password
4. Copy the generated password.

You can now open your GitLab instance and sign in with:

• Username: root
• Password: The password returned by the command above.

After signing in, change the initial password and configure your GitLab instance according to your organization's requirements.

Once GitLab is deployed, you can manage the instance and its underlying infrastructure directly from the Northflank dashboard. Key areas include:

• Service management: Start, restart, redeploy, and monitor the GitLab service from the Northflank dashboard.
• Resource management: Adjust the compute resources allocated to GitLab as your users, repositories, and workloads grow.
• Persistent storage: Manage the volume attached to GitLab and increase its capacity when you need additional storage.
• Environment configuration: Update GitLab configuration and environment variables through the service configuration and secret groups.
• Networking and domains: Manage the public domain and configure custom domains for your GitLab instance.
• Logs and observability: Use Northflank's observability tools to inspect GitLab logs, access the service shell, and troubleshoot issues.
• GitLab versions: Update the GitLab image version when you want to upgrade your deployment. Review GitLab's upgrade requirements before changing versions.
• Deployment configuration: Modify the deployment configuration as your requirements change, including compute, storage, networking, and other service settings.
• Cloud infrastructure: If you're using BYOC, manage the GitLab workload in your own cloud environment while continuing to manage the deployment through Northflank.

The GitLab software and the infrastructure it runs on are separate considerations. Community Edition is available for self-managed deployments, but you still need to provide the compute, storage, networking, and other infrastructure required to operate the instance.

Yes. GitLab can be deployed in your AWS environment. With Northflank BYOC, you can deploy GitLab into your own cloud environment while continuing to manage the deployment through the Northflank platform.

Yes. You can use a deployment platform that manages the underlying orchestration layer for you. Northflank abstracts much of the underlying infrastructure management, so you can deploy and operate GitLab without manually managing Kubernetes.

It depends on the capabilities your organization needs. Community Edition provides the core GitLab platform, while Enterprise Edition is intended for organizations that need additional enterprise capabilities. Choose the edition that matches the features and licensing requirements of your team.

Yes. Northflank provides one-click GitLab templates that package the resources and configuration required for the deployment. You can choose between Community Edition and Enterprise Edition, review the configuration, and deploy the instance without manually creating each underlying resource.

Yes. Northflank BYOC allows you to deploy GitLab into your own cloud environment instead of Northflank Cloud. You retain control over the underlying cloud infrastructure while managing the GitLab deployment through Northflank.

Your backup strategy should cover the persistent data required to restore GitLab. For a production instance, define your backup frequency, retention, storage location, and recovery process, and test your backups regularly to make sure you can restore the instance when needed.

GitLab's managed platform is generally simpler if you want GitLab without managing the underlying infrastructure. Self-hosted GitLab gives you more control over infrastructure, networking, and data location, but also means taking responsibility for backups, updates, security, and maintenance. If you need that additional control without building the entire deployment infrastructure yourself, you can use a Northflank GitLab template to deploy GitLab on Northflank Cloud or in your own cloud through BYOC.

Self-hosting GitLab gives you greater control over where GitLab runs, how it connects to your infrastructure, and how your development data is managed. However, that control also comes with the responsibility of maintaining the instance, including backups, updates, security, and monitoring.

With Northflank, you can simplify the initial deployment using a one-click GitLab Community Edition or Enterprise Edition template. The templates provision the GitLab service, persistent storage, networking, and required configuration, while giving you the option to run GitLab on Northflank Cloud or in your own cloud through BYOC.