Managed GitLab hosting

Engineering and securityOn-prem or sovereign site

Git repositories, merge requests, CI/CD pipelines and registries in one application, run on your own hardware or in Swiss and EU regions, with runners on machines you place. Pilae runs it on your own servers, or in Zurich, Switzerland, and eleven other Pilae Cloud regions.

Talk to us about GitLab

Licence: MIT
Runs on: Your own hardware, or any of twelve Pilae regions — six of them in Switzerland and the EU
Upgrades: Pinned, tested against your configuration, applied in your window
Upstream: about.gitlab.com

Running GitLab in production: what it takes

Size, then deploy the Linux package
One node on the upstream reference architecture for up to 1,000 users, or the multi-node layouts beyond it, pinned to a version we have run. Community Edition, unless your requirements need a paid tier.
Buckets from the first day
Artifacts, LFS objects, uploads, packages and container images go to object storage in the same region before the first project exists. Moving them off local disk later is a migration of its own.
Runners on their own machines
CI jobs run on runner machines sized to your pipelines and registered over the private network, never on the host that holds the repositories and the secrets.
Back up three things, restore them together
The backup archive, the buckets, and /etc/gitlab with the SSH host keys go offsite daily, encrypted, to a location in your chosen country, with the secrets kept apart from the data. Once a month we restore all three into a scratch instance of the same version and sign in.
Upgrade along the path, in your window
GitLab ships a minor release every month, with required upgrade stops along the way, and background migrations must finish before the next step. Security fixes reach only the current release and the two before it, so we do not let an instance fall further behind. Each step is rehearsed on a copy; with your approval, the Pilae Agent applies it in your window and records it in the console.

What GitLab is, and who runs it

Self-hosted GitLab for code, pipelines and registries

GitLab is one application for Git hosting and the work around it: repositories with merge requests and code review, CI/CD pipelines, container and package registries, issues and boards, and wikis. Teams coming from GitLab.com already know it, so for them a self-managed instance changes where it runs more than how people work. Teams coming from GitHub learn a new pipeline syntax and a different permission model.

We run it on dedicated machines, on your own hardware or in one of 12 Pilae Cloud regions with six in Switzerland and the EU, and it answers only on your private network. Source code, build logs and the images you ship stay in one place you can name. For a team that wants a lighter forge, Forgejo is the other one we run. GitLab has a container registry of its own; teams that want one registry for every forge and cluster, with replication between sites, add Harbor beside it.

GitLab in production: runners, backups and the upgrade path

GitLab is heavy. The upstream reference architecture for up to 1,000 users is one node with 8 vCPU and 16 GB of memory, running Rails, Sidekiq, Gitaly, PostgreSQL and Redis together. Upstream recommends a standalone deployment with good backups up to about 2,000 users and high availability from 3,000, which is a different amount of machinery. CI jobs run on separate runner machines, and artifacts, LFS objects and images go to buckets in the same region.

The backup command leaves out two things a restore cannot do without: the buckets, and /etc/gitlab, where gitlab-secrets.json holds the key to CI variables and two-factor secrets. We back up the archive and both of those daily, encrypted, to an offsite location in your chosen country, and the monthly drill restores all three together into a scratch instance of the same version. Upgrades follow the documented path, stop by stop, with background migrations finished before the next step. The Pilae Agent tests each step on a copy and applies it in your window. Probes read GitLab’s readiness check every 60 seconds and alert an engineer.

GitLab licence and editions

GitLab Community Edition has no per-user fee. Sign-on through OpenID Connect, SAML or LDAP is in the Free tier, so Keycloak or Entra ID works without a subscription. We tell you which tier your requirements need before deployment. Pricing for our operation is on request. Talk to us about the repositories you want to move.

GitLab Community Edition is MIT-licensed. The Enterprise Edition adds the code in its ee/ directory under the GitLab Enterprise Edition licence, which is source-available rather than open source: it may be read and modified, but used in production only with a paid subscription for the right number of seats. Without an activation code, the Enterprise Edition runs the Free features only. Merge request approval rules, code owners, push rules, protected environments, epics, LDAP and SAML group sync and Geo are Premium; DAST, dependency scanning and the security dashboards are Ultimate. We deploy Community Edition unless you need a paid tier, and if you do, the subscription is held in your name with GitLab.

GitLab system requirements

Before anything is deployed, this is what has to exist. We size it with you in the first session, and we say so when your own hardware is already enough.

CPU and memory: 8 vCPU · 16 GBThe upstream baseline for one node, sized for up to 1,000 users. Rails, Sidekiq, Gitaly, PostgreSQL and Redis share it, and upstream advises turning swap off.
Database: PostgreSQL 17The only database GitLab supports, bundled in the Linux package. Recent major releases have each raised the minimum, so the PostgreSQL upgrade is part of the upgrade plan.
Repository storage: Local SSD, not NFSGitaly needs at least as much disk as all repositories combined. Upstream warns that NFS and cloud file systems can significantly affect performance.
Object storage: S3-compatible · one bucket per typeJob artifacts, LFS objects, uploads, packages and container images go to buckets. The backup command does not copy them, so they are backed up on their own.
Runners: Separate machinesUpstream advises against running CI jobs on the GitLab host, for security and performance. Runners register over the private network, one pool per level of trust.

Migrating from GitHub Enterprise Cloud to GitLab

GitLab has a built-in GitHub importer, and it brings more than the code: branches, pull requests as merge requests with their reviews and comments, issues, labels, milestones, wikis, release notes and LFS objects. Contributions arrive against placeholder users and are reassigned to real accounts afterwards. Organisations and teams do not come across, so the group structure is designed first. Actions workflows are rewritten as GitLab pipelines, and secrets, which GitHub never gives back, are entered again. Required status checks are not imported, and code owner approval and push rules need GitLab Premium. The pipelines and the GitHub API rate limit set the pace: GitLab's own test import of the Kubernetes repository took 76 hours.

