Which fits your team: GitHub Enterprise Server or self-hosted GitLab
The decision starts with what your team needs from the platform. Teams that want GitHub's workflow, its pull request model and its Actions syntax, delivered as a self-managed appliance with a vendor-supported upgrade path, will find GitHub Enterprise Server the closer fit. Teams that want one self-hosted platform covering repositories, CI/CD, security scanning and compliance evidence on their own servers will look more closely at self-hosted GitLab. Both are self-managed, so the choice is about software, support model and who operates it, not only where it runs. Confirm the current GitHub Enterprise Server license terms and the per-user pricing that applies to your headcount directly with GitHub before comparing totals.
Four questions should drive the shortlist. First, the CI runner model: GitHub Enterprise Server runs Actions workflows, while GitLab uses GitLab Runner registered to your instance, so map your existing pipelines and self-hosted runner fleet to each. Second, the upgrade cadence your team can staff. GitLab ships a minor release monthly, and its upgrade paths pass through required stops, so check whether your team can apply those on schedule. Third, air-gapped requirements: GitLab documents offline operation, but confirm which scanners and AI features work fully disconnected in your environment. Fourth, the edition. GitLab Free, Premium and Ultimate differ in CI/CD, support and security features, so list the controls you must have, then compare them against the tier that includes them. Ask GitLab to confirm feature availability for your deployment model.
Which scenarios favor each platform
This table maps common operating conditions to the platform that fits them better, with the reason each advantage matters. Read each row against your own constraints, and treat a row as decisive only when its condition describes your environment.
| Scenario | Better fit | Why and under what condition |
|---|---|---|
| Air-gapped or offline deployment | Self-hosted GitLab | GitLab documents running self-managed instances in offline environments, with separate guidance for its security scanners. Confirm with GitLab which features your offline setup needs, and confirm the same for GitHub Enterprise Server before you decide. |
| Large user counts needing high availability | Self-hosted GitLab | GitLab publishes reference architectures from 1,000 to 50,000 users and recommends a high availability strategy at 3,000 or more users. Choose it when you plan for that scale and have staff for Gitaly Cluster, PostgreSQL and Redis components. |
| Existing GitHub Actions workflows | GitHub Enterprise Server | Workflows written for GitHub Actions run with little change on GitHub Enterprise Server, while GitLab CI/CD uses its own pipeline syntax. The advantage holds when rewriting pipelines would cost more than running the appliance. |
| One tool for CI and security scanning | Self-hosted GitLab | GitLab bundles CI/CD with security testing and compliance features, with the higher tiers adding application security, supply chain and vulnerability management. Confirm which scanners your tier includes before you rely on them. |
| Limited platform staff | Depends on tier and staffing | A single GitLab instance has many components to patch and back up, while the appliance is a packaged unit. Choose based on which operating model your team can keep current, and ask each vendor for its upgrade and support model in writing. |
| Frequent upgrade cadence with limited downtime | Depends on maintenance practice | GitLab ships a monthly minor release and requires upgrade stops at fixed versions, so upgrades must be planned. Choose GitLab when your team can schedule that cadence, and confirm the upgrade path with the current GitLab upgrade documentation. |
| Hosting on existing GitHub Enterprise Server investment | GitHub Enterprise Server | If your teams already rely on GitHub-specific integrations and your licenses are current, moving adds migration work. The case favors staying until a renewal, licensing change or residency requirement forces a decision. |
How hosting, data location and compliance differ
GitHub Enterprise Server ships as a virtual appliance that you install on your own hypervisor or cloud virtual machines, and GitHub manages the appliance image and its upgrade path. Self-hosted GitLab is a different kind of install: you choose a method and operate the components yourself. The main options are the Linux package, which bundles PostgreSQL, Redis and Sidekiq and is documented as the most mature and scalable method, the Helm chart, the GitLab Operator, Docker, and installation from source. For air-gapped networks, GitLab documents offline operation, with separate guidance for its security scanners and for GitLab Duo Self-Hosted. Confirm with your platform team which method fits your Kubernetes and VM standards, and which components will run as managed services.
- Appliance versus package: The appliance is a single unit under GitHub's update process, while GitLab's Linux package is a set of services you upgrade on your own schedule.
- Kubernetes boundary: GitLab's reference architectures state that stateful components such as PostgreSQL and Redis are not supported inside Kubernetes, so the Cloud Native Hybrid pattern keeps them on VMs or managed services.
- Air-gapped scope: Confirm offline support for each feature you need, including scanners and AI features, because the offline guidance is feature-specific.
- Network placement: Both platforms need reachable runner and webhook paths, so plan the network zones before the install.
- Ingress and TLS: Decide where certificates terminate and who renews them, since this is a shared responsibility in either model.
Ask each vendor to confirm the supported install method for your exact environment before you commit to a design.
On either platform, your repositories, issues, pull requests and attachments live in databases, object storage and Git storage on servers you control, so the question is which of those stores you operate and which you back up. Access tokens, SSH keys and runner registration secrets are stored by the platform and must be included in your backup and key-management design. GitLab documents a backup and restore procedure that covers its databases and repositories, and you should test a restore into a separate environment rather than assume a backup is usable. Hosted alternatives can store tokens and keys outside the region you select, so confirm where secrets are kept if residency is a requirement.
- Repository data: Git repositories, the database and uploaded files must be captured together, or a restore can produce mismatched issue and code states.
- Tokens and keys: Personal access tokens, deploy keys and runner tokens need rotation procedures and a clear owner.
- Backup location: Store backups in a separate account or site so a single compromise or outage does not remove both production and recovery copies.
- Restore testing: Run a timed restore into a test environment on a schedule, and record the result as evidence.
- Secret stores: Decide whether the platform's secrets live in your existing secrets manager and whether that manager is in scope for the same controls.
Ask for the exact list of data stores and secrets in your chosen architecture, and for the backup and restore steps your team must perform.
Residency is a deployment decision on both paths. Hosted services offer regional storage only in some plans and regions: GitHub Enterprise Cloud with data residency on GHE.com offers EU, Australia, US and Japan regions, and Azure DevOps stores customer data in the geography chosen for the organization but keeps tokens and SSH keys in a US datacenter. A self-hosted platform keeps data where you place it, but it does not automatically satisfy a residency rule for backups, logs, mirrors or support access. Map every copy of the data, including CI caches, container images and log exports, against the rule you must meet.
- Hosted residency limits: Regional options depend on the plan and region, so a plan that lacks a required region is a blocking finding.
- Self-hosted placement: Your choice of region, data center or air-gapped network sets the residency position, and it is yours to document.
- Derived copies: CI artifacts, backups, search indexes and log shipping can leave the primary region even when the primary data stays put.
- Support access: Record who can access production data during vendor or partner support, and under what approval.
- Export paths: Confirm the export routes you will use if you must move data out later.
Ask your provider and your own team to list every location where code, tokens, backups and logs will be stored.
Both platforms depend on identity configuration and audit logging to produce compliance evidence. GitHub Enterprise Server and GitLab each support enterprise sign-in, and GitLab documents authentication and authorization options for self-managed instances, including external identity providers and role-based access. Audit trails must record administrative changes, permission changes, token creation, and access to protected branches and repositories. Decide who may administer the platform, how privileged accounts are separated from daily developer accounts, and where audit events are shipped for retention. Confirm the exact audit event types and retention controls for your edition, since these vary by tier.
- Single sign-on: Connect the platform to your identity provider, and document the fallback path for when that provider is unavailable.
- Privileged accounts: Keep site administrators few, named and separate from routine accounts.
- Audit event coverage: List the events you must retain, then confirm each is produced by your chosen edition.
- Log shipping: Forward audit logs to a store that the platform administrators cannot silently edit.
- Access reviews: Schedule periodic reviews of group membership, token scope and runner access, and keep the results.
Ask for a written list of audit events, their retention settings and the identity options available in your edition.
DeployOpen plans, configures and documents the controls for a self-hosted platform, and prepares the evidence an assessor will ask for, such as configuration records, access reviews, backup and restore results, and change logs. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work, and they decide whether your controls meet a given framework. Expect the same evidence requests whether the platform is GitHub Enterprise Server or self-hosted GitLab, but expect the sources of evidence to differ because you own more of the stack in the GitLab case.
- Control mapping: Map each control objective to a configuration setting, a procedure and an evidence source, and keep the map current.
- Evidence collection: Decide how configuration exports, restore records and access reviews are captured on a fixed schedule.
- Vendor evidence: For a GitHub Enterprise Server appliance, collect the vendor's documentation and your own configuration records, because the appliance is only one part of the system.
- Auditor scope: Agree the systems and boundaries in scope with your assessor before you collect evidence.
- Shared responsibility: Record which controls the platform vendor, your hosting provider and your team each own.
Ask your assessor which framework and which evidence format they expect before the implementation begins.
What keeping each platform current demands
Keeping a self-managed forge current is a recurring workload, and the two platforms set that workload differently. For GitLab, the release cadence is published and predictable: a major release ships yearly (GitLab 20.0 is planned for May 2027), a minor release lands on the third Thursday of each month, and patch releases come twice a month. The maintenance policy currently covers 19.5, 19.4 and 19.3. Bug fixes are backported only to the current stable release, while security fixes also reach the previous two monthly releases, so your team must plan to move to a supported version rather than wait on a fix for an older one. Required upgrade stops fall at 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, so a long-delayed instance cannot jump straight to the newest release.
Compare that with the GitHub Enterprise Server release window and appliance upgrade path. Ask GitHub for the support period of your current feature release and the downtime, storage and hardware checks its upgrade guide requires, then convert those into staff hours per cycle. Confirm with your GitLab partner or support contract how many upgrade stops your version sits behind, and test the path on a staging copy with a restored backup from the GitLab backup and restore documentation before committing a production window. Budget both platforms as a recurring operations line, not a project.
High availability is where the upkeep becomes structural. GitLab's reference architectures range from 1,000 users at 20 API requests per second to 50,000 users at 1,000 API requests per second, and the documentation generally recommends a high availability strategy at 3,000 or more users. That strategy uses Gitaly Cluster with Praefect for repository storage, PostgreSQL with Patroni, Redis Sentinel and Consul, each of which must be operated, patched and tested for failover. Stateful components such as PostgreSQL and Redis are not supported inside Kubernetes, so the Cloud Native Hybrid pattern keeps stateless services on Kubernetes and places stateful services on virtual machines or managed services. Confirm which pattern your platform team can run and staff, because that decision drives the largest recurring cost.
How CI runners differ and what to plan for
GitHub Enterprise Server teams usually inherit Actions workflows, runner pools and artifact storage that were set up around GitHub's model. Moving to self-hosted GitLab means deciding where runners sit, how builds are isolated and how capacity is sized before the first pipeline is migrated.
Actions workflow reuse
Teams with many GitHub Actions workflows need to know how much of that YAML carries over. GitLab CI/CD uses its own .gitlab-ci.yml syntax, so workflows that call third-party actions, use GITHUB_TOKEN or depend on the actions/ marketplace must be rewritten or replaced. Inventory every workflow and the actions it pulls in, then confirm the equivalent job, secret and environment behavior in the GitLab CI/CD documentation before you schedule cutover.
GitLab Runner placement
Runner placement decides who can reach what. GitLab Runner can sit on VMs inside the same network as the GitLab instance, on separate build networks or on Kubernetes, and each option changes access to internal registries, artifact stores and deployment targets. Decide whether runners need outbound internet access in an offline environment, and confirm the supported executors and registration model in the Runner documentation for your chosen topology.
Runner isolation for regulated builds
Regulated builds often require that a job cannot read another project's secrets or leave artifacts on a shared host. Ask whether each runner is dedicated to a project group or shared across the instance, whether jobs run in ephemeral containers or VMs, and how cached dependencies are scoped. Map these settings to your change management and segregation of duties requirements, and confirm the isolation options against the Runner and hardening documentation rather than assuming defaults.
Artifact storage and retention
Build artifacts, container images and test reports accumulate quickly and often hold sensitive build output. Decide where GitLab stores job artifacts, how long they are kept, and whether they are included in backup and restore scope. Compare this with the artifact and retention settings your GitHub Enterprise Server appliance uses today, and confirm object storage configuration and retention limits in the GitLab administration documentation before sizing disks.
Capacity planning for concurrent jobs
Runner capacity depends on peak concurrent jobs, not on user count alone. Measure current queue times and peak job volume from your GitHub Enterprise Server Actions usage, then size runner pools with headroom for release days. GitLab's reference architectures tie API load to user counts, so pair that sizing with an estimate of build concurrency. Ask your team to confirm the concurrency and autoscaling settings in the Runner documentation before committing hardware or cloud spend.
Dependency access in air-gapped builds
Builds that pull packages, base images or actions at run time fail in an offline network unless those sources are mirrored internally. List every external dependency your pipelines fetch, including language packages, container base images and any marketplace actions, and decide which internal registry or mirror serves each one. Confirm how GitLab's offline guidance applies to your runners and which dependencies must be pre-staged before cutover.
What each platform costs to keep current
What does GitHub Enterprise Server cost each year to keep current?
The recurring cost has three parts: per-user GitHub Enterprise licenses, the appliance hardware that runs the instance, and the staff time and downtime needed for each upgrade. Licenses are priced per user, so the bill grows with headcount and with any contractors or service accounts that need a seat. The appliance is sized by license count, and the GitHub Enterprise Server documentation describes the hardware requirements for each size, so ask your GitHub account team for the current license and hardware figures in writing. Upgrades are recurring work: each feature release is supported for a limited period, so plan an upgrade cycle, its maintenance window and the storage and backup checks that come with it. Ask for the license terms, support tier and the hardware specification for your user count in one written quote.
How much does GitLab Premium cost compared with GitLab Free?
GitLab Free costs 0 US dollars, and GitLab Premium costs 29 US dollars per user per month when billed annually, according to the GitLab pricing page. Both tiers are available for self-managed installations, so the subscription is an optional recurring cost on top of the software, which is open core and can be run without a paid tier. Premium adds advanced CI/CD and priority support, so the decision depends on whether your teams need those features and the support response you require. Multiply the per-user rate by the number of seats you expect to bill, then add any tax or reseller terms in writing. Confirm with GitLab whether the seat count is based on active users, since that changes the annual total.
When is GitLab Ultimate worth its custom price?
GitLab Ultimate is custom priced, so there is no public figure to compare, and you should request a written quote. The GitLab pricing page places application security testing, software supply chain security, vulnerability management and compliance features in this tier. Those features matter most when you would otherwise buy separate scanners, a vulnerability management platform or compliance tooling, so compare the quote with the licenses and staff time those tools would cost you. If you already run open-source scanners and a separate vulnerability workflow, Ultimate may duplicate work you have already paid for. Ask GitLab to map each Ultimate feature to a control or workflow you need, and ask which of them run in an offline environment.
What infrastructure does a highly available self-hosted GitLab need?
A highly available GitLab installation carries the largest recurring infrastructure cost, and it grows with user count and API load. GitLab's reference architectures range from 1,000 users at 20 API requests per second to 50,000 users at 1,000 API requests per second, and the documentation generally recommends a high availability strategy at 3,000 or more users. That strategy uses Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul, so budget for several virtual machines, load balancing, storage and the staff to run them. The GitLab reference architectures documentation says stateful components such as PostgreSQL and Redis are not supported inside Kubernetes, so do not assume a cluster will hold them. Ask your architect to size the reference architecture against your user count and growth plan.
What do backups, storage and disaster recovery add to the bill?
Storage and backups are recurring costs that grow with repository history, LFS objects, CI artifacts and retention periods. Repository data, the database and object storage all need backup copies, and each copy needs capacity in the chosen region or data center. GitLab documents backup and restore procedures, so the cost to plan includes the time to test a restore, not only the storage. If you need geographic replication, GitLab Geo adds a second environment to run and maintain. Ask your team to measure current repository and artifact size, set a retention policy, and price the backup target and the restore test as separate line items.
How much staff time does a GitLab upgrade take?
Upgrade effort is mostly staff time, planning and downtime rather than license fees, and it recurs on a fixed cadence. GitLab ships a major release yearly, a minor release on the third Thursday of each month and patch releases twice a month, according to its maintenance policy, and bug fixes are backported only to the current stable release. Upgrades must pass through required upgrade stops, which since GitLab 17.5 fall at versions x.2, x.5, x.8 and x.11, so a team that falls behind needs more steps and more testing. Plan for an upgrade calendar, a staging environment and a documented rollback. Ask your implementation partner for a written upgrade plan that lists the stops between your current version and the target.
What does migrating from GitHub Enterprise Server to GitLab cost?
Migration is a one-time cost made up of labor, testing and parallel running, and its size depends on what you move. Git history can be moved with a clone or mirror, but issues, pull requests, reviews and wikis need a platform importer, and GitLab can import projects from GitHub, among other sources, according to its import documentation. CI pipelines, which are rewritten for GitLab CI/CD, often take the most effort, along with access rules, integrations and users. Costs fall when repositories are few, pipelines are simple and the team is already familiar with GitLab. Ask for a written scope that lists repositories, pipelines, integrations, identity mapping and the cutover plan, and request separate effort estimates for each.
Can DeployOpen handle the full cost comparison and migration for us?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, so the cost of a GitLab deployment, its high availability design, migration and upgrade support follows from a written scope. Share your user count, repository inventory, CI usage, backup targets and air-gap requirements, then request a quote. Your own finance and procurement teams should still compare the quote with the GitHub Enterprise Server renewal.
How a move from GitHub Enterprise Server to GitLab works
The sequence moves repositories, history, collaboration records, pipelines and access to self-hosted GitLab in an order that lets each stage be checked before the next begins. The end result is a GitLab instance that holds the same work, with GitHub Enterprise Server kept read-only until teams have confirmed the copy.
Inventory repositories, users and Actions workflows
Start by listing every repository with its size, default branch, open issues and pull requests, wiki use, Git LFS objects and large files, along with every user, team, outside collaborator and GitHub App or token that touches them. Catalog each workflow in the
.github/workflowsfolders and note which marketplace actions, secrets and self-hosted runners they depend on. Confirm the inventory with repository owners, because undocumented automations are where migrations most often lose work. The output is a signed-off spreadsheet that becomes the scope for every later step.Mirror Git history into a staging GitLab
Use
git clone --mirrorto copy each repository, including all branches, tags and refs, then push the mirror to a staging GitLab project. Check the GitHub repository limits before you start, since GitHub recommends keeping the .git folder under 10 GB and enforces a 100 MB file limit and a 2 GB push limit, so repositories that exceed them need history rewriting or LFS handling first. Compare commit counts and tag lists between source and target. Done means every mirrored repository matches its source refs.Import issues, pull requests and reviews
Run the GitLab import tooling for the GitHub source, which brings across issues, pull requests and their review comments where the importer supports them. GitHub API rate limits shape this stage: personal access tokens get 5,000 REST requests per hour, so large organizations should schedule imports in batches and confirm the token type and throughput with their own administrators. Ask the importer owner to document which object types were not carried over, such as Actions run history, reactions or some attachments. Done means a sample of imported issues and merge requests has been checked against GitHub by the people who use them.
Rebuild CI pipelines on GitLab CI/CD
Translate each GitHub Actions workflow into a
.gitlab-ci.ymlpipeline, mapping triggers, jobs, artifacts, environments and secrets to GitLab equivalents. Register GitLab Runners on infrastructure you control, matching the operating systems and tooling the workflows need, and confirm that self-hosted runners can reach internal registries and deployment targets. Marketplace actions usually need a replacement template or script, so list each one and decide how it will be rebuilt. Done means every pipeline runs green on staging for a representative set of branches, and the runner fleet is documented.Map identity, groups and permissions
Connect GitLab to your identity provider using the authentication options in GitLab's documentation, then map GitHub organizations, teams and repository roles to GitLab groups, subgroups and project roles. Review branch protection rules, required reviews, code owner files and deploy keys, because these rarely translate one to one and must be re-created deliberately. Confirm which service accounts and tokens will exist in GitLab and who owns them. Done means access tests for sample users in each role return the same permissions they had on GitHub Enterprise Server.
Pilot with a small group of teams
Move a limited set of teams and repositories first, and let them work in GitLab for a defined trial period agreed with their leads. Track issues with the pilot itself, including broken links, missing reviewers, failed pipelines and access complaints, and fix them in the migration scripts so the same fix applies to later waves. Keep the GitHub Enterprise Server copies live during the pilot. Done means the pilot teams have closed their open migration issues and agree that the workflow is usable.
Cut over remaining repositories in waves
Move the rest of the inventory in waves, repeating the mirror, import, pipeline and permission checks for each batch. Freeze pushes to a repository during its final sync, run a last mirror update, and then switch developers' remotes and any integrations that point to the old URLs. Keep GitHub Enterprise Server read-only rather than deleting it, so that history and links remain available. Done means every wave passes its checks and no active integration still points to the old instance.
Back up, verify and retire GitHub Enterprise Server
Before decommissioning, take a final backup of the GitHub Enterprise Server instance and store it under your retention policy, then confirm that GitLab backup and restore procedures are tested on the new instance. Document where audit records, release artifacts and legacy links are archived. Only after leadership signs off on the archive should the appliance and its licenses be retired. Confirm license termination terms with your GitHub account team before you stop renewing. Done means a restore test has succeeded and the decommissioning record is complete.
Questions buyers ask before choosing GitLab or GitHub Enterprise Server
How much does it cost to move from GitHub Enterprise Server to self-hosted GitLab?
The move cost depends on scope, not on a single price, and no figure for it is supplied here. The main cost components are the GitLab subscription (if you buy one), the servers or cluster you run it on, storage and backup capacity, migration work, and the staff time to operate and upgrade the platform. GitLab Free has no license fee, while the pricing page lists Premium at 29 US dollars per user per month billed annually, with Ultimate custom priced. Ask any provider for a quote that separates one-time work (planning, migration, integrations, hardening) from recurring work (subscriptions, infrastructure, upgrades, on-call support), and ask what each line assumes about user count, CI volume and storage.
How long does a GitHub to GitLab migration take?
Duration depends on how much you move and how much you change along the way. Git history can be cloned or mirrored between any two forges, but issues, pull requests, reviews and wikis need a platform importer. GitLab can import projects from GitHub and Git repositories by URL, according to its import documentation. Timing is driven by repository count, the volume of pull request and issue history, the number of CI pipelines that need rewriting for GitLab CI/CD, identity and access setup, and how many teams must cut over together. A fixed-scope written plan from DeployOpen or another provider should state the timeline; ask for it to list each phase and its dependencies.
Can our own staff run self-hosted GitLab without outside help?
Yes, many teams do, but the answer depends on the skills and capacity you have. Running GitLab means operating its package-based installation (which bundles PostgreSQL, Redis and Sidekiq), backups and restores, upgrades, and Gitaly storage. GitLab requires upgrades to pass through required upgrade stops, which fall at versions such as 18.2, 18.5, 18.8 and 18.11, so upgrades need planning. The reference architectures recommend a high availability strategy at 3,000 or more users, which adds Gitaly Cluster, PostgreSQL with Patroni, Redis Sentinel and Consul. Confirm that your team has Linux, database and on-call capacity for that load before committing.
What does a DeployOpen engagement include, and what is covered by a retainer?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports, attestations or certifications.
Can GitLab run in an air-gapped environment?
GitLab documents running self-managed instances in offline, air-gapped environments, with separate guidance for running its security scanners and GitLab Duo Self-Hosted offline. Plan for the parts that normally reach the internet: package and container image delivery, scanner database updates, runner registration, and identity provider connections. Confirm with GitLab which features in your chosen tier work offline, and confirm how you will move upgrade packages and security patches across the air gap on the release cadence described in its maintenance policy.
How do GitLab Free, Premium and Ultimate compare for self-managed use?
All three GitLab tiers are available for self-managed installations. Free costs nothing and covers core source hosting. Premium adds advanced CI/CD and priority support, according to the pricing page. Ultimate adds application security testing, software supply chain security, vulnerability management and compliance features. Because GitLab is open core, code outside its ee/ directory is MIT licensed, while the ee/ directory falls under the GitLab Enterprise Edition license. Compare the features you actually need against each tier, and check which controls you must evidence before you pick a tier, since compliance readiness work depends on that choice.
How often does GitLab release updates, and what does that mean for our upgrade plan?
GitLab ships a major release yearly, a minor release on the third Thursday of each month, and patch releases twice a month. It currently maintains 19.5, 19.4 and 19.3, according to its maintenance policy. Bug fixes are backported only to the current stable release, while security fixes also reach the previous two monthly releases. That means you should plan to upgrade at least monthly to stay within support for fixes, and to follow the required upgrade stops. Compare this with your current GitHub Enterprise Server release, whose support window you should confirm in the GitHub Enterprise Server releases documentation.
What hardware and storage does a self-hosted GitLab instance need?
Sizing depends on user count, API request rate, CI volume and repository size. GitLab's reference architectures run from 1,000 users at 20 API requests per second up to 50,000 users at 1,000 requests per second. Stateful components such as PostgreSQL and Redis are not supported inside Kubernetes, so the Cloud Native Hybrid architecture runs stateless parts on Kubernetes and stateful services on VMs or managed services. Also plan for CI runners on separate hosts, backups and disaster recovery through the backup and restore documentation, and storage growth from repository and artifact history. Ask your provider for a sizing worksheet tied to your numbers.
What a fixed-scope evaluation or migration covers
A DeployOpen engagement for self-hosted GitLab starts with a written scope, not with an installation. Before any server is built, the scope and deliverables are agreed in writing, and that document defines which parts of the work are included: planning the target architecture, implementing the GitLab instance in your own cloud accounts, data centers or air-gapped network, integrating it with your identity provider and existing tooling, hardening it, configuring backups, planning upgrades, documenting the result and supporting the platform afterward. Most engagements are fixed-scope, so the agreed deliverables and timelines are what you verify against. Ask for the scope to name the GitLab edition (Free, Premium or Ultimate), the installation method, the number of users and whether high availability is in or out of scope.
Pricing follows from that scope. DeployOpen does not publish a price list, and a quote is produced from the written scope, so the useful request is a scope document that lists each component and its assumptions. Expect the one-time work (architecture, installation, migration of projects and CI settings, hardening and the first backup test) to be separated from recurring items. Ongoing support, upgrades and continuous testing are available as retainers, and the retainer terms should state which GitLab upgrade stops and monthly releases it covers, who applies security patches and how restore tests are scheduled. Confirm with DeployOpen how the quote treats the GitLab Runner fleet and any offline scanner setup, since both change the effort. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, so ask which evidence it will hand over for your assessor.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For GitHub Enterprise Server versus self-hosted GitLab, we start with the written scope that decides which GitLab edition, runner model and availability design fits your users, pipelines and compliance obligations.
How we scope
- Inventory your GitHub Enterprise Server users, repositories, Actions workloads, LFS storage and integrations before choosing a GitLab tier.
- Agree in writing which GitLab edition, reference architecture and high availability design your user count and API load require.
- Confirm which GitLab features you need from Free, Premium or Ultimate, and which must be verified against current vendor documentation.
How we build
- Install GitLab on your own servers or in your own cloud accounts, using the installation method your platform team selects.
- Plan GitLab Runner fleets, CI/CD migration from GitHub Actions, and authentication through your existing identity provider.
- Configure offline or air-gapped operation, hardening baselines, backup and restore procedures, and an upgrade path that follows GitLab's required upgrade stops.
How we hand over
- Migrate repositories, issues, pull requests and wikis with platform importers, and test each batch against an agreed acceptance list.
- Deliver runbooks for upgrades, backups, restores, runner scaling and incident response, written for your operations staff.
- Document configuration, access controls and evidence so your internal assessors and independent auditors can review the setup.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after the fixed-scope work closes.
- Retainers can cover GitLab minor and patch cadence, upgrade stop planning and restore testing on a schedule you approve.
- Ask any quote to state what recurs, such as retainer hours, runner capacity and licensing, and what is one-time migration work.
