Sizing a GitLab server correctly

Measure workload

Project and user counts explain only part of the load. Measure repository sizes, LFS, registry, artefacts, concurrent web use and background work. Imports, backups and maintenance add peaks. GitLab’s official requirements are a starting point; dependable sizing comes from observed use and a growth allowance.

Treat runners separately

CI runners execute workload-defined jobs and can create bursty CPU, memory, I/O and network demand. Record parallel jobs, duration, images, caches and artefacts. Separate runners from the main GitLab system where isolation, scaling or security boundaries require it. Check runner utilisation before increasing the size of the web node.

Know data classes

Repositories, database, uploads, LFS, artefacts, package and container registries grow differently. Define retention and cleanup deliberately. A full volume can stop more than new commits. Monitor capacity and trends rather than only the login page’s availability.

Check upgrade paths

GitLab upgrades can require intermediate versions and database migrations. Document source version, edition, integrations and extensions. Test the path on a copy and plan maintenance and rollback. Secrets, webhooks, OAuth integrations and runner tokens belong in the inventory, not public documentation.

Backup and restore

GitLab documentation distinguishes application backup and configuration. Check which external data, such as object storage or a registry, requires separate protection. A restore must match the version and should be rehearsed in isolation. Record the time required and any manual steps.

Include integrations in the system inventory

List webhooks, identity providers, package sources and deployment targets. Record each one's purpose and owner without placing secrets in widely accessible documentation. Changed addresses or certificates can affect these connections during migration. Test a complete path from commit to an approved test deployment. For ongoing operation, establish who replaces expiring tokens and how permission changes are reviewed. Working repository access alone does not cover these dependencies.

A small team can generate substantial CI load

For example, a development team has eight active users and twenty repositories. That sounds small. Yet building several containers and running extensive integration tests on every merge can produce many concurrent jobs. Most of the required compute then sits on runners. Increasing resources for the GitLab web application alone will not shorten that job queue or solve constraints inside a build environment.

Inventory representative pipelines: duration, concurrency, memory, temporary storage and transferred artefacts. Distinguish recurring peaks from rare exceptional runs. You can then decide which jobs need to execute concurrently and where queuing is acceptable. This shows which jobs need the most processing capacity.

Separate runners by trust and purpose

A runner executes project code, so its design is more than a performance question. A build for an external contribution should not receive the same access as an approved production deployment. GitLab explicitly documents the risks of different executor configurations. Choose an execution model around the required trust level and examine the networks, files and secrets that jobs can reach.

For each runner group, specify which projects may use it and whether jobs can access production. Keep build artefacts separate from credentials and sensitive variables out of logs. A privileged container is not a general security boundary. Plan cleanup after jobs and replacement of compromised runners too. Review these settings regularly as projects and access requirements change.

Consider data growth and restoration together

Repositories are often only part of storage demand. Container images, packages, LFS objects and build artefacts can grow differently from source code. Set a retention rule for each class of data. Which artefacts must remain available for a release, and which test outputs can expire quickly? Cleanup should be understandable and must not remove delivery assets that are still required.

For recovery, inventory every storage location and its associated backup. Check whether configuration, keys or external object storage need separate protection. A useful test covers repository access, sign-in, selected integrations and a controlled pipeline run using test credentials. Record the required GitLab version and how runners will reconnect. This shows whether recovery supports the whole working environment or only some of its data, and gives the team a repeatable acceptance exercise.

• Size the main instance and runners separately, with clear operational ownership.
• Record concurrency and duration for representative pipelines.
• Limit production access to the jobs and runners intended for that purpose.
• Check retention and restoration for repositories, registry and artefacts separately.

Prepare the request

Provide active users, projects, volume, growth, CI concurrency, integrations and desired responsibility boundaries. NUXOA can then plan the main system and runners separately. The six example configurations on the product page provide a starting point. Your quote is tailored to your requirements.