GitLab vs GitHub: which should our small team use?

The week you hire a sixth developer, the private top-level group holding your code on GitLab.com Free goes past five users. GitLab's free user limit docs say the group then goes read-only. On GitHub Free for organizations the new hire gets in without trouble, since collaborators are unlimited, but you'll run into a different limit the first time you want to lock down main. GitHub Free's private repos can't use protected branches or code owners.

The paid plans you'd compare next are GitHub Team, listed at $4 per user/month for the first 12 months, and GitLab Premium, at $29 per user/month billed annually. There's also an option with no license fee at all, GitLab Community Edition. CE runs on servers you control, one for GitLab and one for the runner that does your CI jobs, and the table below gives it a column of its own.

How the plans compare on a private repo

Every row below assumes a private team repo. The plan facts come from each vendor's own pricing page or docs.

Plans and prices as listed on github.com/pricing and about.gitlab.com/pricing on September 28, 2026, and unchanged when we read both again on October 21. GitHub's page doesn't say what Team costs after the first 12 months. The storage row isn't like for like. GitHub's allowance covers packages and Actions artifacts, and GitLab's covers Git repository and LFS storage in each project.

If your team wants someone to sign off before a deploy reaches production, read the deploy row before the price row. On GitHub Free, Pro and Team, required reviewers for deployment environments only work on public repos, which puts that gate a tier above a required merge review for anyone with private code. GitLab puts both in Premium, where protected environments set who can deploy and who must approve. If your code is public, most of these gaps close on GitHub: protected branches and deployment reviewers both work on public repos without a paid plan.

Which one fits your team

In our view, GitHub is hardest to leave when your pipelines lean on Actions, since moving means adapting the Marketplace workflows you borrow to GitLab CI.

What GitLab CE leaves out, and what it keeps

In CE, one of your leads can merge a request nobody's reviewed, and GitLab won't stop it. Approvals in the free tier, which is the feature set CE runs, "are optional and don't prevent merging without approval". Everything in the What needs Premium list below is badged Premium in GitLab's docs.

Whether a review happens first is still up to your Maintainers. If a customer contract or a compliance review says no change ships without a second approval, CE can't enforce that, and Premium's approval rules can.

You won't have to migrate to get them. GitLab's conversion docs have you install the Enterprise Edition (EE) package on top of CE, then add a license. Until you add it, EE runs the same Free features at no cost. Premium's features turn on when you activate a paid license.

What running it yourself takes

One CE admin on the GitLab Forum, running an instance with about 40 registered users, about five of them active, handles the routine every Monday:

Your plan needs a little more:

• Applying GitLab updates on a schedule you keep, at a quiet hour. After a cold start, our test instance took about 2 minutes before its sign-in page answered
• Backing up to somewhere other than the server, and restoring a copy now and then to prove it works. GitLab's backup leaves out gitlab.rb and gitlab-secrets.json, and its backup docs say to copy both yourself
• Updating GitLab Runner on its own server, too
• Naming a second person who can do all of it when the first is away

Here's what a year of seats comes to at list price, before you count anything for servers:

That's $29 and $4 per user a month, times 12. Our guide on GitLab and GitHub per-user costs next to one GitLab CE server prices the full bill, servers included. At the 2025 US median wage for software developers, QA analysts and testers of $64.44 an hour, from the Bureau of Labor Statistics, 10 Premium seats cost about as much as 54 hours of a developer's time a year, and 10 GitHub Team seats about 7 hours.

To weigh those hours against seat fees for your own team, take a year of Premium seats, subtract what the two servers cost, and divide by your own hourly cost. That's how many hours of upkeep a year you could spend before CE costs more than Premium. This weighs cost only, since CE doesn't enforce approvals the way Premium does. If GitHub Team is your other option, run the same math at its $4 seat price. At that price, seat fees take much longer to add up to the cost of two servers and their upkeep.

On DreamHost's GitLab VPS, DreamHost supports the hardware, network and connectivity 24/7, and the product page says you handle software updates and configuration yourself. Backups are yours too, as the list above says.

How much server GitLab needs

