Full Control Over the Entire Development Lifecycle: Why Teams Need Self-Managed GitLab

Picture a typical development team. One developer is writing a new feature, another is fixing a bug, a third is preparing a release. Each has their own version of the code, and the changes need to be merged, reviewed, tested, and only then shipped to production.

While the team is small, some of these processes can be done by hand. As the project grows, questions arise: who made this change, why did the build break, which version is on the server right now, can the release be rolled back safely, and where do we look for a vulnerability in a dependency?

At this stage, using Git purely for storing code is no longer enough: a full-fledged engineering platform is needed around it. One of the best-known examples of such a platform is GitLab.

How GitLab Works

GitLab helps organize the entire software development cycle: from writing code and team discussion to automated testing and rolling out the finished application. To do this, the platform combines version control, an issue tracker, code review, and automation tools.

At the core of the platform is Git. It is a distributed version control system that tracks changes to files, keeps a history of work, and merges the results of several developers. GitLab extends Git with a convenient web interface and services that simplify teamwork and take routine work off engineers' hands.

Core GitLab Components

• Repository: the storage for the project's source code and its edit history. Developers clone the repository to their computers, work with the code locally, and push changes to the server.
• Project: a workspace that brings together the repository, issues, access settings, discussions, and CI/CD pipelines.
• Group: a tool for combining several projects and centrally managing member permissions. Convenient for companies developing several products at once.
• Branch: a separate line of development that allows changes to be made in isolation from the main code.
• Commit: a recorded set of changes with a precise history of what was edited and when.
• Merge Request (MR): a request to merge changes from a working branch into the main one. It allows colleagues to review the code, leave comments, and run tests before the changes are published.
• Issue: a task, bug, or suggestion for the project. Helps the team distribute work and track statuses.
• Pipeline: an automated chain of actions, including code style checks, test runs, building, and deploying the application.
• GitLab Runner: the component that executes the instructions from the CI/CD pipeline on virtual machines or servers.

How Work with Code Is Organized

Work in GitLab is built around collaborative development and managing changes to code. Developers can work on different tasks in parallel, save changes in separate branches, and propose them for inclusion in the main version of the project.

GitLab helps track who made which changes, review code before merging, and reduce the risk of errors in team development.

The process looks like this:

1. Cloning the repository. The developer downloads a copy of the project to their computer.
2. Creating a branch. A separate branch is created for a new feature or bug fix so that the working code is not affected.
3. Making changes. The code is edited locally, checked, and recorded in commits.
4. Pushing to the server. The finished branch is sent to GitLab with the git push command.
5. Opening a Merge Request. The author describes the essence of the changes and links them to an issue.
6. Code review. Colleagues examine the code, ask questions, and request revisions if necessary.
7. Automated checks. GitLab CI/CD runs tests and the build, displaying the results directly in the Merge Request interface.
8. Merging. After approval and successful tests, the code is merged into the main branch.
9. Deployment. The configured pipeline rolls out the updated service to a test or production environment.

In this way, GitLab brings the main stages of development together in a single workspace.

How GitLab Helps the Team

In collaborative development, it is important not only to have access to the source code, but also to understand who is making changes, how they are reviewed, and how they get into the main version of the project. GitLab helps organize this process: it combines work with code, discussion of changes, task management, and access control in one space.

• Single storage. The team works with a shared repository where the entire project history is kept.
• Parallel development. Isolating changes in branches rules out accidentally overwriting someone else's code.
• Transparent code review. Architecture discussions happen directly in the context of the changes made.
• Task control. Issues link a specific line of code to a business task.
• Access management. Administrators flexibly configure member permissions and protection of key branches.

As a result, GitLab makes team development more organized and transparent.

How GitLab CI/CD Works

CI/CD helps check and deliver code automatically, without manually running scripts on the server.

• CI (Continuous Integration): automatic building and testing every time code is pushed. Allows errors to be found at an early stage.
• CD (Continuous Delivery / Deployment): automatically preparing the application for release or deploying it directly to production servers.

The process is configured through the .gitlab-ci.yml file in the repository, and the commands themselves are executed by the GitLab Runner component.

