What a GitLab implementation involves
A self-managed GitLab implementation covers six areas: sizing and architecture, installation, identity, runners, backups and handover. Each one carries decisions that shape the rest of the project, so the scope should be written down before any server is provisioned. Sizing comes first. GitLab publishes reference architectures from 1,000 users up to 50,000 users, and the user count, expected API load and whether you need high availability determine which one applies. Installation method, such as the Linux package, the Helm chart or the GitLab Operator, follows from that choice.
Organizations usually scope this work for one of three reasons: they are moving source control off a hosted service, they are consolidating several CI/CD systems into one, or they must meet data residency or air-gap requirements. Each trigger changes the plan. A residency requirement, for example, usually pushes runners, storage and backups into the same controlled environment as the instance itself, and an air-gap requirement adds offline package transfer and a separate patching route.
On the question of in-house versus partner: a team with Linux and GitLab administration skills can perform the installation itself. Partners are most often brought in for the decisions that are hard to reverse, namely sizing, architecture, the sequence of migration waves and a documented handover that lets your own administrators run the instance after go-live. Ask any partner to show how they will test restores and how the runbook will be handed over, not only how the install will be done.
The tier you choose also changes the scope. GitLab Free, Premium and Ultimate are all available for self-managed installations, and the features each tier adds, such as advanced CI/CD and priority support in Premium or security testing and compliance features in Ultimate, bring their own configuration, integration and testing work. Confirm the tier against current pricing and feature pages before you finalize the architecture, because a feature you assumed was included may need a different tier, and Geo disaster recovery is only offered in Premium and Ultimate.
What the work includes and what you receive
A fixed-scope GitLab project is divided into work packages, each ending in a deliverable you keep. The exact list, depth and acceptance criteria are set in the written scope before work starts.
Requirements and sizing record
We record user counts, concurrent activity, repository sizes, CI job volume and availability targets, then map them to a GitLab reference architecture. You keep a sizing record that shows the chosen architecture, the assumptions behind it and the triggers that would call for a review. Ask the team to confirm how peak load is estimated.
Installation method decision
The Linux package, the Helm chart, the GitLab Operator and other methods carry different operating models for upgrades, backups and scaling. This work package documents the choice against your platform team's skills and hosting, and you keep a decision record that names the rejected options and why. Confirm which method your support model covers.
Architecture diagram and instance configuration
The architecture diagram shows nodes, load balancers, storage, network zones and external services for your chosen layout. Instance settings are written to configuration files and kept in version control, so changes are reviewed and traceable. Check whether the configuration covers sign-up limits, default visibility and the gitlab.rb settings your security team needs.
Identity connection and access mapping
GitLab can connect to LDAP, SAML, OpenID Connect through OmniAuth and SCIM provisioning, depending on your identity provider and tier. This package delivers a tested sign-in path, group-to-role mapping and a documented fallback for administrator access. Confirm which identity features your chosen tier includes before the scope is signed.
Runner setup and capacity notes
Runners execute CI/CD jobs and their executor type, tags and host capacity determine pipeline speed and isolation. You receive configured runners with a documented executor choice, protected variable rules and a version alignment plan that matches the GitLab release in use. Ask what capacity testing is included and who owns runner hosts after handover.
Tested backup and restore runbook
Backups must cover the database, repositories, uploads and the secrets and configuration files that the backup tool does not replace. The deliverable is a backup design, a schedule, and a restore test performed on a separate system with a recorded result. Ask for the restore test report and for the recovery steps to be written as a runbook your team can follow alone.
Monitoring and upgrade plan
Monitoring covers service health, storage growth, job queues and backup job status, with alert routing to your on-call process. The upgrade plan lists the required upgrade stops and the maintenance window steps for each one. Confirm which monitoring tool your team already runs so the handover fits existing operations.
Documentation and admin training
Documentation includes the architecture diagram, runbooks for routine and failure tasks, and the configuration repository guide. Admin training walks your administrators through daily operations, upgrades and restore steps using your own instance. Ask how many sessions are included and whether recordings or written materials are delivered for later reference.
What drives cost and duration
Each row names one factor that moves GitLab implementation effort or cost, why it moves it, and how to keep it contained, so you can compare scope items in a written quote.
| Driver | Why it moves effort | How to keep it down |
|---|---|---|
| User count and API load | Reference architectures run from 1,000 users at 20 API requests per second to 50,000 users at 1,000 requests per second, and each step adds nodes, database capacity and sizing work. | Confirm active users and peak API load with your team before sizing. Right-sizing to the smallest reference architecture that fits avoids paying for capacity you do not use. |
| High availability requirements | The GitLab docs generally recommend a high availability strategy at 3,000 or more users, which adds Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul to build and test. | Decide early whether in-site high availability or a warm standby is required, and scope HA only for services whose outage your business cannot tolerate. |
| Installation method | The Linux package bundles PostgreSQL, Redis and Sidekiq. Helm chart or Operator deployments on Kubernetes need external stateful services, since the reference architectures do not support running PostgreSQL or Redis inside Kubernetes. | Choose the method your platform team already operates. Where Kubernetes is required, confirm the Cloud Native Hybrid layout and the stateful services you will host outside the cluster. |
| Identity providers | Each LDAP, SAML, OAuth 2.0, OmniAuth, Kerberos, JWT, smart card or SCIM source needs configuration, group mapping, testing and ongoing ownership. | Limit the first release to one authoritative identity source and add others as separate, scoped work items. |
| Runner fleet size and executor types | Shell, Docker and autoscaling executors need different images, isolation, cloud or hypervisor capacity and tagging. Runner versions must stay aligned with GitLab. | Start with a small pool for the highest-volume pipelines, standardize images, and define which projects may use which runner tags. |
| Repository, artifact and registry volume | Large repositories, long artifact retention and container registry growth drive Gitaly storage, object storage size, backup duration and restore time. | Set artifact expiry and retention policies early, and agree on which repositories need large-file handling before migration. |
| Migration sources and history depth | GitHub, Bitbucket, Gitea, other GitLab instances, Jira and FogBugz have different import paths. Subversion needs external conversion, and deep history or many projects extend validation and cutover. | Inventory sources, limit history to what teams need, and migrate in waves so each wave has a defined validation step. |
| Tier: Free, Premium or Ultimate | Premium lists advanced CI/CD and priority support at 29 US dollars per user per month billed annually (GitLab pricing page). Ultimate is custom priced and adds security, supply chain and compliance features. Geo is available in Premium and Ultimate. | Match the tier to the features you will use and confirm the current per-user terms and any Geo or Ultimate requirements with GitLab before quoting. |
| Disaster recovery, Geo and air-gapped operation | A Geo secondary site in another region is continuously synchronized and needs its own infrastructure. Air-gapped operation requires offline package transfer, license handling and separate scanner setup. | Define recovery objectives per data class, decide whether Geo is in scope, and confirm offline update and scanner requirements before the design is fixed. |
Project phases and outputs
The sequence moves from agreed requirements to a tested, documented GitLab instance that your administrators can operate after handover.
Confirm requirements and load assumptions
DeployOpen gathers user counts, geographic spread, repository and CI volume, and expected API request rates, then maps them to a GitLab reference architecture. Your team confirms identity sources, data residency and network constraints. The output is a requirements record signed off in writing before design starts.
Select architecture and installation method
The team chooses the reference architecture, the Linux package, Helm chart, or Operator, the storage layout, and whether high availability or a Geo secondary is in scope. Choices are documented with their trade-offs. The output is an architecture decision record and a bill of materials your infrastructure team can review.
Build the non-production environment
DeployOpen installs GitLab, runners, storage and supporting services inside your infrastructure in a non-production environment, applying the agreed configuration as code where possible. Each component is checked against the design. The output is a working staging instance and a build record that lists versions and settings.
Integrate identity and runners
Single sign-on, group mapping, two-factor policy and runner registration are connected and tested with real test accounts and pipelines. Runner executors and tags are validated against your build workloads. The output is a test report showing sign-in, group sync and sample jobs passing in staging.
Run migration waves where applicable
If you are moving repositories, merge requests, issues or pipelines from another system, the migration runs in agreed waves, each checked for completeness and user mapping. Rollback steps are rehearsed for each wave. The output is a wave log with reconciliation results for every migrated group.
Test backup and restore
The team takes a full backup, saves the secrets and configuration files separately, and restores into a clean host to confirm the instance works afterward. The restore time and any manual steps are recorded. The output is a restore test report that your operations team can repeat.
Cut over to production and hand over
DeployOpen runs the production cutover against the agreed plan, verifies users, runners and integrations, and transfers operation to your administrators with admin training and runbooks for upgrades and required upgrade stops. The output is a signed handover record and the documented runbook set.
What teams keep and what they outsource
This table compares GitLab work that an internal team usually keeps with work often outsourced to a partner, and lists the skills each area requires so you can match them against your staff.
| Work area | Usually kept internally | Usually outsourced | Skills required |
|---|---|---|---|
| Repository ownership | Yes: naming, default branch rules, approval rules and archiving decisions | No, unless the rules are being designed for the first time | Git workflow design, GitLab permissions model, code review practice |
| Group and project structure | Yes: day-to-day additions of groups, subgroups and projects | Initial hierarchy design for a large or multi-business-unit instance | GitLab group and namespace model, identity mapping, governance policy |
| Pipeline authoring | Yes: .gitlab-ci.yml changes, templates and team-level CI components | Shared template library, migration of an existing build estate | CI/CD design, YAML authoring, container image management, test tooling |
| User lifecycle | Yes: joiners, movers and leavers handled through the directory | Initial sync design with the directory and role mapping | Directory services (LDAP or Active Directory), SAML or OIDC administration, SCIM |
| Daily administration | Yes: upgrades between required stops, user support, monitoring checks | Ongoing retainer support or upgrade execution when staff are limited | Linux administration, PostgreSQL and object storage operations, log review |
| Architecture sizing | Review and sign-off of the proposed design | Yes: mapping user count and API load to a reference architecture | Capacity planning, load estimation, familiarity with GitLab reference architectures |
| Initial install and hardening | Acceptance testing and ownership of the resulting configuration | Yes: Linux package or Helm install, gitlab.rb settings, OS hardening | Linux administration, TLS and certificate handling, configuration management |
| High availability or Geo design | Operating the cluster after handover | Yes: Gitaly Cluster, Patroni, Redis Sentinel, Consul or a Geo secondary design | PostgreSQL replication, storage clustering, networking, failover testing |
| Identity integration | Directory accounts, group membership and access approvals | Yes: LDAP, SAML or OIDC configuration and attribute mapping | Directory services, SAML or OIDC, Kerberos where required, identity governance |
| Backup and restore validation | Scheduled restore tests and recovery exercises | Yes: backup design for secrets, configuration, database and object storage, and first restore test | PostgreSQL backup tooling, object storage lifecycle, secrets handling, recovery runbooks |
| Runner fleet design | Adding runners for new teams and monitoring job queues | Yes: executor choice, autoscaling, image hardening and tagging model | Docker or Kubernetes operations, cloud or hypervisor autoscaling, CI/CD design |
What usually goes wrong
Most GitLab implementation problems are visible in the plan before any server is built. The points below are the ones to settle in scope, with a prevention step for each.
Undersizing against the reference architecture
Teams often size the instance for today's headcount and find out late that the reference architecture for their user count and API request rate needs more nodes, storage or database capacity. Confirm the target user count, peak API load and growth assumptions in writing, then pick the reference architecture before the infrastructure order is placed.
Stateful services inside Kubernetes
Running PostgreSQL and Redis inside the cluster is a common shortcut when the team already runs Kubernetes. The GitLab reference architecture documentation says this is not supported. Decide early whether stateful services run on VMs or managed services, and use the Cloud Native Hybrid layout if Kubernetes is required for the stateless components.
Backups without a restore test
A backup job that reports success does not prove the instance can be rebuilt. Schedule a restore into a separate environment, time it, and record which steps needed manual work. The scope should name who runs the test, how often it runs and what evidence is kept.
Secrets and configuration left out of backups
The gitlab-backup tool does not capture everything needed to restore an instance. Secrets files and configuration such as gitlab.rb must be saved separately, and without them encrypted data and integrations may not work after a rebuild. Add secrets and configuration to the backup runbook and check them during each restore test.
Runner versions drifting from GitLab
Runners are updated on their own schedule, so they fall behind the GitLab version and jobs fail in ways that look unrelated. The Runner documentation advises keeping major and minor versions aligned with GitLab. Put Runner upgrades in the same change calendar as GitLab upgrades and assign an owner for the runner fleet.
Skipping required upgrade stops
GitLab requires upgrades to pass through required stops, which since GitLab 17.5 fall at x.2, x.5, x.8 and x.11. Jumping past one blocks the upgrade and can require a restore. The plan should map the current version to the target path, confirm the stops in the upgrade paths documentation, and schedule a test upgrade on a copy first.
Hardening applied all at once
Applying every hardening setting in one change makes it hard to tell which one broke a login, a pipeline or an integration. GitLab's hardening guidance is a work in progress and recommends gradual rollout. Stage the changes by area, such as sign-up and two-factor settings first, then runner isolation, and record the result of each step.
Unclear ownership after handover
After go-live, questions about who applies patches, restores backups, manages runners and approves access changes often have no answer. The scope should name owners for each of these tasks, state which ones the partner supports under a retainer and which stay with the internal team, and set a review date for the runbook.
How the work changes by starting point
A new self-managed install for a small or mid-size team is usually the smallest scope. The main decisions are the reference architecture that matches your user count, the Linux package versus Kubernetes deployment method, and the tier you need.
- Sizing: Confirm the user count and API load against the reference architectures before choosing a single-node or multi-node layout.
- Deployment method: The Linux package is the most mature method and is usually the simpler path for a first install.
- Runners and storage: Plan runner capacity and object storage for artifacts and backups as separate line items.
- Identity: Decide whether sign-in uses local accounts for the first phase or your existing directory from the start.
- Backups: Set a restore test as an acceptance step, not an afterthought.
For edition choices, see the cost of ownership and editions topic. For the install itself, see the GitLab upgrades and support and runner setup topics for the operating detail.
Consolidating several GitLab instances or moving from a hosted service adds data movement and cutover work on top of the install. The effort depends on how much history, membership and automation you need to carry across.
- Source inventory: List every instance or hosted workspace, including groups, projects, users, runners and integrations.
- Version gap: If sources run older versions, confirm the required upgrade stops before any import or transfer.
- Import method: Choose between the built-in importers, direct transfer between GitLab instances and file exports, based on what must survive.
- Identity mapping: Plan how users and contributions map to accounts on the target instance.
- Cutover: Agree a staged cutover with freeze windows and a rollback point for each source.
For transfer mechanics, see the migration topic. For version paths, see the upgrades topic.
An install on Kubernetes using the Cloud Native Hybrid layout runs stateless components in the cluster and keeps stateful services outside it. That split is set by GitLab's reference architecture guidance, which does not support stateful components such as PostgreSQL and Redis inside Kubernetes.
- Stateful services: Decide whether PostgreSQL, Redis, and Gitaly run on VMs you operate or on managed services, and cost each one separately.
- Cluster ownership: Confirm who operates the Kubernetes cluster, its upgrades and its ingress before the GitLab work starts.
- Chart or Operator: Choose the Helm chart or the GitLab Operator and confirm the chart version matches the target GitLab release.
- Storage classes: Validate persistent volume behavior for any component that remains in the cluster.
- Runbooks: Write separate runbooks for cluster changes and for the external stateful services.
For the deployment method, see the Kubernetes Helm chart or Operator topic. For high availability layouts that include Cloud Native Hybrid, see the high availability topic.
An air-gapped environment changes how software reaches the instance. Offline packages, container images and security scanner data must be transferred in, verified and applied without internet access, and every update repeats that transfer.
- Transfer process: Define how packages, images and scanner content are approved, copied across the boundary and checked.
- Scanner data: Plan how vulnerability and scanner content is refreshed offline, since it does not update on its own.
- Patch cadence: Map the patch and minor release schedule against your change window, since each cycle requires a new transfer.
- Licensing: Confirm how license activation works without outbound connectivity.
- Duo Self-Hosted: If AI features are in scope, confirm the offline guidance for that component separately.
For the offline procedure, see the air-gapped installation topic. For ongoing patching, see the upgrades and support topic.
A regulated environment needs evidence that hardening and access controls are in place and stay that way. The build is similar to the other starting points, but the work includes documenting configuration, controls and test results for assessors.
- Control mapping: Map the NIST SP 800-53 oriented hardening guidance to your own control set and record which settings you applied.
- Access controls: Define sign-up limits, two-factor enforcement, group roles and token policies, and keep the configuration under change control.
- Audit evidence: Decide which audit events are retained, where they are stored and how long they are kept.
- Runner isolation: Document how runners and protected variables separate environments.
- Assessor scope: DeployOpen prepares systems, controls and evidence. Independent auditors and certification bodies issue any attestation.
For the control settings, see the security hardening topic. For identity controls, see the SSO and identity topic.
What you need to provide
Gaps in the inputs below are the most common reason a GitLab scope changes after kickoff, so collect them before a fixed-scope quote is written. Name one accountable owner each for the instance, the identity integration, and the CI/CD runners. Each owner should be able to approve configuration decisions without waiting for a committee.
Give the team user and group counts, split into active and licensed users, and estimate typical and peak API request rates. The reference architecture is chosen from these numbers, and the difference between a small single-node build and a highly available layout is often driven by load rather than headcount. Also provide repository, package, container registry and CI artifact volumes, with the expected growth over the first year. Large Git histories and artifact stores change backup duration and storage design.
List the tools and sources the instance must connect to or migrate from, including GitHub, Bitbucket, Gitea, other GitLab instances, Jira, chat, and any Subversion repositories that will need external conversion. For hosting, decide between virtual machines, Kubernetes, and object storage, and state which network zones, load balancers, DNS names and certificate authorities are available. Confirm whether the environment is air-gapped, since offline installation changes the package transfer and scanner plan.
Set backup retention periods and recovery objectives with the business owners, not with the engineering team alone. Decide the tier (Free, Premium or Ultimate), whether Geo is required, and whether high availability is needed now or later. Finally, secure access to the target environments, the identity provider administrators who will register SAML or OIDC applications, and the change approval board that signs off production windows. Without these approvals in place, the schedule is usually the first item to slip.
Questions buyers ask before hiring help
Can our own team install and run self-managed GitLab without a partner?
Yes, many teams do, and the decision depends on capacity and experience rather than on whether GitLab is possible to install. Your team needs Linux administration, PostgreSQL and object storage skills, network and DNS work, backup and restore practice, and someone who can own upgrades. GitLab documents several installation methods, and the Linux package is the most mature one, so the question is whether your staff can run it for years, not just stand it up once. A partner is most useful when the scope includes identity integration, runner design, migration and a planned upgrade path that your team has not yet operated.
What does a fixed-scope GitLab implementation cost and what does it depend on?
A fixed-scope project has three cost components. The first is the fixed fee for the deliverables agreed in writing, such as architecture, installation, identity, runners, backups and handover. The second is the GitLab subscription, which is zero for the Free tier and applies only if you choose a paid tier. The third is the infrastructure you pay your cloud or data center provider for, including compute, storage, load balancing and backup capacity. Your user count, the reference architecture that matches it, the number of runners, your identity sources, and whether you need high availability or Geo move each component up or down.
Is the Premium price of 29 US dollars per user per month the only option?
No. GitLab Free costs nothing and is available for self-managed installations. GitLab Premium is listed at 29 US dollars per user per month billed annually, and it adds advanced CI/CD and priority support. GitLab Ultimate is custom priced and adds application security testing, software supply chain security, vulnerability management and compliance features. All three tiers can run on your own infrastructure. Confirm current terms with GitLab before budgeting, since subscription terms are set by the vendor and are separate from any DeployOpen fee.
How long does a GitLab implementation take?
The duration depends on the drivers of the work, not on a standard length. The main ones are the number of users and the reference architecture they require, whether you need high availability for 3,000 or more users, how many identity providers and group mappings must be integrated, the number and type of runners, the volume and kind of repositories to migrate, and how many approval cycles your security and change teams require. A fixed-scope proposal should state the schedule against these drivers and the milestones in writing. Ask for that breakdown rather than a single number.
What do we need to provide before a quote can be prepared?
A quote follows the written scope, so DeployOpen cannot give a firm price from a rough description. Prepare the user count and expected growth, the locations and network zones where GitLab will run, the cloud or data center platform and its existing services, the identity provider and group structure, the runner workloads and target platforms, the backup and retention requirements, and any compliance or air-gap constraints. Also confirm which GitLab tier you intend to buy, because it affects both the subscription line and the features in scope.
Which technical choices most affect the effort and running cost?
Four choices drive most of the effort. The Linux package is the most mature installation method and is usually simpler to operate than Kubernetes, while the Helm chart or Operator suits teams already running Kubernetes, and stateful components such as PostgreSQL and Redis are not supported inside Kubernetes under the reference architectures. Single-node or small multi-node layouts cost less than high availability designs with Gitaly Cluster, Patroni and Redis Sentinel. Runner design, including autoscaling capacity, adds recurring compute cost. Finally, backups of secrets and configuration files, plus restore testing, add recurring operational work that should be sized into the plan.
How DeployOpen scopes and delivers GitLab projects
DeployOpen plans, implements, hardens, documents and supports self-managed GitLab inside your own cloud accounts, data centers or air-gapped networks. The work starts with a written scope that ties user count, reference architecture, runners, identity and backups to a fixed set of deliverables.
How we scope
- Confirm user count, peak API load and growth so the reference architecture choice is grounded in your numbers.
- Decide Linux package, Helm chart or Operator, and document why that method fits your operations team.
- Record tier needs, runner types, storage locations, identity sources and backup targets in the written scope before work starts.
How we build
- Install and configure the instance, runners, storage and identity connections in the environments you own.
- Test backup and restore, upgrade paths and runner behavior against the agreed scope before handover.
- Apply hardening settings in stages, recording each change so your team can audit and reproduce the configuration.
How we hand over
- Deliver architecture diagrams, configuration records, runbooks and the upgrade stop plan for your team to keep.
- Walk your administrators through backup, restore, runner registration and routine maintenance tasks.
- Document open items and decisions so any later changes can be traced to the original written scope.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, agreed separately from the project.
- Plan monthly minor releases and required upgrade stops with your change calendar in mind.
- Ask any partner for written terms covering response expectations, included upgrades and what the retainer excludes.
