GitLab for SaaS and technology companies

SaaS and technology companies self-manage GitLab to keep change evidence for SOC 2, control runner spend, hold data in chosen regions and grow from one node to reference architectures.

Book a callTalk to us
On this page

Why SaaS companies self-manage GitLab for SaaS delivery

Self-managed GitLab fits SaaS and technology companies because it puts source control, code review, pipelines and deployment approvals inside infrastructure the company controls, and gives the security team one place to produce change evidence. Consider an engineering leader whose product team has doubled, whose customer security questionnaires now ask how code reaches production, and whose SOC 2 scope has added change management. The GitLab instance becomes the system of record for those changes, so it is no longer just a developer tool. Merge request approvals, protected branches, pipeline results and deployment approvals all become evidence that an auditor may sample, and the instance itself falls inside the system description.

That shift changes the design work. Before the audit window opens, confirm which GitLab tier your team needs, because approval rules, compliance features and audit reporting differ by edition. Also review the licensing split: content under the ee/ directory is covered by the GitLab Enterprise Edition license, while content outside it is available under the MIT Expat license. The gitlab-org/gitlab LICENSE file sets out that split, and your legal team should confirm how it applies to the edition and features you deploy.

Plan the instance as a controlled system from the start. Decide who can change protected branch settings and approval rules, record who administers the instance, and keep the configuration under version control so changes to it are reviewable too. Ask your auditor early which GitLab logs and settings they expect to sample, because the answer determines retention and access design. The SOC 2 criteria themselves are a question for your auditor and your own control design, not something this platform certifies on its own.

Requirements SaaS companies bring to a GitLab build

This table lists the audit and regulatory requirements that most often shape a self-managed GitLab build for SaaS and technology companies. Each row gives the source fact, what it means for GitLab configuration and what to confirm with your auditor or counsel. Applicability depends on your product, customers and jurisdictions, so use the table as a scoping starting point.

RequirementSource factGitLab configuration impactConfirm with auditor or counsel
SOC 2 CC8 change managementCC8 is the change management criterion in the SOC 2 common criteria, which apply to every SOC 2 report.Merge requests, approval rules, protected branches and audit events become change evidence. Gate deployments on pipeline results.Which changes need approval, how emergency changes are handled, and which audit events the auditor will sample.
SOC 2 scope and report typeA Type 1 report covers control design at a date. A Type 2 report adds an opinion on operating effectiveness over a period.Define the GitLab instance, runners, backup store and identity provider as in-scope systems. Keep logs for the full observation period.Whether Type 1 or Type 2 is needed, the observation period, and how the report will be restricted for use.
GDPR Article 28(3) processor instructionsProcessors must act only on documented instructions, including for transfers, and apply Article 32 security measures.If customer personal data appears in repositories, issues or job logs, document access, retention and transfer instructions for GitLab and CI vendors.Whether you act as controller or processor, which subprocessors are in your pipelines, and what the data processing agreement must state.
EU Data Act switching rightsSince 12 September 2025, data processing providers must allow switching to another provider or on-premises infrastructure. Switching charges end on 12 January 2027.Test exports of repositories, issues, merge requests and pipeline configuration. Keep runner and pipeline settings in version control.Whether your product is a data processing service under the Act, and what notice period and switching terms your contracts state.
NIS2 for cloud and managed providersNIS2 Annex I treats cloud computing, data center, content delivery, managed service and managed security providers as high-criticality sectors.If in scope, access control, logging, backups and change records in GitLab feed the risk management measures expected of providers.Whether your services fall in scope under national transposition, and which measures in Implementing Regulation 2024/2690 apply to you.
Cyber Resilience Act for software productsThe CRA applies to products with digital elements, including software, from 11 December 2027. Article 14 reporting applies from 11 September 2026.Build pipelines can generate SBOMs and vulnerability scan results. Track vulnerability handling and reporting steps in GitLab issues and approvals.Product classification, whether self-assessment under module A applies, and the reporting steps for products you place on the EU market.

Which GitLab modules and settings matter for a SaaS build