GitLab's requirements page sets 8 vCPU and 16 GB of memory as the baseline for a single-node install. DreamHost's GitLab VPS plans include Stack 16 (4 vCPU, 16 GB) and Stack 32 (8 vCPU, 32 GB). Stack 32 is the first plan that meets that baseline. Stack 16 matches the 16 GB but has half the 8 vCPU, so it sits below the baseline, and the smaller plans sit further below it. GitLab's memory-constrained guide goes much lower, for up to five developers. Neither page names a team of 10 or 20.

Those numbers are for GitLab itself. CI jobs belong somewhere else: GitLab's runner install page says to install GitLab Runner on a machine separate from the machine that hosts your GitLab instance. GitLab doesn't publish a size for that machine. Its runner requirements page says it depends on how much CPU and memory your jobs use, how many run at once, and how many people work in parallel. Our own estimate puts it on Stack 8, which has 2 vCPU and 8 GB, the same as GitLab.com's default hosted runner.

GitLab requirements pages read September 28, 2026, and runner pages October 20, 2026. Stack specs come from the DreamHost GitLab VPS page.

GitLab's docs don't say where 4 vCPU runs out for a team your size, and we haven't measured it either, so the test below runs GitLab on Stack 16 and watches it while pipelines run. When jobs queue during the test, check the runner's concurrency setting and the CPU use on both servers before you blame a plan. A GitLab server whose CPU sits near full while pipelines run is the sign you've found the gap, and Stack 32 meets both of the requirements page's baseline numbers. Disk grows with your repositories, container images and CI artifacts, so check the used space at the end of the trial and project it forward.

What GitLab CE used on our test VM

GitLab's sizing pages give a baseline for real use and a low-memory floor, but no reading of what an empty install actually uses. So we ran the official GitLab CE 19.5.0 image on a test VM with 2 vCPU and 8 GB, about the size of the runner server above, and read its memory 10 minutes after it settled. Then we ran three pipelines from a small Node.js project, with GitLab Runner on the same VM.

In CPU figures, 100% is one vCPU, so the job and GitLab together needed more than the VM's two. These runs had no users and one small project, so they can't give you a team size. They do put GitLab's idle memory at about 4,285 MiB with default settings and about 2,657 MiB with the low-memory ones, about a quarter of Stack 16's 16 GB or less, which leaves the 4 vCPU as the figure to watch. So during the trial, watch CPU on both servers while your own pipelines run.

How to try CE for one sprint

Mirror your code to the test server and leave the original where it is, so if the test doesn't work out, there's nothing to move back.

1. Copy one real repository

   Pick a repo with a working pipeline and its real history, so the test carries your actual size and build times. GitLab's GitHub importer brings the repo, issues and pull requests across.

2. Set the merge rule

   Protect main with Allowed to merge set to Maintainers and Allowed to push and merge set to No one. Then see whether your leads are comfortable with approvals GitLab won't enforce.

3. Run a normal week of CI

   Register a runner on a second server, a Stack 8, and run your usual pipelines. If they're GitHub Actions workflows, rewrite them for GitLab CI first and count those hours in the test. Note how long jobs wait while people are using the web app.

4. Test a restore and an update

   Restore a backup, plus your copies of gitlab.rb and gitlab-secrets.json, to a spare, throwaway server, then apply a GitLab update. Note how long each took and anything you had to fix by hand. We didn't time an update on our test VM, so this step is where your upkeep figure comes from.

Before the sprint starts, write down your pass mark: how long a build may wait, and how many hours a month of upkeep you'll accept.

How we tested GitLab CE

The GitLab figures on this page were measured by DreamHost on a test VM (arm64), not a DreamHost server, on October 20, 2026. That's the same run behind our guide on GitLab and GitHub per-user costs, which has the full setup and the idle readings in more detail. Our plans use x86 AMD EPYC processors, so expect small differences on a real server. In short: the official CE 19.5.0 image on a 2 vCPU machine with 8 GB of memory (7,922 MiB as Linux reports it), once at default settings and once at GitLab's memory-constrained settings. For the pipelines, GitLab Runner sat on the same machine and ran the open-source Express project's test and build jobs three times, while we read memory and CPU every 3 seconds.

What we didn't test: a real team's load, a large repository, several pipelines at once, a runner on a second server, Stack 16's 4 vCPU or Stack 32's 8, and an update's downtime. Each setting ran once. Plan facts and prices come from GitHub's and GitLab's own pages on the dates in the sources.

GitLab or GitHub FAQs