Category: Development
Managed self-hosted GitLab
Your GitLab on your infrastructure, upgraded without scares, with runners that do not get stuck and backups we know restore because we check.
- Where it runs
- In your account, in your name
- Backups
- With tested restores
- Updates
- Planned and documented
In short
A managed self-hosted GitLab is a GitLab instance installed on your infrastructure that someone else takes responsibility for. We look after the instance, the runners, the container registry, object storage, single sign-on, backups with tested restores, major version upgrades and monitoring. Your team just has to use it.
What do we look after?
A self-hosted GitLab is not just the website where the code lives. It is a database, file storage, an image registry, runners that execute every pipeline and a good handful of secrets. If any of those pieces fails, the team can no longer deploy. This is what we monitor and maintain:
Instance
GitLab services, PostgreSQL, Redis and Gitaly, with their configuration as code.
Runners
Shared cache, resource limits, labels per type of job and autoscaling.
Registry
Container images with cleanup policies so that the disk does not fill up.
Object storage
Artefacts, packages, LFS and backups off the server disk.
Single sign-on
Access with your identity provider and leavers removed instantly.
Monitoring
Instance health, job queues, disk and certificates, with alerts.
Which architecture do we recommend?
You do not need the reference architecture for thousands of users if there are fifteen of you. We choose the installation method according to the size of the team and what you already have in place:
| Team size | Installation | Runners | Storage |
|---|---|---|---|
| Up to about 50 people | Omnibus on one machine, with PostgreSQL and Redis included | On one or two separate machines, with scaling if there are peaks | Object storage for artefacts, registry and backups |
| Medium-sized teams | Omnibus with the provider’s managed PostgreSQL | Autoscaling on machines or on Kubernetes | Object storage for everything that supports it |
| You already have Kubernetes | Official Helm chart, with the database and Redis outside the cluster | Kubernetes runner with limits per namespace | Object storage required |
In all three cases, the runners are kept separate from the instance: a pipeline that eats up the memory must not bring down the whole team’s GitLab.
Which problems do we come across most often?
When we take over an existing GitLab, one of these almost always turns up:
- The disk fills up: artefacts and registry images that nobody has cleaned up for years.
- The backup is useless: the database is backed up, but not the instance secrets, and without them the restore does not start.
- Version far behind: so many versions behind that several jumps have to be chained, one after another.
- Shared runners with no limits: one heavy job leaves the rest of the team waiting.
- Users who are no longer there: active accounts of people who have left, because there is no single sign-on.
- Expired certificates: the registry stops accepting images on a Monday morning.
How do we handle backups and upgrades?
A GitLab backup has two parts: the data (repositories, database, uploaded files) and the instance secrets. We back up both, off the server, and every month we restore the instance on a test machine to check that it starts and that the repositories are complete. The time it takes goes in the report.
Major GitLab versions arrive once a year and change things. We plan them following the official upgrade path, with a backup before each jump, a dry run if the instance is large and an announced window. Security releases are applied as soon as they come out.
In which account and with what access?
In yours. The machine, the storage, the managed database and the licence, if there is one, are in your company’s name with your provider: AWS, Google Cloud, Azure, Hetzner, OVH or your own server. We log in with a named user and administrator permissions only where they are needed, and the configuration stays in your repository, so that someone else can carry on if we ever part ways.
If you want to set up more than GitLab, such as the complete deployment platform, it is in internal platform and PaaS. If what you want is someone answerable for the whole platform every month, it fits with SRE as a service.
Where do we set it up?
In your account, with the provider you already use or the one that fits best. If the data has to stay in the EU, Hetzner and OVHcloud are the European options.
Providers we set it up on
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Own server
| Provider | How we set it up | Things to bear in mind |
|---|---|---|
| Hetzner | A cloud server with Omnibus and PostgreSQL inside the installation itself, because Hetzner does not offer a managed database. Hetzner Object Storage, which is S3-compatible, for artefacts, registry and backups. | The runners go on separate servers that are created and destroyed according to the load. |
| AWS | EC2 with Omnibus, RDS for PostgreSQL and S3. If you already have EKS, the official Helm chart with the database on RDS. | We keep an eye on egress traffic: registries with many downloads make it shoot up. |
| Google Cloud | Compute Engine with Omnibus, Cloud SQL for PostgreSQL and Cloud Storage. On GKE, the Helm chart. | Cloud SQL simplifies database backups and patches. |
| Azure | A virtual machine with Omnibus, Azure Database for PostgreSQL and Blob Storage, which GitLab supports as object storage. On AKS, the Helm chart. | A good fit if sign-in already goes through Microsoft Entra ID. |
| DigitalOcean | A Droplet with Omnibus, DigitalOcean managed PostgreSQL and Spaces, which is S3-compatible. | |
| OVH | A Public Cloud instance with Omnibus, an OVHcloud managed database for PostgreSQL and S3-compatible Object Storage. | |
| Own server | Omnibus on your server or in a Proxmox virtual machine, with PostgreSQL included. | The backup leaves the building, to S3 storage in the cloud. |
What is included
- GitLab CE or EE instance installed with the official method that suits your size: Omnibus, containers or Helm.
- Runners with cache, limits and autoscaling, on machines or on Kubernetes.
- Container registry with automatic cleanup of old images.
- Object storage (S3 or compatible) for artefacts, packages, LFS and backups.
- Single sign-on with your identity provider (SAML or OpenID Connect).
- Daily off-server backups, including the instance secrets, and a test restore.
- Planned major version upgrades, following the official upgrade path.
- Monitoring of the instance, the runners and disk space, with alerts.
Frequently asked questions
Which GitLab edition do you manage?
Both: Community Edition, which is free, and Enterprise Edition with or without a licence. If you have a paid licence, it remains yours and in your name; we just apply it to the instance.
How long does a major upgrade take?
It depends on how many versions have to be jumped and on the size of the database. We plan the official upgrade path, take a backup before each jump and let you know the window. On small instances it is usually a matter of minutes of downtime per jump.
Can we migrate from GitLab.com to our own server, or the other way round?
Yes. Groups, projects, issues and merge requests are migrated with GitLab's migration tools. Runners and CI variables are reviewed separately, because they do not always travel on their own.
Do you also manage GitHub or Gitea?
Gitea yes, also self-hosted. With GitHub there is no instance to maintain, but we can take care of your own runners and the pipelines.
Tell us about your case
In a free 20-minute call we look at where you are and where to start. No commitment.
Reviewed on