Change evidence is the part of a GitLab build that auditors and customers read most often. A SOC 2 examination looks at whether changes to the system are authorized, reviewed and tested, so the settings that enforce those steps belong in the design from the start. Protected branches, merge request approval rules and pipeline requirements are configured in the project or group, and they determine what evidence the instance can produce later.

  • Protected branches: Restrict who can push to production branches and who can merge, so direct commits to release branches are blocked.
  • Merge request approvals: Define how many approvers are required and which groups must approve changes to sensitive paths.
  • Required pipelines: Make passing CI jobs a condition for merging so test and scan results are linked to each change.
  • Ultimate compliance features: Compliance frameworks, audit events and security policy enforcement are listed on the pricing page under Ultimate, so confirm the exact feature set there before the quote.
  • Audit events: Confirm which audit events your tier records and how long they are retained in your own storage.

Before the quote, ask which change controls you need to demonstrate and map each one to a setting and a tier.

How the instance grows from one node to a reference architecture

This sequence moves a SaaS engineering organization from a single-node GitLab to a sized reference architecture by measuring user count, API load and CI volume first, so each scaling step is driven by evidence rather than guesswork. The output is a documented sizing decision and a staged growth path that the team can revisit as load changes.

  1. Baseline current users, API load and CI volume

    Engineering leadership and the platform team collect the current number of active users, the sustained API request rate and the number of CI jobs per day, including peak hours. Use the instance's own logs, Prometheus metrics and pipeline history rather than estimates, and record the figures with the date they were captured. The step is done when the team can state three numbers with a measurement method they can repeat. Confirm the metric names and exposure settings for your version in the monitoring documentation before you rely on them.

  2. Match the load to a reference architecture size

    The platform team compares the baseline with GitLab's published reference architectures, which range from 1,000 users at 20 API requests per second to 50,000 users at 1,000 API requests per second. Pick the stage where user count and API load both fit, and check CI concurrency separately, because heavy pipeline traffic can push a team toward a larger stage even when user count is modest. The output is a written sizing decision that names the stage, the measured inputs behind it and the date it should be reviewed. Ask your GitLab representative or DeployOpen to confirm the current stage definitions against the version you plan to run.

  3. Decide when high availability is required

    GitLab recommends a high availability strategy for 3,000 or more users. At that point the design usually moves from a single node to several components that tolerate failure, including Gitaly Cluster with Praefect for repository storage, PostgreSQL with Patroni, Redis Sentinel and Consul for coordination. The platform lead decides whether the business can accept a single-node outage window or whether repository hosting, CI and the database must survive a node loss. The output is a recorded decision on availability targets, with the reasoning tied to the user count from the previous step. Teams below that threshold should still document their recovery approach, since the backup and restore procedure becomes their main protection.

  4. Place stateful services outside Kubernetes

    If the organization runs GitLab alongside a Kubernetes platform, the architect confirms early that PostgreSQL and Redis will not run inside the cluster, because GitLab's reference architectures do not support stateful components there. The Cloud Native Hybrid architecture is the documented pattern: stateless components run on Kubernetes, while stateful services run on virtual machines or managed services. The output is a component placement table listing each service, its host type and its owner. Review the placement with the team that operates the cluster, since it affects node pools, storage classes and database backup ownership.

  5. Build the target environment and install in stages

    The platform team provisions the chosen topology in the infrastructure the organization controls, then installs GitLab using a supported method such as the Linux package, which bundles PostgreSQL, Redis and Sidekiq and is the most mature option for scaling. Components are added in the order the reference architecture describes, with each tier tested before the next one receives traffic. The step is complete when every component reports healthy, a test project can be cloned, pushed and built, and failover behavior has been exercised for the highly available parts. Keep the installed version and component versions recorded, since Runner and GitLab versions should stay aligned.

  6. Migrate workloads and validate capacity

    Engineering moves repositories, pipelines and CI runners onto the new topology in waves, starting with teams that have moderate load so problems surface early. The platform team watches API latency, Gitaly and database performance, queue depth and runner wait times against the targets set in the sizing decision. Validation is complete when the measured load stays within the chosen stage for a representative period, and the team can show where the headroom ends. Record any tuning changes so the next sizing review starts from an accurate baseline.

  7. Review sizing on a fixed cadence

    The platform owner repeats the baseline measurements on a set schedule and compares them with the stage in use, paying attention to user growth, new CI workloads and larger monorepos. When measured load moves toward the limit of the current stage, the owner schedules a change to the next stage before performance degrades, and the change goes through the same staged install and validation. The output is a short sizing review record each cycle, which also feeds capacity conversations with finance and leadership. Confirm the review interval with your operations team, since it depends on how fast your engineering headcount is growing.

What drives runner cost and how to keep it under control