Git and GitLab: Not the Same Thing

Git, a distributed version control system, stores the project's change history. With it, you can create branches, compare versions, merge changes, and return to previous states of the code.

GitLab uses Git as its foundation and solves a broader set of tasks. Roughly speaking:

• Git manages code versions.
• GitLab ties code, teamwork, CI/CD, security, planning, and application delivery into a single process.

If Git is like a detailed change log for a book, then GitLab is like a publishing house. In addition to the log, it has an editorial office, quality control, a production line, and release control.

What Happens Inside GitLab

The value of GitLab is not in any single tool. It is in the fact that the different stages of development are gathered in one loop.

Repository and Change History

Source code is stored in Git repositories; the team works with branches, commits, and change history. The project gets a single source of truth: instead of archives in messengers and manual file copying, everyone works with one version control system.

Merge Requests and Code Review

Changes are submitted through Merge Requests. Developers discuss the code, leave comments, conduct reviews, and configure approval rules without which changes will not reach the target branch.

The process looks roughly like this:

code change → review → checks → merge → build → deployment.

CI/CD

GitLab automates building, testing, and delivering the application using CI/CD pipelines. The jobs themselves are executed by GitLab Runner, so the architecture is usually as follows:

GitLab → Pipeline → GitLab Runner → Job → result.

In a small installation, the Runner can sit next to GitLab. In more serious infrastructure, it is moved to separate virtual machines and scaled independently.

The reason is that the GitLab server and the Runner have different jobs. The server serves the platform itself, the repositories, and background processes, while the Runner executes CI/CD jobs.

Security

Application Security tools embed security checks directly into the development process:

• SAST looks for potential vulnerabilities in the source code.
• DAST tests the already running application.
• Dependency Scanning looks for known vulnerabilities in third-party dependencies.

There are also checks for containers, secrets, and infrastructure as code.

Keep in mind that not all security functionality is available on all tiers. For example, basic SAST is included in Free, while DAST and Dependency Scanning belong to Ultimate.

In this way, GitLab becomes part of a built-in security process, beyond simply storing source code.

Task Management and Documentation

For planning, GitLab has Issues, Issue Boards, and other tools. An issue can be linked to code, a Merge Request, a pipeline, and the result of the work. For project documentation, there is a Wiki.

Information that is usually scattered between a Git service, a task tracker, a CI/CD system, and a separate knowledge base lives in one platform.

GitLab: What Its Main Argument Is

Git, code review, and CI/CD are available from other services too. Other major DevOps platforms also offer built-in automation and task management.

So GitLab's main argument is different. It is not that only GitLab can do CI/CD. It is that GitLab deeply connects the different stages of the development lifecycle in one loop.

For the team, this means fewer gaps between tools. A developer starts with an Issue, continues in a Merge Request, waits for the CI/CD results, sees security findings, and moves on to the release without leaving the main working loop.

GitLab.com, Self-Managed, and Dedicated

GitLab offers several hosting options.

GitLab.com

GitLab.com works as SaaS. There is no need to install GitLab: the infrastructure and the platform are maintained by GitLab itself. This is the simplest option for a team that cares more about getting started quickly than about managing the platform on its own.

GitLab Self-Managed

With Self-Managed, the organization itself installs, administers, and maintains its own GitLab instance. This can be a virtual machine, a physical server, or more complex distributed infrastructure.

GitLab itself emphasizes: with Self-Managed, the organization manages the infrastructure, operating system, network, storage, security, GitLab itself, and ongoing maintenance.

So Self-Managed means more than “GitLab on your own server.” It is your own platform, for which the team is responsible.

GitLab Dedicated

GitLab Dedicated is designed as a single-tenant SaaS option for large and regulated organizations. Organizational and infrastructure operations are handled by GitLab, but the environment is dedicated to a specific customer.

When a Company Really Needs Self-Managed

Self-Managed is not “better” in itself. It is needed when control over your own infrastructure gives the organization real advantages. For example, when:

