Which GitLab install method fits your team
If your team must self-manage GitLab and does not already run Kubernetes in production, start with the Linux package. GitLab's installation methods page says to use the Linux package if you want the most mature, scalable method, and that the same version runs on GitLab.com. The Linux package bundles PostgreSQL, Redis and Sidekiq on the same server, so one team can install, upgrade and back up the instance with standard Linux administration skills. The Helm chart and the GitLab Operator are cloud-native routes on Kubernetes. They fit teams that already operate clusters, have people who can troubleshoot pods and persistent volumes, and have decided that Kubernetes is the platform they want to standardize on. GitLab's own warning is that administration and troubleshooting require Kubernetes knowledge, so a Kubernetes skills gap is a planning risk, not a footnote.
The cloud-native route has real advantages for the right team. Its default installation needs more resources than a single node Linux package deployment, but it can share a cluster with other workloads and follow the same GitOps and policy tooling your platform team already uses. The Helm chart requires external PostgreSQL, Redis and object storage, and GitLab's reference architectures say that running stateful components such as PostgreSQL and Redis inside Kubernetes is not supported. Before you choose this route, confirm with GitLab which Cloud Native Hybrid layout applies to your user count and which managed or VM-based services you will run for the stateful parts. The Operator offers functionality beyond the Helm chart, but GitLab advises considering the Helm chart if the Operator's known issues are limiting, so check the current known issues list before you commit.
Docker and source installs are narrower options. GitLab documents a Docker installation that runs the GitLab packages in a container, which suits teams that already standardize on container hosts but still want a single-instance deployment. A self-compiled installation covers platforms the other methods do not support, such as BSD systems. For most regulated teams the practical choice is between the Linux package on VMs and a Kubernetes route with external stateful services. Ask GitLab support or your reseller to confirm which method is supported for your target OS, storage and air-gapped requirements, since GitLab's offline environments guidance applies to every method.
How the Linux package, Helm chart and Operator compare
This table compares the three self-managed GitLab install methods on maturity, bundled versus external dependencies, resource needs, Kubernetes skills, upgrades and Operator risk. Read each row against your team's current skills and the platform you already run, because the Linux package is the documented default for most teams and the Kubernetes routes add prerequisites. Confirm any specific sizing or Operator issue with GitLab before you commit.
| Decision factor | Linux package (Omnibus) | Helm chart | GitLab Operator |
|---|---|---|---|
| Maturity per GitLab | GitLab describes it as the most mature, scalable method and it is the version used on GitLab.com | GitLab describes it as a cloud-native version for teams already on Kubernetes | Follows the Kubernetes Operator pattern with functionality beyond the Helm chart; GitLab says it has known issues |
| PostgreSQL, Redis and object storage | Bundles PostgreSQL, Redis and Sidekiq in the package | Requires external PostgreSQL, Redis and object storage | Confirm with GitLab which dependencies must be external in the current release |
| Stateful components | Runs all components on the host, so stateful services sit on the same VMs | Stateful services must run outside Kubernetes, per the reference architectures | Confirm with GitLab how stateful services are handled before deployment |
| Resource needs | Documented as the lighter option for a single node deployment | GitLab says the default installation needs more resources than a single node Linux package deployment | Confirm the footprint for your chosen topology with GitLab's sizing guidance |
| Kubernetes knowledge required | Standard Linux administration, no Kubernetes required | GitLab warns that administration and troubleshooting require Kubernetes knowledge | Requires Kubernetes knowledge plus familiarity with Operator behavior and known issues |
| Upgrade handling | Upgrades must pass through GitLab's required upgrade stops, such as x.2, x.5, x.8 and x.11 since GitLab 17.5 | Same required upgrade stops apply to the application; confirm chart version compatibility in GitLab's chart docs | Confirm with GitLab how the Operator handles required upgrade stops and whether known issues affect the upgrade path |
| Reference architecture fit | Suited to standalone deployments and documented single node use, with high availability reference architectures for larger user counts | Cloud Native Hybrid is the documented production pattern when stateful services stay on VMs or managed services | Confirm which reference architecture GitLab supports with the Operator for your user count |
| When to choose it | Your team runs Linux VMs and does not operate Kubernetes in production | You already run Kubernetes and your platform team can own the external PostgreSQL, Redis and object storage | Your team needs Operator-managed lifecycle on Kubernetes and GitLab's known issues do not block your use case |
Which method fits which environment
If your team runs virtual machines or bare metal and has no Kubernetes cluster in production, the Linux package is the method GitLab describes as the most mature and scalable, and it is the one GitLab uses on GitLab.com. The package bundles PostgreSQL, Redis and Sidekiq, so a single node deployment needs no separate database or cache service to start. Growth beyond one node moves you toward GitLab's reference architectures, which the Linux package can serve, rather than toward Kubernetes.
- Fit: a standalone instance on VMs, backed by regular backups, with an operations team comfortable with Linux packages and
gitlab-ctlcommands. - Demand: patching and upgrades on a fixed cadence, including the required upgrade stops GitLab publishes for each series.
- Scale path: GitLab's high availability reference architectures are built from VMs, with PostgreSQL with Patroni, Redis Sentinel and Gitaly Cluster with Praefect, so the Linux package stays relevant as you grow.
- Air-gapped sites: GitLab documents offline installations, which suit VM estates with no internet egress.
Confirm with your team that you can run backup and restore tests for the bundled components before you commit to a single node.
If your organization already runs production Kubernetes and has staff who operate it, the Helm chart or the GitLab Operator is the native route. GitLab says the Helm chart installs a cloud-native version of GitLab and that administration and troubleshooting require Kubernetes knowledge. The chart does not bring its own stateful services: it requires external PostgreSQL, Redis and object storage, and GitLab's reference architecture documentation says stateful components such as PostgreSQL and Redis are not supported inside Kubernetes. That pushes the design toward the Cloud Native Hybrid architecture, with stateless components on the cluster and stateful services on VMs or managed services.
- Fit: an existing platform team with cluster operations, GitOps and ingress already in place.
- Demand: three separate stateful services to host, back up and upgrade outside the cluster.
- Operator option: the GitLab Operator follows the Kubernetes Operator pattern and offers functionality beyond the chart, but GitLab advises considering the Helm chart if the Operator's known issues limit you.
- Resource cost: GitLab notes that the default cloud-native installation needs more resources than a single node Linux package deployment.
Before choosing, ask GitLab and your platform team to confirm which version of the chart or Operator you will run and how they map to your cluster version.
GitLab documents a Docker installation that runs the GitLab packages inside a container. It suits teams that already standardize on container hosts for single-node services and want the GitLab image to follow the same build and restart workflow. It does not remove the need to plan storage, backups and upgrades, because the container still holds GitLab's data and configuration on mounted volumes. Docker on a single host is a different operational model from the cloud-native chart, so do not read it as a stepping stone to Kubernetes.
- Fit: a single-host instance where the team already runs Docker and wants the container lifecycle.
- Demand: persistent volume layout for configuration, logs and data, and tested restore procedures.
- Upgrades: you must still follow GitLab's required upgrade stops rather than jumping series.
- Limits: a container host is still one failure domain, so high availability needs the reference architecture approach.
Ask GitLab support or your reference architecture partner to confirm which Docker tags are supported for your target version and how they handle data migration.
GitLab documents a self-compiled installation for platforms the other methods do not cover, and gives BSD systems as an example. This route is for teams whose hosts run an operating system that the Linux package, Docker and the Kubernetes methods do not support. It places the full build, dependency and update burden on your team, so it should be a deliberate choice rather than a fallback when the package does not install.
- Fit: a BSD or other non-standard host where the platform itself is a fixed requirement.
- Demand: compiling, managing dependencies for Ruby, Go and PostgreSQL, and tracking every component update yourself.
- Support: confirm with GitLab which parts of the self-compiled path are covered by its documentation and which are your responsibility.
- Alternative: if the constraint is the operating system, check whether a Linux VM hosts the Linux package, which is the supported path with the most documentation.
Before committing, have your team estimate the upgrade effort for each GitLab minor release and ask GitLab to confirm the supported platforms for your target version.
What the Helm chart needs beyond Kubernetes
The Helm chart does not bring its own database, cache or object store. It requires external PostgreSQL, Redis and object storage, so a team choosing this route is really building three supporting services alongside the Kubernetes cluster. GitLab's reference architecture documentation says running stateful components such as PostgreSQL and Redis inside Kubernetes is not supported, and the Cloud Native Hybrid architecture keeps stateless components on Kubernetes while placing stateful services on virtual machines or managed services. Your platform team owns the PostgreSQL and Redis instances, their backups and their upgrades, and the storage team owns the object buckets. Confirm which of these you will host yourself and which a managed provider in your environment can supply, and confirm the chart's production guidance against the current Cloud Native Hybrid reference architecture before you size anything.
The Kubernetes layer adds its own decisions. The kubeadm high availability guide describes a stacked control plane, with etcd on the control plane nodes, or an external etcd cluster, with at least three control plane nodes and a TCP load balancer in front of kube-apiserver on port 6443. Kubernetes documentation says etcd should run with an odd number of members, recommends five members in production and requires a backup plan using etcdctl snapshot save. Choose the topology before installation, because moving etcd later is harder than choosing it first. Also confirm how Kubernetes Secrets are protected: by default they are stored unencrypted in etcd, so encryption at rest and least-privilege RBAC must be configured. These are the controls your cluster administrators, not the GitLab chart, must own.
Before committing, ask who on your team can operate a cluster, a stateful database and object storage during an incident. The chart's own installation methods page warns that administration and troubleshooting require Kubernetes knowledge. Ask your integrator for a written scope covering each external service, its backup and restore path, and the etcd and control plane runbooks, so the GitLab deployment does not depend on a single person's cluster knowledge.
What drives the cost of each route
Cost depends less on the install method itself than on what sits underneath it: the platform, the external services, the people who run it, and the subscription tier. The cards below separate one-time build work from recurring operation, and name who is paid for each part so you can ask for a quote that is comparable across routes.
Kubernetes platform underneath the chart
The Helm chart and the Operator both assume a working Kubernetes cluster, and GitLab's installation methods page says administration and troubleshooting require Kubernetes knowledge. Ask whether a quote includes building the cluster, or only installing GitLab onto one you already run. The control plane layout, etcd backups and upgrade cadence are recurring work that the cluster owner carries, whichever vendor or partner does the first build.
External PostgreSQL, Redis and object storage
The GitLab Helm chart requires external PostgreSQL, Redis and object storage, and GitLab's reference architectures say stateful components such as PostgreSQL and Redis inside Kubernetes are not supported. The Linux package bundles PostgreSQL and Redis, so this is a cost the chart route adds. Confirm who provisions and licenses these services, who patches them, and whether high availability for PostgreSQL with Patroni is in scope.
Resource overhead of the default install
GitLab's installation methods page states that the default cloud-native installation needs more resources than a single node Linux package deployment. That means more nodes, more memory and more storage to pay for every month, whether the capacity comes from your own hardware or a cloud account. Ask the quote to state the node count and sizing it assumes, and how that sizing changes at your user count.
Staff with Kubernetes skills
Labor is usually the largest recurring cost. A team that already runs Kubernetes can absorb GitLab into existing on-call and tooling, while a team that does not will pay for training or outside help on every incident. Ask who will carry day-to-day operation, which skills they need, and whether the quote covers handover documentation and runbooks.
Upgrade work across required stops
GitLab requires upgrades to pass through required upgrade stops, which since GitLab 17.5 fall at versions x.2, x.5, x.8 and x.11. GitLab ships a minor release monthly, and the maintenance policy keeps the current and previous two minor releases in maintenance. Each route handles these stops differently, and the Kubernetes version skew and etcd backup duties add work on the chart and Operator routes. Ask for the upgrade effort per cycle, including testing and rollback, and whether it is a fixed or retainer item.
GitLab subscription tier
The license is separate from the install method. According to the GitLab pricing page, Free costs 0 US dollars, Premium costs 29 US dollars per user per month billed annually, and Ultimate is custom priced, with all three tiers available for self-managed installations. The subscription is recurring and scales with seats, so it does not change between Linux package, Helm chart and Operator, but it can dominate total cost. Ask the vendor to confirm the tier for each feature you need before comparing routes.
How upgrades and release cadence differ by install method
GitLab's release rhythm applies to every install method, so the upgrade plan starts there. According to the GitLab maintenance policy, GitLab ships a minor release on the third Thursday of each month, patch releases twice a month and one major release a year, with GitLab 20.0 planned for May 2027. Only the current release receives bug fixes, while security fixes are backported to the previous two monthly releases, and the policy lists 19.5, 19.4 and 19.3 as maintained. Upgrades also have to pass through required upgrade stops at x.2, x.5, x.8 and x.11 (for example 19.2, 19.5, 19.8 and 19.11), as described in the GitLab upgrade paths documentation. A team that falls behind on the monthly cadence can therefore face a multi-step upgrade path, whichever install method it chose.
The Helm chart and the GitLab Operator add a second moving part: the Kubernetes cluster and the chart or Operator version that targets it. Kubernetes maintains the three most recent minor releases, and the version skew policy requires kube-apiserver to be upgraded one minor version at a time, before the control plane components and kubelets, with kubelets allowed to lag up to three minor versions. Your upgrade sequence therefore has to satisfy the GitLab upgrade stops and the Kubernetes skew rules at the same time. Ask GitLab which chart or Operator version pairs with each GitLab release, and confirm which Kubernetes minor versions that pairing supports before you schedule a cluster upgrade. Also confirm how your team will rehearse upgrades in a non-production cluster, since the Operator's known issues are documented on the installation methods page.
For a Linux package deployment, the work is mostly one package upgrade per node, plus the PostgreSQL, Redis and Sidekiq components bundled with it. For a Helm or Operator deployment, the work also includes cluster upgrades, managed or external PostgreSQL, Redis and object storage upgrades, and the chart values that need to change between releases. Decide who owns each layer, set a maintenance window for every stop, and write a rollback plan that covers the database schema changes that GitLab applies during upgrades. Confirm these steps with your GitLab support or DeployOpen engagement scope before the first production upgrade.
Upgrades, backups, monitoring and skills for each route
This table compares how each GitLab installation route handles upgrades, backups, monitoring and the skills your team needs to run it. Read each row against your own staffing: the Linux package keeps operations closer to traditional server administration, while the chart and Operator add Kubernetes and external data services to the work.
| Area | Linux package (Omnibus) | Helm chart | GitLab Operator |
|---|---|---|---|
| Upgrade path handling | Follow GitLab's required upgrade stops, which since 17.5 fall at x.2, x.5, x.8 and x.11 (for example 19.2, 19.5, 19.8 and 19.11). Plan each hop against the upgrade paths documentation. | Same required upgrade stops apply to the GitLab release. Chart version and GitLab version must be matched, so confirm the compatible pairing in the chart docs before each upgrade. | Same required upgrade stops apply to the GitLab release. Confirm Operator compatibility and any open known issues on the installation methods page before scheduling an upgrade. |
| Backup and restore approach | Use GitLab's backup and restore guidance. The package bundles PostgreSQL, Redis and Sidekiq, so backups cover the instance on the same host, plus repositories and object data as configured. | Backups must cover the external PostgreSQL, Redis and object storage the chart depends on, not only the GitLab application. Confirm the restore procedure with your database and storage owners. | Backups must cover the external data services and the Kubernetes objects GitLab uses. Confirm with GitLab which components the Operator backs up and which you must back up yourself. |
| Kubernetes etcd backup | Not applicable. | Cluster state lives in etcd. Kubernetes documentation requires a backup plan for etcd data, using etcdctl snapshot save and etcdutl for restores. Test restores on a separate cluster. | Same etcd requirement as the chart. Include etcd snapshots in your recovery runbook alongside GitLab data backups. |
| Monitoring and troubleshooting effort | Logs and service status are read on the host with standard Linux tooling. GitLab's administration docs describe the bundled services, which keeps the diagnostic path shorter for most teams. | GitLab warns that administration and troubleshooting require Kubernetes knowledge. Your team must monitor pods, nodes, the external services and the GitLab components together. | Adds Kubernetes operator reconciliation to the diagnostic path. Confirm how the Operator reports status and which known issues apply to your version. |
| Resource overhead to watch | Sized for a single node or a defined multi-node layout. Monitor CPU, memory and disk on the host, plus PostgreSQL and Redis growth. | The default installation needs more resources than a single node Linux package deployment, according to GitLab. Size nodes, storage classes and the external data services together. | Shares the chart's cluster footprint. Confirm resource requests with GitLab's reference architecture guidance before sizing. |
| Skills each route needs | Linux administration, PostgreSQL and Redis basics, TLS, backup tooling and the GitLab Rails command line for recovery tasks. | Kubernetes administration (workloads, storage, networking, RBAC), Helm, plus PostgreSQL, Redis and object storage operations and the Cloud Native Hybrid layout. | Kubernetes operator concepts, custom resources and everything the chart requires. Confirm which Operator issues affect your version before committing. |
| Verification before you commit | Ask for a restore test on a copy of your instance and a dated upgrade rehearsal for each required stop. | Ask the vendor or your architect to confirm the external service design, the etcd backup schedule and who owns each restore step. | Confirm the Operator's known issues in writing and confirm whether your team or DeployOpen will handle Kubernetes-level incidents. |
How to choose and validate an install method
This sequence turns the three GitLab install methods into a decision your team can defend, with each step producing a written input or a tested result before the next one starts. It ends with a test install and an upgrade rehearsal, so production is the first time the chosen method meets real data.
Inventory Kubernetes skills and platform
Platform and operations leads list who would administer and troubleshoot a cluster, which Kubernetes distribution and version your organization already runs, and who is on call for it. GitLab's installation methods page warns that administering and troubleshooting the Helm chart requires Kubernetes knowledge, so this inventory is the first real test. You are done when you can name the people who would handle a failed pod, a stuck upgrade and a certificate problem, and that list is written down.
Decide where stateful services will run
Architects decide where PostgreSQL, Redis and object storage will live before choosing a method, because the Helm chart requires them to be external. The GitLab reference architectures documentation says stateful components such as PostgreSQL and Redis are not supported inside Kubernetes, and the Cloud Native Hybrid pattern places them on VMs or managed services. You are done when each stateful service has a named owner, a hosting location and a backup approach written in the design record.
Check user count against reference architectures
Architects compare the expected number of users and API request rate with the sizes in GitLab's reference architectures, which run from 1,000 users to 50,000 users. The docs generally recommend a high availability strategy at 3,000 or more users, so the sizing result decides whether a single node or a multi-component layout is needed. You are done when the expected user count, peak request rate and target architecture are recorded, and the team agrees on whether high availability is in scope.
Select the install method in writing
The platform owner chooses the Linux package, the Helm chart, the Operator, Docker or a source install using the answers from the previous steps. GitLab describes the Linux package as the most mature, scalable method, while the Helm chart and Operator suit teams already running Kubernetes. Record the decision, the reasons, and what would trigger a revisit, such as a change in user count or the Operator's known issues. You are done when an approver has signed the decision record.
Run a test install in a non-production environment
The platform team installs the chosen method in an isolated environment that mirrors the production network, identity provider and storage backend. Confirm that sign-in works through your identity provider, that Git operations and CI runners connect, and that backups complete and restore to a scratch location. You are done when a documented checklist passes and the team has recorded any deviations from the vendor documentation.
Rehearse an upgrade through required stops
Operators practice an upgrade on the test instance, following GitLab's upgrade paths, which require passing through required upgrade stops such as x.2, x.5, x.8 and x.11 since GitLab 17.5. The rehearsal should include the database migration step, a restore from the most recent backup and a rollback plan. Note how long each step took in your environment so the production change window is based on measured data. You are done when the rehearsal ends with a clean instance and a written runbook.
Approve the production cutover with evidence
The security lead and platform owner review the test results, the backup and restore evidence, the upgrade runbook and the skills inventory before production goes live. Confirm the hardening baseline from GitLab's hardening recommendations has been applied and documented. You are done when the approvers have signed off, the rollback criteria are written, and the team knows who may invoke them.
Questions buyers ask before choosing a GitLab install method
Is the Linux package still the recommended way to install self-managed GitLab?
Yes, for most teams. GitLab's installation methods page says to use the Linux package if you want the most mature, scalable method, and notes that the same version runs on GitLab.com. The Linux package bundles PostgreSQL, Redis and Sidekiq, so a standalone instance has fewer moving parts to operate. The case for the other routes is narrower: a platform team already running Kubernetes at scale, or a standing requirement to deploy everything through cluster tooling. Confirm the current wording on the installation methods page before you standardize on a route, because GitLab updates that guidance as its methods change.
What Kubernetes skills does the GitLab Helm chart require?
Your team needs working knowledge of Kubernetes administration and troubleshooting, not just the ability to run a Helm command. GitLab's installation methods page warns that administration and troubleshooting require Kubernetes knowledge. Engineers should be comfortable with pods, persistent volumes, ingress, certificates, RBAC and rolling upgrades before they take on the chart. The chart also expects external PostgreSQL, Redis and object storage, so the team must operate or buy those services as well. If your Kubernetes staff is small or on call for other workloads, factor that load into the decision.
How much more resource overhead does the default cloud-native install need?
The default cloud-native installation needs more resources than a single node Linux package deployment, according to GitLab's installation methods page. The overhead comes from several layers: the Kubernetes control plane and nodes, the stateless GitLab services that run as separate workloads, and the external PostgreSQL, Redis and object storage the chart requires. The reference architecture documentation adds that stateful components such as PostgreSQL and Redis are not supported inside Kubernetes, so they run on VMs or managed services. Ask any partner for a sizing estimate tied to your user count and API request rate, and check it against GitLab's reference architectures, which start at 1,000 users.
Are Docker or source installs suitable for production under GitLab's documentation?
GitLab documents both methods, but its installation methods page presents them differently from the Linux package. The Docker installation runs the GitLab packages in a container, and the self-compiled installation exists for platforms the other methods do not cover, such as BSD systems. Neither is described on that page as the most mature or scalable route. Before choosing either, read the current GitLab documentation for the specific method, confirm how upgrades, backups and reconfiguration are handled, and confirm that your support path covers it. A source install in particular puts the build and patch burden on your team.
How long does a migration between install methods take, and what drives the effort?
The effort depends mostly on data volume, the target topology and how much change the platform carries, not on the install tool alone. Moving between methods usually means moving repositories, databases, object storage and configuration, then validating users, runners and integrations. Required upgrade stops also shape the plan: since GitLab 17.5 these fall at versions x.2, x.5, x.8 and x.11, so an old instance may need several stops before it reaches the target. No duration is given here because it varies with your instance. Ask for a written plan that lists the backup and restore steps, the upgrade path and the cutover window.
Can our own team install and run self-managed GitLab without outside help?
A team with Linux administration experience can usually run a Linux package instance, since that route is GitLab's most mature method and bundles its own PostgreSQL, Redis and Sidekiq. The cloud-native routes need Kubernetes experience plus operation of external PostgreSQL, Redis and object storage, which is a larger skill set. Key questions are who handles upgrades on the required stops, who tests backups and restores, and who owns on-call response. If those roles are thin, an external implementation partner can help with setup and runbooks, but your team still needs to own operations.
What should we ask DeployOpen for in a scoped quote for a GitLab install?
DeployOpen does not publish a price list, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ask for the chosen install method and the reasons for it, the target topology and sizing assumptions, and the list of external services you will run. Also ask which components DeployOpen will plan, implement, harden, back up and document, what testing and handover are included, and whether ongoing support or upgrades are offered as a retainer. Request that the quote state what is excluded, such as your own infrastructure or licensing.
Does GitLab support running PostgreSQL and Redis inside Kubernetes?
No, not for production in the reference architectures. GitLab's reference architectures documentation says running stateful components such as PostgreSQL and Redis inside Kubernetes is not supported. The Cloud Native Hybrid architecture runs stateless components on Kubernetes and places stateful services on VMs or managed services instead. Plan the database and cache tier before you choose the chart, and confirm the current support statement with GitLab, since this is a requirement that affects the whole design.
When Kubernetes skills justify the cloud-native route
The Helm chart or the GitLab Operator earns its complexity only when the team already runs a Kubernetes platform well and the organization wants GitLab to share that platform with other workloads. Kubernetes competence is the deciding factor, not interest in containers. GitLab's installation methods page warns that administration and troubleshooting require Kubernetes knowledge, and the default cloud-native installation needs more resources than a single node Linux package deployment. A team that already handles node failures, certificate rotation, persistent volume problems and rolling upgrades on its own clusters can absorb those demands. A team that would learn them on the GitLab incident is taking on risk it has not priced.
Before choosing the cloud-native route, check four conditions. First, the cluster has an owner, a patch cadence and monitoring that the platform team already operates. Second, staff can read pod logs, events and scheduling failures during an outage without outside help. Third, the chart's external dependencies are in place: the chart requires external PostgreSQL, Redis and object storage, and GitLab's reference architectures state that PostgreSQL and Redis inside Kubernetes are not supported. Fourth, the organization can name who owns the Kubernetes control plane and its etcd backups, since those become part of GitLab's recovery path. Confirm the current support position for each stateful component with GitLab before you commit, because the reference architecture guidance governs what the vendor will support.
The Linux package remains the better fit when the team has no Kubernetes platform to host GitLab, when GitLab would be the only workload that justifies a cluster, or when the staff who would carry the pager have no Kubernetes troubleshooting experience. GitLab describes the Linux package as the most mature and scalable method and as the version it uses on GitLab.com, so it is the path with the longest operational history. Ask GitLab whether the Operator's known issues affect your planned features, since the installation methods page advises considering the Helm chart if those issues are limiting. Then confirm in your own environment whether your cluster version falls within the Kubernetes support window and whether your upgrade calendar can absorb both GitLab's required upgrade stops and Kubernetes' version skew rules.
How DeployOpen plans and runs GitLab deployments
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including GitLab. For a GitLab install, we start from the deployment method your team can operate over the long term, then agree the scope, build, handover and support in writing before work begins.
How we scope
- We confirm whether your team runs Linux servers, Kubernetes or both before choosing an installation method.
- We document user count, API load, air-gapped requirements and required external PostgreSQL, Redis and object storage.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We install GitLab in your cloud account, data center or air-gapped network, following the method you selected.
- We configure authentication, backups, runners and upgrade procedures, and test restores before go-live.
- We run security testing against the instance and record findings, fixes and retest results for your review.
How we hand over
- You receive written documentation covering architecture, configuration, backup, restore and upgrade steps.
- Handover includes a walkthrough with your administrators so the team can run routine tasks without us.
- Compliance evidence we prepare is organized for your independent auditor, since we do not issue attestations.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainer scope, including GitLab upgrade stops and monthly release review, is agreed in writing.
- Ask any provider to confirm which GitLab versions and upgrade paths their support covers before signing.