Design the groups first
We map your GitHub organisations and teams to GitLab groups and subgroups, with their roles, before the first repository moves, because permissions inherit down the group tree.
Import in batches, ahead of the switch
The largest repositories start days early. The import runs through an OAuth app owned by your Enterprise Cloud organisation, which raises the GitHub API limit from 5,000 to 15,000 requests an hour.
Rewrite the workflows
Each Actions workflow becomes a .gitlab-ci.yml, run by your own runners instead of hosted ones. Marketplace actions are replaced one by one, and secrets become masked, protected CI/CD variables.
Reassign, then archive the old repositories
Placeholder users are reassigned once people have signed in through your identity provider. Developers repoint their remotes, and the GitHub repositories are archived, read-only, until their owners sign off.

What a GitLab restore actually needs

acme-2026-09-24_gitlab_backup.targitlab-backup create, nightly
- backup_information.ymlthe version and edition it restores into
- db/database.sql.gzPostgreSQL dump, 11 GB
- repositories/@hashedone Git bundle per repository, 120 GB
gitlab_config_1790214300_2026_09_24.targitlab-ctl backup-etc, stored apart
- gitlab-secrets.jsondecrypts CI variables and 2FA secrets
- gitlab.rbrepository storage names must match
- ssl/TLS keys and certificates
s3://acme-gitlab-*not in the archive, copied offsite separately
- acme-gitlab-artifactsjob artifacts and archived logs, 1.4 TB
- acme-gitlab-lfsLFS objects, 310 GB
- acme-gitlab-uploadsissue and merge request attachments
- acme-gitlab-packagespackage registry
- acme-gitlab-registrycontainer images, restored with the registry database
/etc/ssh/ssh_host_*_keyso Git over SSH sees no new fingerprint

An example restore set for acme. The backup archive holds the database and the repositories. It does not hold /etc/gitlab, where the key to CI variables and two-factor secrets lives, or the buckets with artifacts, LFS objects and images. The monthly drill restores all of them together, into the exact version and edition the archive records, because that is the only instance it will restore into.

What Pilae is responsible for

A pinned version

A version we have run, not whatever latest resolves to that day.

A runbook

What it depends on, how it fails, what to do about it. In your repository.

A restore drill

Backups restored on a schedule. A backup nobody has restored is a file.

A patch window

Security updates in a window you agreed, with a rollback ready.

Someone watching

Every endpoint probed on the minute. An alert reaches a person, not a dashboard nobody opens.

Where it runs: zur1, fra1, fal1, gra1, ams1, hel1, lon1, ash1, hil1, sin1, tok1, syd1, on-premZurich, Frankfurt, Falkenstein, Gravelines, Amsterdam, Helsinki, London, Ashburn, Hillsboro, Singapore, Tokyo, Sydney, Your own hardware
Who holds the credentials: You do. Ours are separate, named, logged and revocable with one command. We ask before anything changes outside an agreed window.
If you leave: The machine, the data, the compose files and the runbook are already yours. Nothing stops when our access does.

What drives the price of running GitLab

Pricing is on request: a fixed price for onboarding, then a monthly price for GitLab, quoted in writing within five business days. The plans set what every deployment includes; these are the inputs the quote is built from.

Instance size: The CPU, memory and, where a model runs, the GPUs the app needs for your users and your data.
High availability: One machine with tested restores, or a replicated setup that keeps serving when a node fails.
Storage and backups: How much data it holds, how long backups are kept, and point-in-time recovery for its database.
Plan and support: Essential, Business or Enterprise: support hours, response times in the contract and how often we review the service with you.
Region: Your own hardware, where the infrastructure is already yours, or a Pilae Cloud region, where it is passed through at cost plus a fixed margin.
Sign-on and integrations: Single sign-on, directory sync, mail relays and the other systems the app has to reach.

GitLab: common questions

Is GitLab open source?

The Community Edition is, under the MIT licence. The Enterprise Edition adds code under the GitLab EE licence, which is source-available: you can read and modify it, but production use needs a paid subscription. Without an activation code, the Enterprise Edition runs the Free features only. We deploy Community Edition unless you need Premium or Ultimate.

Where do our repositories and artifacts live?

Repositories on the local disk of the GitLab machine, the database beside them, and artifacts, LFS objects, packages and images in buckets in the same place: the Pilae region you picked, in ISO 27001-certified datacentres, or your own hardware. Runners sit wherever you place them.

Can we sign in through Keycloak or Entra ID without a paid tier?

Yes. OpenID Connect, SAML and LDAP sign-in are all in the Free tier of a self-managed instance. Two things need Premium: group sync, which sets GitLab group membership from the directory over LDAP or SAML but not over OpenID Connect, and OpenID Connect rules that require a directory group or grant roles from one. Without Premium, people sign in with their directory accounts and group membership is managed in GitLab.

Can GitLab be upgraded without downtime?

Not on a single node. The package stops GitLab while it runs the database migrations, so each step of the upgrade path takes a short window. Zero-downtime upgrades need the multi-node, load-balanced architecture that upstream recommends from about 3,000 users. Below that, a scheduled window at night is usually the better trade, and we say so.

Should we run GitLab or Forgejo?

GitLab when you want code, CI/CD, registries and planning in one application and can give it the machine it needs. Forgejo is a much smaller system to run, with repositories, pull requests, packages and its own CI. For a few dozen developers who mostly need a forge, Forgejo is often enough, and we tell you when it is.

Back to apps

Bring us your GitLab. We will tell you what it takes.

Thirty minutes on the deployment you already have, or the one you are about to start.

Start with one workload Book a 30-minute briefing