• data must reside in a specific jurisdiction;
• the network perimeter and internal integrations need to be controlled;
• CI/CD must run in a closed or isolated environment;
• a custom Runner architecture is required;
• there are corporate requirements for redundancy, monitoring, and access;
• the data storage and infrastructure architecture needs to be defined independently.

In such scenarios, Self-Managed allows you to build the platform around your own infrastructure and security requirements.

What to Consider When Launching Self-Managed

A common mistake: assuming that it is enough to create a VM and install the package.

Inside GitLab, several components are running, including GitLab Rails, Sidekiq, Gitaly, PostgreSQL, Redis, and other services.

Under light load, GitLab can run on a single server. For example, the official reference architecture for up to 1,000 users assumes about 8 vCPU and 16 GB RAM for a typical load profile. As the load grows, the components can be separated and scaled independently.

The number of users is not the only criterion, though. RPS, the size and number of repositories, monorepos, CI load, and other project specifics all matter.

CPU and RAM

GitLab's resources determine the performance of the platform itself. The Runner's resources determine the speed and parallelism of CI/CD jobs. That is why, in a production architecture, it is often worth separating the GitLab Server and the GitLab Runner infrastructure.

Storage

For GitLab, disk capacity matters, and I/O performance matters separately.

Gitaly is responsible for working with Git repositories. It can sit on the same server, and as the system grows, it can be moved to separate infrastructure.

For production, fast SSD storage is usually chosen. For demanding workloads, NVMe may be preferable, but the GitLab architecture itself does not require NVMe.

Backup and Recovery

Hosting it yourself also means taking responsibility for backups yourself. You need to determine in advance:

• what exactly is backed up;
• where the backups are stored;
• how often they are created;
• how long they are retained;
• how recovery is tested;
• what happens in the event of a complete loss of the VM or storage.

A backup whose restore has never been tested cannot be considered full data protection.

Monitoring and Updates

Self-Managed requires constant maintenance. You need to monitor the state of GitLab, storage, database, Runner, and network components, as well as regularly install updates and security patches.

New versions of GitLab are released monthly. For example, GitLab 19.4 was released on September 17, 2026.

That is why Self-Managed should be viewed as a platform that is continuously maintained, not as a one-time installation.

Comparison: GitLab, GitHub, and Bitbucket

All three platforms work with Git, but they suit different tasks and infrastructure requirements.

What to Choose for Your Needs

• GitLab suits companies that need a single isolated loop: repository, task management, security, and CI/CD in one platform (including hosting on their own servers).
• GitHub is convenient for working with open source and using ready-made GitHub Actions.
• Bitbucket is chosen by teams whose processes are tightly tied to Jira and Atlassian products.

Advantages and Nuances of GitLab

Advantages

1. All tools in one place. There is no need to separately assemble and connect a third-party task tracker, a container registry, and a build system.
2. CI/CD automation. Frees engineers from routine work and speeds up the release cycle.
3. Closed deployment option (Self-Managed). Allows the platform to be deployed in the UzCloud sovereign cloud for full control over data and compliance with Law ZRU-547.

What to Keep in Mind

1. Learning curve. The platform contains many features, so it takes time to master.
2. Resources and maintenance. With self-hosted deployment, it is important to correctly size the server (CPU, RAM, disks) and ensure regular backup maintenance.

What's New in GitLab in 2026

In 2026, GitLab is actively developing AI and agentic automation.

AI Moves from Suggestions to Completing Tasks

In the GitLab Duo Agent Platform, AI helps write code and automates complex tasks.

In GitLab 19.4, GitLab Duo CLI received /goal in public beta. The developer describes the desired end result, and the agent performs a sequence of actions and checks whether the result has been achieved. The same release introduced MCP server tools for automating operations with CI/CD, Merge Requests, work items, vulnerabilities, and projects.

The working model itself is changing:

• previously, the developer gave the AI a specific instruction;
• now, more and more often, the AI can be given an end goal.

AI Participates in Security Remediation

GitLab is developing automatic remediation of security issues. For example, the system can create Merge Requests to update vulnerable dependencies and use AI to fix the breaking changes that the update brings with it. The changes still go through review rather than being merged automatically without verification.