Runner spend for a SaaS engineering team is less about the GitLab license and more about how many jobs run, how long they take and how much capacity sits idle between them. The cards below separate the decisions that shape that spend so you can ask a partner to quantify each one against your own pipeline history.

Choosing the autoscaling executor

The executor decides where each job runs and who pays for the machine it runs on. Docker Autoscaler provisions cloud virtual machines on demand, so you pay the cloud provider for instance hours. The Kubernetes executor schedules job pods onto a cluster you already run, so cost moves to node capacity and cluster overhead. Ask a partner to model both against your peak concurrent job count and the share of jobs that need Docker-in-Docker or privileged containers, since those constrain the choice.

Sizing cloud VMs for Docker Autoscaler

Instance type and size set the cost of every job minute. Oversized machines waste money on light jobs, while undersized machines lengthen builds and hold runners busy longer. Pick instance families by the workload profile, such as compile-heavy, test-heavy or container-build-heavy pipelines, and measure CPU, memory and disk use per job before fixing a size. Ask the partner to show the idle-to-busy ratio per instance type and the cloud pricing model you will commit to, because that changes the effective rate.

Limiting idle capacity

Autoscaling only saves money if machines are removed when the queue empties. Idle capacity comes from minimum instance counts kept warm for fast job start, from idle timeouts set too long, and from runners pinned to a project that no longer needs them. Review the idle timeout and the maximum instance count together, because a high ceiling with a long timeout can produce a large bill during a single burst. Ask the partner to report queue wait time alongside idle minutes so the trade-off is visible.

Reducing job duration and cache storage

Every minute a job runs is billed at the rate of the machine it runs on, and cache and artifact storage grows with branches and retention settings. Long dependency installs, uncached container layers and oversized artifacts often cost more than the runners themselves. Review pipeline stages for redundant work, set cache keys deliberately, and set artifact expiry so old build outputs do not accumulate. Ask a partner for a breakdown of compute minutes versus storage and egress for the last quarter.

Separating runner cost from job design

Some spend comes from pipeline design choices that no runner setting will fix, such as running full test suites on every commit, rebuilding unchanged services or duplicating jobs across branches. Split the cost view by project and pipeline so engineering leads can see which teams drive compute usage. Ask the partner to identify the top pipelines by compute minutes and propose changes, such as rules that limit expensive jobs to merge requests or main branches.

Keeping Runner aligned with GitLab

Runner cost control depends on a stable fleet, and version drift causes failed jobs, retries and manual firefighting that consume engineering time. The Runner documentation advises keeping Runner major and minor versions aligned with GitLab, so plan a Runner upgrade alongside every GitLab upgrade. Ask the partner to include the Runner version in the upgrade plan, the test pipeline used to verify it and a rollback path for the autoscaling fleet.

Keeping GitLab current without breaking change evidence

How often does GitLab release new versions?

GitLab ships a minor release on the third Thursday of each month and patch releases twice a month, with a major release once a year. The major release for 20.0 is planned for May 2027. For a SaaS team, this cadence means the upgrade plan is a recurring activity, not a one-time project. Each cycle should produce a change record that names the target version, the reason for the change and the approver. Confirm the current schedule on the GitLab maintenance policy before you set your internal calendar.

Which GitLab versions receive bug fixes and security fixes?

Bug fixes are backported only to the current stable release. Security fixes are backported to the previous two monthly releases as well. GitLab currently maintains 19.5, 19.4 and 19.3, according to the maintenance policy. The practical result is that staying on an older monthly release gets security fixes for a limited window, and bug fixes not at all. Your change process should treat a security patch as a time-bound change with its own approval path, separate from feature upgrades that can wait for the next scheduled window.

What are GitLab required upgrade stops?

Required upgrade stops are versions your instance must pass through before moving to a later release. Since GitLab 17.5, they fall at x.2, x.5, x.8 and x.11. Examples from the upgrade paths documentation include 18.2, 18.5, 18.8, 18.11 and 19.2, 19.5, 19.8 and 19.11. A jump from one stop to the next is allowed, but skipping a stop is not. Plan your path against the official upgrade paths page for your current version, and confirm each stop in the target environment before scheduling production work.

Why should the GitLab upgrade plan sit inside the change-management record?

