When a single node GitLab is enough and when to build high availability
A standalone GitLab is enough for most teams under 2,000 users, provided backups and restore are tested. GitLab's reference architecture guidance places environments serving 2,000 or fewer users on a standalone approach, which can be a single node or a multi-node layout without high availability, and relies on backups for recovery. Build a high availability reference architecture when your user base reaches 3,000 or more users, or when your traffic reaches about 60 requests per second, which is the threshold GitLab uses in its decision tree. Between those two points, the deciding factor is not headcount but whether downtime would critically impact your workflow.
Choose the standalone path when an outage of a few hours is tolerable for your engineers and your recovery objectives can be met from backups. In that case your effort goes into a scheduled backup job, an off-instance copy of the backup files, and a restore rehearsal on a separate host. Confirm with your own team how long a restore takes on your hardware and what data loss is acceptable, because GitLab's documentation describes the backup and restore procedure but does not promise a recovery time for your environment. Choose high availability when pipelines gate production releases, when many teams depend on the instance around the clock, or when your organization has a formal availability target that a single host cannot meet.
Disaster recovery is a separate question from high availability. A multi-node reference architecture protects against a failed component inside one site, but it does not protect against losing the site. GitLab's reference architecture documentation advises using its advanced and complex Geo setup only when disaster recovery is a key requirement, so treat Geo as a decision of its own with its own operating cost. Before you commit to any architecture, ask your GitLab partner or GitLab's support team to confirm the sizing for your user count and request rate, and document the choice in your continuity plan with a named owner for each restore step.
Which deployment fits which team
A small team that can accept planned downtime usually does not need a high availability design. GitLab's reference architectures generally place environments serving 2,000 or fewer users on a standalone approach, which can be single-node or multi-node without HA and depends on backups for recovery. In this model the work is operational discipline: scheduled upgrades, tested restores and a named owner for each step.
- Threshold: a standalone approach for 2,000 or fewer users, with recovery based on backups.
- Upgrade windows: plan each upgrade around GitLab's required upgrade stops, which since 17.5 fall at versions x.2, x.5, x.8 and x.11.
- Patch cadence: minor releases arrive monthly and security fixes reach the previous two releases, so a fixed monthly window keeps the instance supported.
- Restore testing: a backup that has never been restored is an assumption. Restore into a separate host and record how long the restore takes with your own data.
- Change condition: the answer changes when user count approaches 2,000, when peak API traffic reaches the 60 RPS decision point, or when a stopped instance starts blocking releases.
Confirm current active users and peak request rate from your own metrics before you accept the standalone design.
When an outage stops merges, deployments and hotfixes, downtime has a direct cost even for a moderately sized instance. GitLab generally recommends a high availability strategy for environments serving 3,000 or more users, and its decision tree uses 60 RPS or 3,000 users as the threshold. The documentation advises HA only when downtime would critically affect your workflow, so the test is how much of your delivery depends on GitLab during an outage.
- Threshold: HA is generally recommended from 3,000 users or 60 RPS, whichever the decision tree flags first for your workload.
- Reference architecture: the Linux package reference architectures cover 1,000 to 50,000 users and 20 to 1,000 RPS, and the HA strategy uses Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul.
- Cloud Native option: Cloud Native Hybrid starts at 2,000 users and suits teams with Kubernetes skills, while Cloud Native is the recommended architecture for new deployments.
- Operating load: every HA component adds monitoring, patching and failover testing, which is recurring effort for your team or a support partner.
- Change condition: an organization between 2,000 and 3,000 users, where a stopped instance halts production deployments, should run the decision tree now instead of waiting for the 3,000 figure.
Ask for a written load model based on the decision tree and a list of components each candidate architecture requires.
Regulated teams usually start from recovery objectives set by the business, then choose the GitLab design that can meet them. The GitLab material this page relies on does not state recovery times, so recovery time and recovery point targets must come from your risk owners and be tested in your environment. The distinction that matters is between high availability, which handles component failure inside a site, and GitLab Geo, which is the disaster recovery option across sites.
- Backups first: backup and restore is the baseline for every standalone design, and the restore procedure needs documented steps and retained evidence.
- HA for component failure: a reference architecture reduces the impact of a failed node, but it does not replace off-site backups.
- Geo for site loss: GitLab advises the advanced and complex Geo setup only if disaster recovery is a key requirement, so record that justification in writing before building it.
- Tier check: confirm on the GitLab pricing page which self-managed tier includes Geo before budgeting, because feature placement can change.
- Change condition: if restoring from backup cannot meet the agreed objective within the stated window, HA or Geo moves from optional to required.
Ask the risk owner to document the objectives, then ask the design partner to demonstrate a test that meets them.
Air-gapped networks change what can run inside the enclave, while the user and request thresholds stay the same. GitLab documents running self-managed instances in offline environments, and it provides separate guidance for running its security scanners and GitLab Duo Self-Hosted offline. The reference architecture is still set by users and RPS, but every stateful service must fit inside the enclave, which determines whether Kubernetes or managed services are an option.
- Threshold: the same standalone and HA thresholds apply, measured on users and RPS from inside the network.
- Install method: the Linux package bundles PostgreSQL, Redis and Sidekiq and is described as the most mature, scalable method, which suits enclaves without a Kubernetes platform. Compare options on the GitLab installation methods page.
- Stateful services: Cloud Native Hybrid keeps PostgreSQL, Redis and object storage on virtual machines or cloud services, so confirm those exist inside the enclave before choosing it.
- Scanners and AI features: confirm the offline guidance for each scanner and for Duo Self-Hosted separately, since each is documented on its own.
- Change condition: if the enclave cannot host Kubernetes or an object store, the Linux package layout is the practical starting point, and each upgrade path must be staged offline.
Confirm the offline update process with GitLab before setting a schedule, because staged packages and required upgrade stops add effort.
Single node vs high availability reference architecture side by side
This table compares a standalone GitLab deployment backed by backups against GitLab's high availability reference architectures, factor by factor. Read each row as the question to settle with your team, and use the thresholds GitLab documents as the starting point rather than the final answer.
| Factor | Standalone (no HA, backup-based recovery) | HA reference architecture |
|---|---|---|
| User and RPS sizing | GitLab says environments serving 2,000 or fewer users should generally follow a standalone approach | GitLab generally recommends HA for 3,000 or more users, or around 60 RPS in its decision tree |
| Components on the path | One instance or multi-node without HA, with PostgreSQL, Redis and Gitaly in the chosen layout | Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul, per GitLab's HA guidance |
| Backup and restore role | Backups are the primary recovery mechanism; restore time and data loss depend on your backup schedule and tested restores | Backups remain required; HA reduces how often a restore is needed but does not replace them |
| Availability design | Downtime during a node failure is expected until the node is restored or rebuilt | Designed to tolerate component failures, but only worth the added complexity when downtime would critically impact your workflow |
| Upgrade and maintenance windows | Upgrades follow required upgrade stops (for example 18.2, 18.5, 18.8, 18.11) with a single outage window | Upgrades follow the same stops, but the HA layout must be planned so components are updated in a documented order; confirm with GitLab upgrade guidance |
| Operating skills | Linux administration, backup and restore testing, and GitLab upgrade procedures | Adds PostgreSQL failover, Patroni, Redis Sentinel, Consul and Gitaly Cluster operations, plus monitoring for each |
| Cost drivers | Server capacity, backup storage and the time spent on tested restores | More VMs or nodes, load balancing, object storage, and the staff time to run and test failover; confirm node counts in the GitLab sizing guidance |
| Kubernetes placement | Not applicable to a single-node Linux package install | Cloud Native Hybrid keeps PostgreSQL and Redis off Kubernetes; Gitaly nodes may run on Kubernetes per GitLab's reference architectures |
How the Linux package, Cloud Native Hybrid and Cloud Native architectures differ
GitLab's high availability reference architectures come in three shapes, and each one moves a different share of the work into Kubernetes. The right choice depends on your user count, your request rate, and how much Kubernetes skill your team already has to operate.
Linux package reference architectures
These are sized from 1,000 to 50,000 users and 20 to 1,000 RPS, and every component runs on virtual machines installed from the Linux package. The operating burden is VM patching, Gitaly and Praefect tuning, and Patroni failover drills that your own team runs. This shape suits teams that operate VMs well and do not want a Kubernetes control plane in the GitLab path. Check whether your VM automation can rebuild each node from code, because recovery time depends on it.
Cloud Native Hybrid architecture
This architecture starts at 2,000 users and runs stateless components such as Webservice and Sidekiq in Kubernetes. Stateful services such as PostgreSQL, Redis and object storage stay on virtual machines or in managed cloud services. The split means two operating models at once, so your team needs both Kubernetes and VM skills, plus a clear owner for each layer. Confirm which managed database or object store your cloud or data center offers before you size the cluster.
Cloud Native architecture
GitLab lists Cloud Native architectures in Small, Medium, Large and Extra Large sizes up to 1,000 RPS and calls them the recommended architecture for new deployments. Individual Gitaly nodes can run on Kubernetes and are generally available. The trade-off is that you must operate the cluster, its storage classes and its upgrades as a core service, not as a side project. Ask GitLab which sizes match your request rate, and test node failure and storage recovery before go-live.
PostgreSQL and Redis stay outside Kubernetes
GitLab's reference architectures state that running stateful components such as PostgreSQL and Redis inside Kubernetes is not supported, in any of the cloud-native shapes. Plan database and cache hosts on VMs or managed services even when the rest of GitLab runs in the cluster. This affects your backup design, because the database backup path sits outside the cluster lifecycle. Confirm the current support statement in the reference architecture docs before you finalize the design.
Kubernetes skills and cluster ownership
Both cloud-native shapes assume your platform team can run a production cluster, including ingress, storage classes, node pools and certificate rotation. A cluster that only one engineer understands becomes a single point of failure of its own. Before choosing either shape, list who patches the control plane, who restores a node, and who answers when GitLab pods are evicted during a drain. If that list is short, the Linux package architecture is usually easier to staff.
Upgrade and maintenance cadence
GitLab ships a minor release monthly and requires upgrades to pass through required upgrade stops, so each architecture repeats the same sequence across more moving parts. In the Linux package shape, each node is upgraded in a set order, while in cloud-native shapes Helm values and cluster versions also change. Test the upgrade path on a copy of production, and budget the window for each stop. Ask your DeployOpen or internal team to script the rollback before you commit to a shape.
Which GitLab components may run in Kubernetes
The key rule for this section is that Kubernetes can host the stateless and some stateless-like parts of GitLab, but not the stateful data stores. Under the Cloud Native Hybrid reference architecture, stateless components such as Webservice and Sidekiq run in Kubernetes, while PostgreSQL, Redis and object storage stay on virtual machines or in managed cloud services. GitLab's reference architecture documentation states that running stateful components such as PostgreSQL and Redis inside Kubernetes is not supported. Individual Gitaly nodes can also be deployed on Kubernetes and are generally available, so Git repository storage is the one stateful component that may sit in a cluster. Confirm the exact Gitaly layout you want against the GitLab reference architectures page before you commit to it.
Running any part of GitLab on Kubernetes requires your team to operate the cluster itself, not only GitLab. Plan for people who can manage node pools, persistent volume claims, storage classes, ingress, network policies, certificate rotation and cluster upgrades, and who can read pod logs and events when a Webservice or Sidekiq pod fails. If the team does not already run production clusters, the Linux package or a virtual machine layout is usually easier to own. The stateful tier also changes your backup plan: PostgreSQL, Redis and object storage must be backed up and restored on their own schedules, and any Gitaly volumes in Kubernetes need storage that supports snapshots or a tested restore path. Ask your storage vendor and your GitLab backup procedure (see GitLab backup and restore) how a restore is sequenced across these components.
Before you choose this route, run a short check: list every component in your target architecture, mark it stateless or stateful, and assign an owner and a restore test for each stateful item. Treat the Kubernetes-hosted Gitaly nodes as a deliberate decision that needs its own storage review, not a default. Because the Cloud Native Hybrid design splits responsibilities between two platforms, incident response also needs clear ownership, so the cluster team and the database team know who acts when GitLab is degraded. An implementation partner such as DeployOpen can plan and document this split as part of a fixed-scope engagement, but the operating model still belongs to your team.
How upgrades differ between one node and a cluster
This sequence turns an upgrade into a planned, reversible change: you confirm the target version against GitLab's support and upgrade rules, rehearse the restore path, and then apply the change in the order your topology requires. The result is a documented path you can repeat each month without guessing.
Confirm the supported release tracks
Check GitLab's maintenance policy to see which releases are maintained. The current list names 19.5, 19.4 and 19.3, and bug fixes are backported only to the current stable release while security fixes also reach the previous two monthly releases. The platform owner records the current version, the target version and the date the target was published. Done means the target sits on a maintained track and the team agrees on it in writing.
Map the monthly minor release cadence
GitLab ships a minor release on the third Thursday of each month and patch releases twice a month, and a major release once a year. Someone on the platform team builds a simple calendar that matches these dates against your change freeze rules and the business calendar. Done means each upcoming minor release has a named owner and an agreed slot, so no release is applied by accident or left unpatched for long.
Check required upgrade stops
GitLab requires upgrades to pass through required stops. Since GitLab 17.5 these fall at versions x.2, x.5, x.8 and x.11, for example 18.2, 18.5, 18.8, 18.11, 19.2, 19.5, 19.8 and 19.11. The engineer reads the upgrade paths documentation and writes the exact hop sequence from the current version to the target. Done means the hop list is approved and no step skips a required stop.
Test restore from a current backup
Before any change, restore the latest backup into a separate environment built from the same package or chart version. GitLab's backup and restore documentation sets the procedure, and the restore must be tested, not only the backup job. Done means the restored instance boots, repositories clone, and the team has timed the restore on its own hardware. Record the result, because it sets how long a rollback could take.
Plan the single node maintenance window
On a standalone instance, the upgrade stops the one server, so users are offline for the whole change. The platform owner announces a maintenance window, takes a fresh backup, stops write traffic, and applies each hop in the required order with the Linux package. Done means the instance answers health checks on the target version and the team has confirmed sign-in, Git push and CI jobs. Illustrative only: a team with few users may find the outage acceptable, while a team with heavy CI traffic may not.
Sequence rolling work across components
In a multi-node reference architecture, the team upgrades components in a planned order, with a clear rule for each one, such as keeping at least one healthy node in every role during changes. Stateful services such as PostgreSQL with Patroni and Gitaly Cluster with Praefect follow their own upgrade guidance, and Kubernetes-hosted components follow the chart version. Done means each component reports healthy before the next one changes, and the sequence is written in the runbook. Confirm the exact order with GitLab's documentation for your chosen architecture.
Validate and document the outcome
After each hop, run the same smoke checks: sign-in, repository clone and push, a pipeline run, and an admin view of background jobs. Record the version, the time taken and any issues in the change log. Done means the checks pass on the final version and the log is filed with the backup identifier used. The record becomes the baseline for the next monthly cycle and for any compliance evidence you need to produce.
When Geo is worth the added complexity
Choose Geo only when disaster recovery is a key requirement. GitLab's reference architectures documentation advises the advanced and complex Geo setup for that case, and it treats a standalone deployment backed by tested backups as the default for smaller user counts. Losing a whole facility or region is a different problem from wanting fewer outages during upgrades. Before going further, write down the recovery time and recovery point you need for GitLab, the systems it depends on, and the failures you must survive. If backups restored into fresh infrastructure already meet those targets, Geo is probably not the next step.
Geo runs a second GitLab site that replicates data from a primary site so it can be promoted if the primary fails. The team effort covers much more than the extra servers. Someone must size and operate the secondary environment, monitor replication for each data type, plan upgrades across both sites, and write and rehearse the failover and failback runbooks, including how users, runners and integrations get redirected. These tasks recur for the life of the deployment, and they grow with every component you replicate. Ask any implementation partner to price them as ongoing work, not only as a one-time build.
Check the GitLab Geo documentation for the current edition requirements before you decide, because the tier that includes Geo and the licensing conditions for a secondary site can change between releases. Confirm which data Geo replicates in your version and which you must still back up separately. Also confirm what the secondary site needs from your network, DNS and identity setup. When you request a quote, ask for the failover test plan, the replication monitoring included, and what ongoing support covers, so the written scope shows who runs each recurring task.
Questions buyers ask before choosing a GitLab architecture
Can a standalone GitLab instance be backed up and restored reliably?
Yes, for many teams. GitLab's reference architectures say environments serving 2,000 or fewer users should generally follow a standalone approach, which can be single-node or multi-node without high availability, and that relies on backups for recovery. Reliability depends on the restore, not the backup job alone. Test restores on a separate host at a set cadence, time how long a restore takes against your downtime tolerance, and confirm which components your backup covers, such as repositories, database, uploads and secrets. Check the steps in GitLab's backup and restore documentation before you rely on them.
What drives the cost of a GitLab high availability build?
Four components drive most of the cost: the number of virtual machines or cloud services for each stateful and stateless role, the skills to run PostgreSQL with Patroni, Redis Sentinel, Consul and Gitaly Cluster with Praefect, the hosting and storage behind them, and the GitLab subscription tier you buy. The tier cost is set by GitLab's pricing page, where Premium is listed at 29 US dollars per user per month billed annually and Ultimate is custom priced. Hosting and staff time recur every month, while design and build work is usually one-time. Ask any provider, including DeployOpen, for a quote that separates these lines and states what each role is expected to run.
How long does a high availability build take, and what does it need from my team?
No supplied source gives a standard duration, so treat any timeline as something to agree in writing. The work depends on how many users you serve, how many components you run, whether your network, DNS, load balancers and storage are ready, and who approves changes. Your team will need to provide access to cloud or data center accounts, named owners for identity and networking, a maintenance window for cutover, and staff who can review runbooks. GitLab's sizing guidance is the place to confirm the target user count and request rate for your architecture before you start.
Can my team run GitLab upgrades without outside help?
Many teams can, if they follow the required upgrade stops and keep a tested rollback path. GitLab requires upgrades to pass through required stops, and since GitLab 17.5 these fall at versions x.2, x.5, x.8 and x.11, for example 19.2, 19.5, 19.8 and 19.11. GitLab ships a minor release monthly on the third Thursday and backports security fixes to the previous two monthly releases. A high availability cluster adds more nodes to patch in the right order, so the upgrade runbook matters more. Confirm your staffing for monthly patch review and quarterly planning before you commit.
When should we hire a consultant for a GitLab high availability build?
Consider outside help when your team lacks experience with PostgreSQL failover, Redis, Gitaly storage or Kubernetes, or when downtime would seriously disrupt your workflow and you cannot test failover in-house. GitLab advises high availability only when downtime would critically impact your workflow, and it generally recommends that strategy at 3,000 or more users or around 60 requests per second. Use the decision tree in GitLab's reference architectures documentation to check where you sit. Ask a consultant to name the skills they will transfer to your staff and the documents you will keep.
What does a fixed-scope DeployOpen engagement cover for GitLab?
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, and the scope, deliverables and timelines are agreed in writing before work starts. For a GitLab build, a written scope would normally name the target architecture, the components and environments in it, the backup and restore tests, the upgrade approach, the documentation, and the handover. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope.
Is Geo worth adding to a GitLab deployment?
Only when disaster recovery is a key requirement. GitLab's reference architectures documentation advises using the advanced and complex Geo setup only in that case. Geo adds a secondary site with its own operational work, so it is a separate project from high availability within one site. Confirm with GitLab whether your tier includes Geo and what your recovery point and recovery time targets require. Also decide whether your regulators or contracts need data in a second location, since that answer may matter more than the technical design.
Operating risks that decide the architecture
The choice between a standalone GitLab and a high availability reference architecture is rarely decided by features. It is decided by whether your team can restore, fail over, upgrade and patch the components you add. The cards below name the conditions under which each operating risk becomes the deciding factor.
Untested backup and restore
A standalone instance depends entirely on backups, so a backup that has never been restored is an assumption, not a recovery plan. Check that your backup job covers the database, Git repositories, uploads and object storage, and that someone has restored a full copy into a separate environment and timed it. This risk matters most when your recovery objective is measured in hours and the restore has never been rehearsed. Confirm the procedure in the backup and restore documentation against your own storage layout before you rely on it.
Gitaly and PostgreSQL failover
High availability adds moving parts: Gitaly Cluster with Praefect, PostgreSQL managed with Patroni, Redis Sentinel and Consul. Each one needs its own failover test, monitoring and recovery runbook, and a failure in one layer can leave the others in a state that is harder to diagnose. The risk is highest when the team has not run these components before. Ask whether your team can perform a planned failover and a forced failover on a non-production copy, and who is on call for each layer.
Kubernetes skills gaps
The Cloud Native Hybrid and Cloud Native architectures move stateless components such as Webservice and Sidekiq into Kubernetes, and GitLab's guidance keeps PostgreSQL and Redis outside it. Your team therefore needs cluster operations skills and VM operations skills at the same time. If the Kubernetes skills sit with one or two people, a cluster upgrade or node failure becomes a single point of failure of its own. Check who patches the control plane and how the cluster is backed up before you commit to this layout.
Required upgrade stops
GitLab requires upgrades to pass through required upgrade stops. Since GitLab 17.5 these fall at versions x.2, x.5, x.8 and x.11, for example 19.2, 19.5, 19.8 and 19.11. A high availability deployment has more nodes to upgrade in the right order, so the upgrade window grows with the component count. Plan the path against the upgrade paths documentation for your current version, and schedule a staging upgrade before each production one.
Air-gapped operating constraints
If the instance runs in an offline or air-gapped network, every package, container image, security scanner update and dependency must be moved in by an approved process. GitLab documents offline guidance separately for security scanners and GitLab Duo Self-Hosted, so those features may need their own transfer routine. High availability multiplies these transfers across more nodes. Ask your vendor and your security team to confirm which components you need offline and how often updates are approved.
Growth past the threshold
GitLab's reference architectures suggest a standalone approach for environments serving 2,000 or fewer users, and generally recommend high availability for 3,000 or more users or 60 requests per second. Growth can cross that line during a merger, a CI expansion or a shift of teams onto the platform. A standalone instance sized for today is then operated outside its design range. Track user counts and API request rates each quarter, and decide before the threshold is crossed rather than during an outage.
How to move from standalone to HA without a rebuild
The migration decision starts with two numbers and one business question. Count the users who will sign in, and measure the API load in requests per second, then compare both against GitLab's thresholds. GitLab's reference architectures documentation says environments serving 2,000 or fewer users should generally follow a standalone approach, and it generally recommends an HA strategy for 3,000 or more users, with its decision tree using 60 RPS or 3,000 users as the threshold. Between those points, the business cost of an outage decides the question. Ask the teams that depend on GitLab how long a stopped pipeline, a blocked release or an unreachable repository would hurt, and write that answer down. GitLab advises HA only when downtime would critically impact your workflow, so a headcount alone does not justify the extra components.
Decide early whether to size for HA from the start. Growth is easy to underestimate, and a standalone instance that is later pushed past the thresholds will need the same planning work under pressure. If you already expect growth into the multi-node range, choose the target architecture first, then confirm that the chosen layout fits your hosting model. Keep in mind that the Cloud Native Hybrid and Cloud Native architectures place stateful services such as PostgreSQL, Redis and object storage on virtual machines or managed services, so those dependencies must exist before the GitLab change begins. Confirm which components your team can operate, including Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul for HA layouts, and whether your own staff or DeployOpen will run them.
Treat the move between architectures as a planned change, not a quick reconfiguration. Before any work starts, scope it in writing: the source and target architectures, the backup and restore test that proves a rollback path, the upgrade route that respects GitLab's required upgrade stops, the maintenance window, and the acceptance tests for repositories, CI runners and authentication. Check the GitLab upgrade paths documentation for the stops that apply to your current version. Ask for a quote that lists each of these items as a deliverable, because the cost of the move depends on how much data, how many integrations and how many runners must be re-pointed.
How DeployOpen scopes a GitLab deployment decision
The scoping sequence turns user counts, request load and downtime tolerance into a documented architecture choice and a written scope before any installation work begins.
Confirm the user and request baseline
DeployOpen starts by collecting the number of users who will sign in to the instance, including contractors and service accounts that generate API traffic, along with current or projected API requests per second from existing tooling, runners and integrations. The client's engineering or platform lead supplies these figures, and DeployOpen records them with the source and date of each measurement. The step is complete when the team agrees on one user count and one peak RPS figure, and notes where either value is an estimate that should be validated. The GitLab reference architectures documentation uses 2,000 users as the upper bound for its standalone guidance and 3,000 users or 60 RPS as the point where it generally recommends HA, so these numbers decide which branch applies.
Map current tooling and Git workloads
Next, DeployOpen inventories what the instance must serve beyond web access: repositories and their sizes, CI pipelines and runner fleets, container registry use, webhook-heavy integrations, and any planned Geo or offline requirements. The client's DevOps owners provide the list, and DeployOpen checks it against the reference architecture sizing so that load from CI and automation is not left out of the user count. The step closes with a written workload summary that the architecture decision can cite.
Classify the downtime impact
DeployOpen asks the business owners what an outage of the GitLab instance would stop: releases, production hotfixes, customer-facing deployments or only routine development. Each answer is recorded with the teams affected and the workflows that would halt. GitLab's guidance recommends high availability only when downtime would critically impact the workflow, so this step separates a tolerable maintenance window from a critical dependency. The output is a short impact statement signed off by the accountable owner, which becomes the reason for or against HA in the scope document.
Assess recovery and disaster recovery requirements
DeployOpen reviews the recovery objectives the client has set and the backup approach already in place for the instance. Standalone deployments rely on backups for recovery, so the team checks whether backup frequency, storage location, restore testing and the restore process the client can run are documented. If disaster recovery is a stated requirement, DeployOpen notes that GitLab advises the advanced and complex Geo setup only in that case. The step ends with a recovery requirement statement and a list of gaps, each assigned to an owner.
Choose the architecture and deployment method
With the baseline, impact and recovery findings in hand, DeployOpen selects the candidate architecture: a standalone instance backed by tested backups, a Linux package reference architecture, a Cloud Native Hybrid design with stateless components on Kubernetes and stateful services on virtual machines or managed services, or a Cloud Native architecture. For HA designs, the team confirms which stateful components the client will run and where, since GitLab states that PostgreSQL and Redis inside Kubernetes are not supported. The client's platform team reviews the choice against its Kubernetes skills and hosting footprint, including whether the environment must run offline. The output is a documented architecture decision record that names the reference architecture and the reasons for it.
Validate integrations, identity and licensing
DeployOpen checks the chosen design against the features the client needs, such as SSO and group sync, which depend on the GitLab edition and subscription tier, and against the external services the architecture requires. The client confirms its licensing position with GitLab and the subscription tier it will hold, since the GitLab pricing page lists different features for Free, Premium and Ultimate for self-managed installations. The team also confirms the upgrade plan against GitLab's required upgrade stops. The step is complete when open items are listed with owners and the licensing position is written down.
Agree deliverables and scope in writing
DeployOpen converts the decision into a fixed-scope proposal that lists the architecture, components, integrations, backup and restore testing, hardening, documentation and handover items, along with the responsibilities of each party. Pricing follows from this written scope, and no work starts until the client signs off on the scope, deliverables and timeline. The client should ask the quote to separate one-time implementation work from any ongoing support or upgrade retainer. The step is complete when both parties have signed the scope document and the architecture decision record is attached to it.
How DeployOpen plans, builds and supports self-hosted GitLab
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so the GitLab topology is chosen against your user count, downtime tolerance and disaster recovery needs. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Count named users, peak API requests per second and the hours downtime would disrupt your teams.
- Record where GitLab would run: your cloud accounts, data centers or air-gapped network.
- Agree in writing whether a standalone instance with backups or an HA reference architecture is in scope.
How we build
- Install the chosen GitLab method, such as the Linux package or Helm chart, inside your environment.
- Configure external PostgreSQL, Redis, object storage and Gitaly layout only where the chosen architecture requires them.
- Test backup and restore, failover and upgrade paths before any user goes live.
How we hand over
- Document the topology, sizing assumptions, backup schedule and recovery steps for your operations team.
- Walk your administrators through required upgrade stops and the maintenance cadence they must plan for.
- Deliver configuration and evidence in a form your auditors or assessors can review independently.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Re-check sizing when user counts, CI volume or compliance requirements change.
- Confirm with your team which GitLab tier and features your scope needs before any licensing decision.