Security as Part of the Overall Engineering Process

GitLab is gradually moving toward a model where security findings, planning, code, pipeline, and AI automation form a single workflow. For large teams, this provides a unified control loop instead of several disparate security tools.

Why Self-Managed Is Attractive to Local Companies

For a company operating in Uzbekistan, its own GitLab can be attractive beyond DevOps alone. Self-Managed allows the company to choose where the infrastructure is hosted, how the network is set up, and which internal systems get access to GitLab and the Runner.

A separate question: data residency.

The current version of the Law of the Republic of Uzbekistan “On Personal Data” requires certain categories of personal data to be stored on the territory of Uzbekistan. These include biometric and genetic data, as well as data of individuals using the services of telecommunications operators operating in Uzbekistan. Other categories of data may be stored and processed outside the country under the conditions established by law.

So a server in Uzbekistan does not by itself guarantee compliance: the requirements depend on the type of data, the organization's role, and the specific processing architecture.

The practical advantage for business lies elsewhere: on local infrastructure, data storage and processing can be set up within the country whenever a specific scenario requires it.

GitLab Self-Managed on UzCloud

Launching Self-Managed does not necessarily mean that the entire infrastructure has to be built from scratch.

The UzCloud Marketplace already offers ready-made GitLab and GitLab Runner images on Ubuntu 24.04. The catalog also includes other development and DevOps tools, including Docker and Harbor.

Instead of a long chain of manual steps:

choose a server → install the OS → configure dependencies → install GitLab → configure the Runner → prepare the infrastructure

you can take a ready-made image and move straight to configuring and operating your DevOps platform.

UzCloud Marketplace is designed as a catalog of ready-made servers with pre-installed software that can be deployed in a couple of clicks.

The infrastructure remains under the customer's control: the virtual machine, network, resources, access, and further configuration are determined by the architecture of the chosen cloud environment.

Why This Is Convenient for Development Teams

A small team can use GitLab as a ready-made platform for:

• repositories and code review;
• CI/CD;
• Container Registry;
• task management;
• automated security checks;
• internal documentation.

On top of this, large teams build separate Runner infrastructure, backups, monitoring, and integration with corporate IAM and internal systems.

UzCloud does not replace GitLab here. It is the infrastructure foundation on which the company deploys and operates GitLab itself.

What to Choose: GitLab.com or Self-Managed?

For most small teams, the choice comes down to a clear guideline:

• You don't want to deal with infrastructure: choose GitLab.com.
• You need control over your own infrastructure, network, and data location: consider Self-Managed.
• You need an isolated single-tenant environment without operating GitLab yourself: look toward GitLab Dedicated.

GitLab itself distinguishes these options by operating model and subscription.

Take the licensing model into account as well. For example, the five-user limit applies to GitLab.com Free for private top-level namespaces, not to every Self-Managed deployment. The paid Premium and Ultimate tiers have their own licensing model and their own feature set.

Conclusion

In 2026, GitLab is already much more than a remote Git repository. It is a platform that connects:

code → code review → CI/CD → security → artifacts → deployment → planning → AI automation.

Not every team needs Self-Managed. It is justified when control over infrastructure, network, data location, and operations matters more than the simplicity of SaaS.

Companies that need such control can avoid building the entire technological foundation themselves thanks to cloud infrastructure. In this scenario, UzCloud serves as the foundation for your own GitLab: from a ready-made image in the Marketplace to a full production deployment with dedicated resources, Runner infrastructure, network, backups, and monitoring.

So today the question is broader than where to store Git. It is about how to build a managed and secure environment where the entire development lifecycle, from the first commit to production, remains under the team's control.

Launch Your GitLab in Uzbekistan

If your team needs a reliable and isolated Self-Managed GitLab, you can skip the manual OS installation, dependency assembly, and package configuration.

The UzCloud Marketplace already offers ready-made GitLab and GitLab Runner images on Ubuntu 24.04.

Go to the UzCloud Marketplace catalog, choose the image you need, and launch a pre-configured server in a couple of clicks — so you can move straight to configuring your DevOps platform on Uzbekistan's sovereign infrastructure.