Auditors reviewing a SOC 2 Type 2 examination test whether changes to systems in scope were authorized, tested and approved, and a self-managed GitLab instance often holds that evidence. If upgrades happen outside the change record, the version history of the tool that enforces your controls has gaps. Record each upgrade as a change with a pre-upgrade backup reference, the stop-by-stop path, test results, rollback criteria and the post-upgrade verification. This keeps the control evidence consistent with the period the auditor samples. Confirm with your auditor how they want upgrade changes documented.

How should a SaaS team test an upgrade before production?

Test on a copy of production that is built from a recent backup, so the schema, repositories and CI configuration match what the upgrade will touch. Run the required stops in order, then check sign-in, repository access, merge requests, pipelines and runner registration. Keep runners aligned with GitLab's major and minor versions, as the Runner documentation advises, and include them in the test. Record the results against the change ticket. The effort depends on instance size, the number of custom integrations and the number of stops between your current version and the target.

What should a rollback plan for a GitLab upgrade contain?

A rollback plan should state the exact backup used, the restore procedure, the decision point after which rollback is no longer practical, and who makes that call. Confirm that backups include the secrets file, which the backup and restore documentation treats separately from the data. Also agree on how long user-facing downtime is acceptable and how the team will communicate it. Write the plan into the change record before the window opens, so the reviewer can see that rollback was considered in advance rather than improvised during an incident.

Who should own GitLab upgrades in a SaaS company?

Ownership usually sits with the platform or developer tooling team, with security and change management as approvers. The platform team plans the path, runs the test and executes the window. Security reviews patch urgency against the backport rules. The change manager confirms that evidence is complete. Engineering leads are informed because pipelines and integrations may change. Decide this before the first upgrade so that a missed patch window does not become an unowned risk. Ask any outside partner to document this split in the written scope.

Can a SaaS team handle GitLab upgrades without outside help?

Many teams can, provided they have a staging environment, a tested backup and restore routine, and time in the schedule for monthly and patch work. The harder parts are keeping up with the twice-monthly patch cadence, reading each required stop and maintaining evidence for each change. A fixed-scope engagement can cover the initial path, the test environment and the runbook, while a retainer can cover the recurring cycle. DeployOpen prepares the systems, documentation and evidence, but does not issue audit reports or attestations.

Compliance evidence SaaS teams need from the platform

A SaaS company rarely fails an assessment because a control is missing. It fails because the evidence for that control is scattered, incomplete or produced after the fact. The cards below cover the attestation, change and data-protection points where self-managed GitLab can carry much of that evidence, and the decisions your team must make before an auditor asks.

SOC 2 Type 1 versus Type 2

A Type 1 report describes your system and tests whether controls are suitably designed as of one date. A Type 2 report adds an opinion on whether those controls operated effectively over a period. For GitLab, the Type 2 question is whether merge request approvals and pipeline gates behaved the same way in month three as in month one. Ask your auditor which period they will sample and whether your GitLab configuration changes are logged across it. Only the auditor issues the report.

Common criteria CC1 to CC9

The security common criteria CC1 to CC9 apply to every SOC 2, whatever other categories you include. CC1 to CC5 cover the control environment, risk assessment and monitoring, while CC6 to CC9 cover logical access, system operations, change management and risk mitigation. Map each criterion to a GitLab setting, a runbook or a recurring review, and record the owner. Gaps usually appear in access reviews and vendor risk, not in the repository itself.

Change management evidence from merge requests

Under the change management criterion in CC8, auditors look for proof that changes were reviewed, tested and approved before release. Merge requests with required approvals, protected branches and pipelines that must pass before merge produce that record. Confirm that approval rules cannot be edited by the author, that pipeline configuration changes are themselves reviewed, and that deployments link back to the merged change. Your team should test this trail before the observation window opens.

Access and identity evidence

CC6 criteria expect you to show who can reach source code, pipelines and production secrets, and that access is removed when people leave. Self-managed GitLab can take sign-in from your corporate identity provider and provision users through SCIM, so deprovisioning follows HR and directory changes. Plan a recurring group membership review and export it as evidence. Confirm which GitLab tier your SCIM and two-factor requirements need before you commit to a design.

GDPR Article 28(3) and Article 32

If your SaaS product processes personal data for customers, you are likely a processor. Article 28(3) requires a contract that limits processing to documented instructions, including on transfers, and Article 32 requires security measures for that processing. Self-managed GitLab keeps repositories, issue text and pipeline logs inside infrastructure you choose, which simplifies the transfer analysis. Check whether personal data appears in issues, logs or test fixtures, because those copies fall under the same contract.

EU Data Act switching rules

