{"id":85247,"date":"2026-07-07T07:00:00","date_gmt":"2026-07-07T14:00:00","guid":{"rendered":"https:\/\/dhblog.dream.press\/blog\/?p=85247"},"modified":"2026-07-07T07:46:51","modified_gmt":"2026-07-07T14:46:51","slug":"self-host-gitlab-ce-on-vps","status":"publish","type":"post","link":"https:\/\/www.dreamhost.com\/blog\/self-host-gitlab-ce-on-vps\/","title":{"rendered":"How To Self-Host GitLab CE on a VPS"},"content":{"rendered":"
\n\t
\n\t\t\n\t\n\t\t\n\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t\n\t\t<\/g>\n\t\t\n\t<\/g>\n<\/svg>\n\t<\/div>\n\t
\n\t\t\n\n

Self-hosting GitLab Community Edition (CE) on a VPS gives you full ownership of your source code, CI\/CD pipeline, and project data with no per-user pricing or third-party data exposure.<\/p>\n\n\n\n

GitLab CE<\/strong>, the free, open-source edition of GitLab, installs on Ubuntu in 10 to 15 minutes using the official Omnibus package (most of that is the automatic reconfigure step), plus about an hour for DNS, prep, and hardening. You’ll want a VPS with at least 8 GB of RAM (the practical floor for a real team, though GitLab can technically run on less) and a domain name.<\/p>\n\n\n\t<\/div>\n<\/div>\n\n\n

It’s a Friday afternoon, your team’s pull request is sitting in review, and your laptop pings with a familiar message: GitHub is having issues again.<\/p>\n\n\n\n

Maybe Actions are stuck.<\/p>\n\n\n\n

Maybe `git push` returns a 500 error for the third time this month.<\/p>\n\n\n\n

The thread in your team chat already has eight messages.<\/em><\/p>\n\n\n\n

The first time this happens, you laugh about it. The second time, somebody links the GitHub status page<\/a>, and you all go get coffee. The third time, usually right before a release window, somebody finally types the question out loud: “Should we just run our own?”<\/em><\/p>\n\n\n\n

For most teams, the honest answer is no. GitLab.com Free covers small teams comfortably, and the operational tax of running your own version-control server is not zero.<\/p>\n\n\n\n

It’s the kind of trade you only make for a real reason.<\/em><\/p>\n\n\n\n

If your team has one of those reasons, such as a customer contract that forbids third-party SaaS, a compliance boundary, or a seat-license bill that’s starting to look ridiculous, self-hosting GitLab CE is the cleanest move you can make. It\u2019s open source, runs on a single VPS, and, once tuned, maintenance takes about an hour a month.<\/p>\n\n\n\n

At DreamHost, we’ve hosted countless self-managed servers, and we keep seeing a pattern: developers who succeed with self-hosted GitLab pick the right plan up front, get the Secure Shell Protocol (SSH)<\/a> and Domain Name System (DNS) prep right, and then resist the urge to keep tinkering once it’s stable.<\/p>\n\n\n\n

Why Would You Self-Host GitLab Instead of Using GitLab.com?<\/h2>\n\n\n\n

You self-host GitLab when GitLab.com or GitHub.com can’t meet your privacy, compliance, or cost-control needs. For most other teams, the hosted option is a better trade.<\/p>\n\n\n\n

Three real reasons hold up under scrutiny:<\/p>\n\n\n\n

    \n
  1. Privacy and data sovereignty:<\/strong> Your source code lives on infrastructure you manage and patch on your own schedule. No third-party access, no shared platform, no breach blast radius beyond your own server.<\/li>\n\n\n\n
  2. Compliance:<\/strong> Regulated industries like healthcare, finance, and government often need data-residency control. Self-hosted GitLab CE is the simplest way to keep code inside a controlled boundary. <\/li>\n\n\n\n
  3. Cost control at scale:<\/strong> GitLab.com charges per active user. According to GitLab’s pricing page<\/a>, Premium costs $29 per user per month, while Ultimate pricing is available only on request. A 50-person team on Premium runs $17,400 per year before add-ons. A self-managed VPS plus an hour of monthly maintenance often costs less.<\/li>\n<\/ol>\n\n\n\n

    If you’re a two-person team with no privacy or compliance reasons, the right answer is GitLab\u2019s free tier. (Yes, we know that sounds funny coming from a hosting company<\/em>).<\/p>\n\n\n\n

    With self-hosting, you’re trading a monthly SaaS bill for ongoing operational time. That’s a worthwhile swap only if you have a good reason to make the switch.<\/p>\n\n\n\n

    Here’s where this option makes sense and where it doesn’t:<\/p>\n\n\n\n

    Scenario<\/strong><\/th>Best fit<\/strong><\/th><\/tr><\/thead>
    Privacy or compliance requirement<\/td>Self-hosted GitLab CE<\/td><\/tr>
    Team larger than ~30 active users<\/td>Self-hosted is often cheaper<\/td><\/tr>
    Code is your IP, and you want it local<\/td>Self-hosted GitLab CE<\/td><\/tr>
    2-5 person team, no compliance needs<\/td>GitLab.com (free)<\/td><\/tr>
    You don’t want to patch a server<\/td>GitLab.com<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    GitLab Community Edition is free under an MIT-style open-source license. There’s no user limit, no feature gate on the basics, and no upsell prompts. The whole platform is yours to run.<\/p>\n\n\n\n

    What Are the Hardware Requirements for GitLab CE?<\/h2>\n\n\n\n

    GitLab CE has clear hardware thresholds, and getting them right is the difference between a snappy install and one that thrashes through swap memory (disk space your operating system uses when RAM fills up).<\/p>\n\n\n\n

    According to GitLab’s official installation requirements<\/a>, sizing is expressed in requests per second rather than fixed per-user tiers. The published baseline is 8 vCPU and 16 GB of RAM for up to 1,000 users (about 20 requests per second). Smaller teams can run on less, down to a documented floor of 2 GB of RAM plus 1 GB of swap for evaluation, though performance suffers below 4 GB.<\/p>\n\n\n\n

    A fresh GitLab install consumes around 4-6 GB at idle. Once CI\/CD jobs start running, memory spikes fast. So plan for headroom \u2014 or plan for slowness.<\/p>\n\n\n\n

    As far as storage goes, GitLab\u2019s official baseline is\u202f40\u202fGB\u202fplus\u202frepository\u202fsize, but\u202f50\u202fGB\u202fis\u202fa\u202fsafer\u202fstarting\u202fpoint\u202fin\u202fpractice.\u202fRepositories\u202fgrow,\u202fand\u202fbuild\u202fartifacts\u202fpile\u202fup. NVMe, a\u202ffaster\u202ftype\u202fof\u202fsolid\u2011state\u202fstorage, makes a noticeable difference on Git operations and CI cache reads.<\/p>\n\n\n\n

    Here\u2019s how those thresholds map to DreamHost’s VPS hosting tiers<\/a>:<\/p>\n\n\n\n

    Use Case<\/strong><\/th>Recommended RAM<\/strong><\/th>DreamHost VPS tier<\/strong><\/th><\/tr><\/thead>
    Evaluation \/ personal<\/td>4 GB RAM<\/td>Stack 4<\/td><\/tr>
    Small team, light usage<\/td>8 GB RAM<\/td>Stack 8<\/td><\/tr>
    Up to ~1,000 users (GitLab’s published baseline)<\/td>16 GB RAM<\/td>Stack 16<\/td><\/tr>
    Running CI\/CD runners on the same box<\/td>+ 2-8 GB RAM on top of your tier<\/td>Size up (e.g. Stack 16 \u2192 Stack 32)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    The right starting point for most teams running real CI\/CD pipelines is Stack 16. That sounds like overkill until you watch the first build kick off and Sidekiq, Postgres, and a runner all spike at once.<\/em><\/p>\n\n\n\n

    16 GB of RAM gives you enough headroom for GitLab’s stack of services (roughly 4 to 6 GB at idle on a default install) and a couple of CI workers (1-2 GB each) to run hot at the same time without anyone in the team chat noticing.<\/p>\n\n\n\n

    \n\n\n

    Get Content Delivered Straight to Your Inbox<\/h2>

    Subscribe now to receive all the latest updates, delivered directly to your inbox.<\/p>

    <\/div>