The EU Data Act, applicable since 12 September 2025, requires data processing service providers to let customers switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transitional period. From 12 January 2027, switching charges are prohibited. For customers, self-managed GitLab reduces dependence on a single hosting provider, but you still need tested export and restore procedures. Confirm with counsel whether your own service is in scope before relying on these timelines.

ISO/IEC 27001 Annex A as an optional framework

Some customers ask for ISO/IEC 27001 certification alongside or instead of SOC 2. Annex A lists controls in four themes, and many technological controls map onto source control, CI/CD and access management that GitLab already supports. Certification is issued by an accredited certification body, not by DeployOpen or GitLab, and it runs on a three-year cycle. Decide early whether one control set can serve both attestations, because duplicate evidence work is the main recurring cost.

Data residency and switching rights for source code

A self-managed GitLab instance keeps repositories, CI job logs, artifacts, container images and package registries wherever you install it, so data residency is set by your infrastructure choices, not by a vendor's region menu. Decide the region and cloud account for the application servers, the PostgreSQL and Gitaly storage, and the object storage bucket that holds artifacts and LFS objects. Keep the same region for the Runner fleet, because job logs and cache traffic travel with it. Confirm with your counsel whether source code, which often contains customer identifiers, test data or security configuration, falls under your personal data obligations, and map where each category lands. Object storage choices deserve particular attention, since backups and artifacts can be copied to buckets in other regions if lifecycle or replication rules are set that way.

For disaster recovery, GitLab Geo provides a warm-standby secondary site that is continuously synchronized, and the Geo documentation places it in another region. Choosing that region is a residency decision as well as a resilience one: a secondary outside your approved jurisdictions copies all of your source code there. Geo is available in the Premium and Ultimate tiers for self-managed GitLab, so confirm your tier before designing around it. Check whether your customer contracts allow a secondary in the chosen region, and document the failover runbook you will rehearse.

The EU Data Act, Regulation (EU) 2023/2854, applies since 12 September 2025 and requires data processing service providers to let customers switch to another provider or to on-premises ICT infrastructure, with a maximum two-month notice period and a 30-day transitional period. Self-managed GitLab removes most of the lock-in question by design, because the data already sits in your infrastructure. Still, you should confirm which of your vendors and hosting providers fall under the Act and what switching charges apply. From 12 January 2027, providers may not impose any switching charges. Ask your vendors to confirm their export formats and how repositories, issues and pipeline history can be moved out, and check the GitLab import documentation for the supported directions.

Rollout phases for a SaaS GitLab migration

The sequence moves a SaaS engineering organization from hosted source control to a self-managed GitLab instance in stages, with each phase producing evidence that auditors, security reviewers and platform owners can check before the next one starts.

  1. Scope the system and map SOC 2 controls

    Define which repositories, pipelines, runners and identity sources fall inside the SOC 2 system description, then map the change management, access and logging controls to GitLab features. DeployOpen leads the mapping with your compliance lead and auditor's expectations in view, and you decide which trust services categories are in scope. The step closes with a signed control matrix and a list of evidence sources, such as merge request approvals, protected branch settings and audit events, that will be exported during the examination period. Confirm the scope with your auditor before any build work begins.

  2. Choose the install method and size the instance

    Select an install method from the supported options, most commonly the Linux package for virtual machines or the Helm chart for Kubernetes, and size the topology against expected user counts and API load using the published reference architectures. You own the decision on whether to run a single node or a highly available layout, and on whether stateful services such as PostgreSQL and Redis run on virtual machines or managed services, since the reference architectures do not support running them inside Kubernetes. The step closes with an approved architecture diagram, a sizing record tied to your user forecast and a capacity plan for the next growth stage.

  3. Connect identity and apply hardening baseline

    Integrate GitLab with your corporate identity provider using SAML or OpenID-based sign-in, with SCIM provisioning so joiners, movers and leavers are reflected in access. Apply the hardening guidance to application settings, sign-up and visibility defaults, SSH keys, CI/CD settings and the operating system, rolling it out gradually as the vendor recommends. Your security team decides the approval rules and the two-factor policy. The step closes with a configuration export, a test log showing a deprovisioned user losing access and a hardening checklist signed off by the control owner.

  4. Import repositories, issues and pipelines

    Migrate repositories and related metadata from the current host in batches, starting with a low-risk group, then move issues and CI definitions. Your engineering leads choose which projects move first, which history is preserved and which legacy pipelines are rewritten rather than copied. Confirm the importer covers your source system, since some sources need external conversion tools. The step closes with a reconciliation report comparing repository counts, branch and tag totals, and sampled commit hashes against the source, plus a list of pipelines that have passed on the new instance.

  5. Stand up the runner fleet

    Build the runner fleet on the executor model that matches your workloads, such as the Docker Autoscaler on cloud virtual machines or the Kubernetes executor, and keep runner versions aligned with the GitLab version. Your platform team decides the isolation boundaries between projects, the autoscaling ceiling that controls spend and the cache and artifact storage location. The step closes with a load test that runs a representative pipeline set, a cost report by project and runner tag, and a record of runner registration tokens and their rotation schedule.

  6. Prove backup and restore on a separate instance

    Run a full backup and restore into an isolated test instance, including the secrets file and object storage data that the basic backup task does not fully cover. Confirm that restored projects, pipelines and runner registrations behave as expected and record how long the restore took on your hardware. Your operations owner decides the retention period and who may perform a restore. The step closes with a dated restore test record, a runbook reviewed by someone who did not write it and a decision on whether the recovery point and recovery time meet your commitments to customers.

  7. Decide on Geo for disaster recovery

    Assess whether a warm-standby secondary site is needed to meet your availability and recovery commitments. Geo is available in the Premium and Ultimate tiers for self-managed GitLab, so confirm your licensing before scoping it. Your leadership and risk owners decide whether a secondary in another region is justified, and whether failover is tested on a schedule. The step closes with a written decision record. If Geo is approved, the record includes the target region, the failover test plan and the licensing quote. If it is declined, it documents the accepted risk and the alternative recovery path.

  8. Cut over and run the first upgrade cycle

    Freeze writes on the source system, run a final incremental import, switch developer access and DNS to the new instance, and keep the old host read-only for a defined rollback window that you set. After cutover, plan the first upgrade against the required upgrade stops rather than the latest release, and test it on a staging copy first. The step closes with a cutover record showing the freeze start and end times, a rollback decision signed by the service owner and a completed upgrade rehearsal logged in the change management system, which becomes the first routine change evidence for the examination period.

What SaaS teams ask before hiring a GitLab partner

How much does a self-managed GitLab build cost?

The build cost is set by the written scope, not by a list price, and DeployOpen does not publish a price list. Expect cost to follow the number of users, the reference architecture you need, how many runner fleets you operate, whether you run Geo for disaster recovery, and how much identity, backup and monitoring work sits around the instance. Some costs are one-time, such as design, installation, migration and hardening. Others recur, such as licenses, infrastructure, runner compute and upgrades. GitLab's public pricing lists Free at 0 US dollars, Premium at 29 US dollars per user per month billed annually, and Ultimate as custom priced for self-managed installations, so license cost is a separate line from services. Ask for a quote that splits one-time work from recurring work and names which tier each feature needs.

How long does a self-managed GitLab deployment take?

Duration depends on the target size, the architecture and how much existing material must move. A single-node installation with a short list of integrations is a much smaller job than a high availability build with Gitaly Cluster, PostgreSQL with Patroni, Redis Sentinel and Consul, which GitLab generally recommends for 3,000 or more users. Migration from another Git host, the number of projects and pipelines to convert, identity integration, and the number of runner types all extend the schedule. Change approval windows in your organization and the time your auditors need to review evidence also set the pace. We confirm a timeline in the written scope after reviewing your user count, API load and migration inventory, so the plan reflects your environment rather than a generic estimate.

What does our team need to provide for a GitLab project?

The work goes faster when your team supplies access and decisions early. Typically that means:

  • An identity administrator to configure SAML or OIDC with your provider, LDAP group sync if used, and SCIM provisioning.
  • Cloud or data center access with accounts, networks, DNS, certificates, object storage and a place to run the Linux package, Helm chart or Operator.
  • A named owner for change management policy, branch protection rules and approval workflows.
  • An auditor or compliance contact who will tell us which evidence format they expect.
  • A backup target and a restore test window agreed with operations.

Confirm each item during scoping, because missing access is one of the most common causes of schedule slip.

Can an in-house team deploy self-managed GitLab on its own?

Yes, many platform teams install and run GitLab with their own staff, and the official installation methods give a clear starting point. The questions to answer honestly are whether the team has capacity for upgrades through required stops, whether it can operate PostgreSQL, Redis and Gitaly at the scale you need, and whether anyone owns runner fleet security and backups. GitLab's upgrade paths require passing through stops such as 18.2, 18.5, 18.8 and 18.11, so the upgrade calendar has to be planned, not improvised. A partner can take on the build, the hardening and the runbooks while your team keeps operational ownership. Decide which of these responsibilities stay in-house before comparing options.

How does a self-managed GitLab instance support SOC 2 evidence?

GitLab can serve as a system of record for change activity, including merge requests, approvals, protected branches and pipeline results, which auditors often sample for change management. Good evidence depends on configuration: access controls, audit logs, retention settings and the way deployments are linked to approved changes. DeployOpen prepares these controls and the evidence trail, but we do not issue SOC 2 reports. The AICPA's 2017 Trust Services Criteria apply common criteria CC1 to CC9 to every SOC 2, and the change management series CC8 is where many SaaS teams look first. Ask your auditor which period they will test, whether they expect a Type 1 or Type 2 report, and which evidence exports they accept.

What happens at GitLab upgrade 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. Skipping a stop can block the upgrade, so the plan must list each stop in order and test it in a staging environment that mirrors production. GitLab ships a minor release on the third Thursday of each month and patch releases twice a month, and it maintains the current and two prior minor lines, so a planned cadence is needed. Security fixes are backported to the previous two monthly releases, while bug fixes go only to the current stable release. Budget time for backups before each stop, for runner version alignment with GitLab, and for rollback criteria written into the change record.

How do we scale GitLab from one node as engineering grows?

Start with a size that matches today's users and CI load, then move up the reference architectures as user counts and API traffic rise. GitLab publishes reference architectures from 1,000 users at 20 API requests per second up to 50,000 users at 1,000 API requests per second. Scale-out steps usually include separating PostgreSQL and Redis, adding Gitaly capacity, and adding Sidekiq workers, with high availability generally recommended from 3,000 users. Running stateful components such as PostgreSQL and Redis inside Kubernetes is not supported by GitLab's reference architectures, so a Kubernetes footprint usually means the Cloud Native Hybrid pattern. Ask the partner to show the migration path between sizes and what downtime each step requires.

Does self-managed GitLab support data residency requirements?

Self-managed GitLab runs in infrastructure you choose, including your cloud accounts, data centers or air-gapped networks, so source code, pipeline logs and artifacts stay where you place them. Residency also depends on backups, object storage, runner locations and any external integrations, which each need a documented location. Under GDPR Article 28(3), a processor must act only on documented instructions and apply the security measures required by Article 32, so your contract and data map should match the deployment. Confirm the regions for every component during design, and confirm with your legal or privacy team which obligations apply to your customers.

How DeployOpen scopes and supports GitLab for SaaS teams

DeployOpen plans, implements, hardens, documents and supports self-managed GitLab inside your own cloud accounts, data centers or air-gapped networks. For SaaS and technology companies, the work starts with your engineering scale, compliance evidence needs and runner workload, then moves through a fixed written scope with handover and optional ongoing support.

How we scope

  • Written scope covering instance size, install method, and the reference architecture tier matched to your user and CI load
  • Mapping of which change-management and access evidence your SOC 2 auditor will ask GitLab to produce
  • Runner fleet plan defining executor types, autoscaling targets and which projects run on which runners
  • Data residency decisions covering where repositories, backups and object storage live in your infrastructure

How we build

  • Installation with the Linux package, Helm chart or Operator, chosen against your existing Kubernetes and VM footprint
  • Identity integration with your corporate SSO, SCIM provisioning and enforced two-factor authentication
  • Runner deployment on your cloud or Kubernetes clusters with isolation settings and secrets handling reviewed
  • Hardening of application settings, CI/CD configuration and the operating system, rolled out in stages

How we hand over

  • Tested backup and restore runbooks, including secrets and object storage, verified by a documented restore exercise
  • Upgrade runbook keyed to GitLab's required upgrade stops and the monthly release cadence your team will follow
  • Architecture, configuration and operations documentation written for the engineers who will run the instance
  • Knowledge transfer sessions with your platform and security teams before the engagement closes

How we support

  • Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
  • Ongoing support, upgrades and continuous security testing are available as retainers after handover
  • Security testing of the GitLab instance and its CI/CD pipelines can be included in the written scope
  • Confirm with DeployOpen which evidence the independent auditor will accept, since DeployOpen prepares evidence but does not issue audit reports

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com