TeamCity alternative or GitLab CI/CD: which fits your build estate
If your code already lives in GitLab or you are willing to consolidate source hosting and CI into one self-managed platform, self-managed GitLab CI/CD is usually the better fit for a broader operating model. If you want to keep your current repositories and a dedicated build server with TeamCity's build chains, IDE integration and Windows agents, TeamCity remains the closer match, and the question becomes how to pay for it or what to replace it with. The decision turns on four points: where the code lives, how many build configurations and agents you run, whether Windows agents and IDE-driven workflows matter to your developers, and how much forge administration your team already carries. A GitLab move also means taking on the forge itself, including its upgrade path and backups, so count that work before you commit.
Choose GitLab CI/CD when the repositories are moving to GitLab anyway, or when you want pipelines defined per project in .gitlab-ci.yml and executed by GitLab Runner executors rather than maintained as a separate build estate. Its licensing differs from TeamCity's per-agent model: the Free tier costs 0 US dollars for self-managed installations, Premium is listed at 29 US dollars per user per month billed annually, and advanced CI/CD is a Premium feature according to the GitLab pricing page. Confirm with GitLab which tier your required pipeline features and support need, and whether your user count changes the total. Stay with TeamCity, or move only the build layer, when your build chains and Windows agents are central to your releases, because a forge-only move would leave those dependencies to be rebuilt by hand.
Before choosing, inventory the parts that determine effort: the number of build configurations, the agents per platform, the Windows and macOS build requirements, and any IDE-driven workflows your developers depend on. Then check whether the team can run GitLab's upgrade stops and backup procedures on a schedule, since these are ongoing duties. Ask any vendor or partner for a written scope covering migration of secrets, which must be re-entered because TeamCity's secure values cannot be exported, and of build history and artifacts. Use the answers to pick the option that matches your estate, not the one that looks cheapest on a license sheet.
Which option fits which scenario
This table maps common situations to the option that usually fits better, TeamCity or GitLab CI/CD on self-managed GitLab. Each row states the condition under which the advantage holds, so check that condition against your own environment before deciding. Read it as a starting point for a scoping conversation, not a final verdict.
| Scenario | Better fit | Why and under what condition |
|---|---|---|
| Code already hosted in GitLab | GitLab CI/CD | Pipelines, runners and the code share one permission model and one admin surface, provided your GitLab edition covers the CI features you need. |
| Standalone CI server for several repositories on mixed forges | TeamCity | TeamCity can build from several VCS hosts without moving repositories, while GitLab CI/CD is built around the GitLab project model; this holds if most repositories are not on GitLab. |
| Large build chains with snapshot dependencies | TeamCity | Build chains and snapshot dependencies are a native TeamCity concept; in GitLab you would model the same graph with parent-child pipelines, which needs redesign and testing. |
| Windows or .NET build agents | TeamCity | TeamCity has long-standing Windows agent support; confirm that GitLab Runner executors on Windows meet your toolchain and service requirements before choosing it. |
| One admin surface for code and pipelines | GitLab CI/CD | Repositories, merge requests, runners and pipeline settings live in one interface, which holds only if the team accepts running GitLab as the central platform. |
| Regulated environment that needs air-gapped operation | Either, after a proof of operation | GitLab documents offline and air-gapped installs, including guidance for its security scanners; confirm that TeamCity's licensing and updates work in your network before deciding. |
| Team that cannot take on GitLab platform administration | TeamCity or a lighter CI engine | GitLab is a full platform with its own upgrade paths, backups and database and storage components, so a small team may prefer a standalone CI server with fewer moving parts. |
How build chains and parent-child pipelines solve different problems
The core difference is architectural. TeamCity is a standalone CI server: it has its own agents, build configurations and build chains, and the server holds most of the definition of how work runs. GitLab CI/CD is built into the forge. The pipeline definition lives in the repository as .gitlab-ci.yml, and the work is done by GitLab Runner executors that pick up jobs from the GitLab instance. A team moving across this line changes where the logic lives. Agents become runners, build configurations become jobs, and chains become stages, needs relationships and parent-child pipelines triggered from a job. Confirm each TeamCity chain's snapshot dependencies and artifact dependencies against your own configuration before mapping them, because implicit ordering in a chain is easy to miss.
Parent-child pipelines solve a different problem than chains do. A chain groups related configurations on one server and passes artifacts between them. A parent pipeline in GitLab generates or triggers child pipelines, often one per component or service in a monorepo, and each child pipeline is versioned with the code it builds. That makes pipeline changes reviewable in the same merge request as the code change. The trade-off is that cross-project dependencies are handled through GitLab's own mechanisms, and they need to be designed rather than inherited from a server-side chain graph. Review your largest chains and ask which dependencies are real build inputs and which only reflect how the server was organized over time.
Feature parity matters less here than the operating model. Ask who will own runner fleets, executor images and runner tags, and how a team will keep the GitLab instance and its runners on the same supported version. GitLab's own documentation describes the Runner as a separate component with its own executors, so capacity planning, isolation of privileged jobs and secret scope become decisions your platform team makes explicitly. If your TeamCity estate depends heavily on Windows agents, on IDE-driven builds, or on a large number of chained configurations with fine-grained dependencies, plan those as separate workstreams and test them on a representative project before committing the whole estate.
Capabilities side by side
This table compares how TeamCity and self-managed GitLab CI/CD handle pipeline definition, dependencies, agents, secrets, access and air-gapped use. Where the supplied research does not confirm a TeamCity capability, the cell tells you what to confirm with JetBrains rather than stating an answer.
| Capability | TeamCity (commercial) | GitLab CI/CD (self-managed) |
|---|---|---|
| Pipeline definition | Build configurations defined in the UI or in Kotlin DSL or XML under versioned settings; confirm the exact export format with JetBrains | The .gitlab-ci.yml file in each repository, with includes and templates for reuse |
| Dependency management between builds | Build chains and snapshot dependencies; confirm how far chains extend across projects in your edition | Parent-child pipelines and multi-project pipelines triggered from other pipelines, with needs for job ordering |
| Agent or runner model | Build agents registered to the server and licensed per agent; confirm current agent counts against your license tier | GitLab Runner installed separately and registered to the GitLab instance, with shared, group or project scope |
| Container execution | Confirm with JetBrains which Docker and container build steps are supported natively and on which agent operating systems | Runner executors include Docker and Kubernetes; the executor is chosen per runner, not per pipeline |
| Artifact and log handling | Build artifacts and logs stored on the TeamCity server; confirm retention settings and export options for your version | Job artifacts and logs stored by the GitLab instance; retention is set per project or instance, and object storage can be configured |
| Secrets handling | Secure parameters stored on the server; confirm how values are encrypted and whether they can be read back by administrators | CI/CD variables with masking and protected options; secrets live on your own GitLab instance and runners |
| Access control | Project and role-based permissions; confirm group and SSO mapping options for your authentication setup | Roles on groups and projects, with authentication and authorization options documented by GitLab; higher-tier features extend governance |
| Air-gapped operation | Confirm with JetBrains which license checks, updates and plugin downloads need internet access | Documented offline installation and runner use; GitLab security scanners and GitLab Duo Self-Hosted have separate offline guidance |
| Security scanning and compliance | Confirm with JetBrains what security and compliance reporting is bundled in your edition | Scanning and compliance features sit in the Ultimate tier; the Premium tier covers advanced CI/CD and priority support |
Where the code, secrets and build data live
Both TeamCity and self-managed GitLab can run inside your own infrastructure, so hosting alone does not separate them. What separates them is where the forge sits, who controls identity, and which systems hold repositories, pipeline definitions, logs and artifacts. The cards below cover each boundary so you can check it against your own data residency and audit requirements.
Forge boundary, not hosting alone
TeamCity is self-hosted, so running it on your own servers is not the difference. The difference is that a self-managed GitLab keeps repositories, merge requests, pipeline definitions, job logs and artifacts in one system you operate. With TeamCity, the code stays in the Git host you already use, and TeamCity holds build configurations, logs and artifacts separately. Map every system that stores build data before you decide which boundary you want.
Offline and air-gapped installs
GitLab documents running self-managed instances in offline, air-gapped environments, with separate guidance for its security scanners and GitLab Duo Self-Hosted. Confirm with your architect which package sources, container images and scanner databases must be mirrored into the network before installation. Ask JetBrains for the equivalent offline installation and update procedure for TeamCity, including how agents receive updates without internet access.
Identity integration options
Self-managed GitLab supports several authentication and authorization methods, which lets you tie sign-in and group membership to your existing directory. Decide early whether developers, service accounts and runner registration follow the same identity path. Confirm with JetBrains which SSO, LDAP and role mapping options TeamCity supports, and whether they match the way your identity provider assigns groups.
Secrets and deployment credentials
Pipeline secrets are the highest-value data in any CI system. Hosted CI platforms have shown that a provider breach can expose environment variables, tokens and keys, so the question is where your secrets are encrypted and who holds the keys. In either option, decide whether deployment credentials live in the CI server, in GitLab CI/CD variables, or in an external secrets manager, and confirm how TeamCity stores secure parameters.
Audit trail and evidence
Compliance assessments usually ask who changed a pipeline, who approved a deployment and where the logs are kept. In GitLab, those records sit with the repository and project history in one platform. In TeamCity, you need to confirm how build logs, configuration changes and user actions are audited and how long they are retained. Put both answers into your control inventory before the migration.
Backup and hardening cover the whole forge
When GitLab is the forge, backup, restore and hardening guidance applies to repositories, the database, object storage for artifacts and logs, and the runners. Plan one backup scope that includes all of them and test restores. Keeping TeamCity alongside an existing forge means you maintain two sets of backup and hardening work, so list each system and its owner, and confirm the TeamCity backup and restore procedure with JetBrains.
What each option costs and what drives the bill
TeamCity licensing has two sides. Professional is free within fixed limits, so the bill starts only when a team needs more build configurations, pipelines or agents. Enterprise is licensed per build agent, so agent count is the main recurring driver. One-time costs are mostly the migration or re-platforming work, while the license or subscription renews on the term in your agreement.
- Professional limits: The free tier stops at 100 build configurations, 10 pipelines and 3 agents. Exceeding these limits is the usual trigger for a licensing decision.
- Per-agent Enterprise licensing: Each build agent adds to the recurring license count, so parallel builds and new target platforms raise the bill directly.
- True-up billing: If your contract includes Enterprise Plus true-up billing, agent use above the licensed count can add charges. Confirm how overages are measured and invoiced.
- Build volume: Build volume does not change the license count, but it determines how many agents you need to keep queue times acceptable.
Ask for the agent and configuration counts the quote assumes, the renewal term, the overage rules and whether any support tier is included.
Running TeamCity means paying for a server and the agents that run builds, and both are your infrastructure costs. The one-time work includes sizing the server, building agent images, configuring backups and migrating or exporting existing projects. Recurring costs include compute and storage for the server and agents, artifact and build history retention, and the staff time to patch the server and agent operating systems and apply TeamCity upgrades.
- Concurrent builds: The number of builds that run at the same time sets the agent count and the compute capacity behind it.
- Artifact and history retention: Longer retention of artifacts, logs and build history increases storage use and backup size.
- Platform mix: Windows, Linux and macOS agents have different image, licensing and maintenance requirements, so a mixed fleet costs more to operate.
- Repository and project count: Larger repositories and more build configurations increase server load, checkout time and disk use.
Ask the vendor or partner for the server and agent specifications the quote assumes, the backup and restore approach, the upgrade process and who is responsible for patching agent images.
GitLab self-managed licensing is priced per user, and the three tiers differ in what they include. According to the GitLab pricing page, Free costs 0 US dollars, Premium costs 29 US dollars per user per month billed annually, and Ultimate is custom priced. All three tiers are available for self-managed installations, so the choice depends on which CI/CD and security features your teams need. The main one-time cost is migration and import of projects and pipelines, and the main recurring cost is the seat subscription.
- Free tier: Costs 0 US dollars and suits teams that do not need the advanced CI/CD or priority support listed for Premium.
- Premium tier: At 29 US dollars per user per month billed annually, the pricing page lists advanced CI/CD and priority support. User count is the direct driver of this bill.
- Ultimate tier: The pricing page lists application security testing, software supply chain security, vulnerability management and compliance features. Pricing is on quote, so the seat count and feature set determine it.
- Seat definition: Confirm how GitLab counts guest users, service accounts and bot accounts before you estimate seats.
Ask for the seat count by tier, the billing period, how seat changes are prorated during the term and whether any add-ons or support levels are included.
Self-managed GitLab costs more in infrastructure and administration than the license alone suggests, and the size of the deployment drives most of it. GitLab's reference architectures run from 1,000 users at 20 API requests per second to 50,000 users at 1,000 API requests per second, and the documentation recommends a high availability strategy for 3,000 or more users. That design uses Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul. Stateful components such as PostgreSQL and Redis are not supported inside Kubernetes, so a Kubernetes deployment usually uses the Cloud Native Hybrid architecture with stateful services on VMs or managed services.
- Reference architecture size: Moving from a single-node or small design to a high availability design adds servers, storage and operational work.
- Upgrade cadence: GitLab ships a minor release monthly and patch releases twice a month, and it requires upgrades to pass through upgrade stops at x.2, x.5, x.8 and x.11.
- Security backports: Bug fixes go only to the current stable release, while security fixes also go to the previous two monthly releases, so staff must plan regular upgrades.
- Runners: GitLab Runner executes jobs on machines you operate, so runner count and size drive compute cost.
- Air-gapped operation: GitLab documents offline environments, which adds effort for update packages and scanner data.
Ask for the reference architecture the quote assumes, the high availability design, the backup and restore procedure, the upgrade plan and who operates the runners.
What running self-managed GitLab asks of your team
Running GitLab for CI means running a forge, and the forge sets the operating rhythm. GitLab ships a major release once a year and a minor release on the third Thursday of each month, with patch releases twice a month. Bug fixes are backported only to the current stable release, while security fixes also go to the previous two monthly releases. Your team therefore needs a standing upgrade cadence, a test environment that mirrors production, and a named owner who reads each release notes set. Since GitLab 17.5, upgrades must pass through required upgrade stops at versions x.2, x.5, x.8 and x.11, so a team that falls several releases behind cannot jump straight to the latest version. Check the GitLab upgrade paths documentation before you schedule any upgrade window.
The installation method is the first architectural decision. The Linux package bundles PostgreSQL, Redis and Sidekiq and is described as the most mature and scalable option, while the Helm chart, the GitLab Operator, Docker and source installs suit other platform standards. Reference architectures start at 1,000 users, and the documentation generally recommends a high availability strategy from 3,000 users, using Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul. Stateful components such as PostgreSQL and Redis are not supported inside Kubernetes, so a Kubernetes-based GitLab usually runs stateless services on the cluster and stateful services on virtual machines or managed services. Confirm the sizing with your own user count, peak concurrent pipelines and API request rate, and ask your vendor or partner to document the target reference architecture in writing.
A standalone TeamCity server has a smaller operating surface, but it is not zero. You still patch the server and agents, back up the configuration and build history, and plan capacity for agents. GitLab adds the repository, merge request, identity and package layers to that workload, so backup and restore, database maintenance and high availability all apply to the whole forge rather than only the build server. Plan for one dedicated owner for the GitLab instance and a documented backup and restore test before cutover, using the GitLab backup and restore documentation as the baseline. Budget for that staffing in the cost comparison, because the time spent on upgrades and capacity work is a recurring cost that does not appear on a license invoice.
How a move from TeamCity to GitLab CI/CD proceeds
The sequence turns a TeamCity estate into a tested set of GitLab pipelines, with every secret re-entered deliberately, every build verified against TeamCity's last known results and each repository switched only after it passes.
Inventory the TeamCity estate
Enable versioned settings on the TeamCity projects so that build configurations, templates, build chains and parameters are committed as a
.teamcitydirectory in Kotlin DSL or XML. Someone who owns the TeamCity server and a lead developer review the export together and mark each build configuration as migrate, merge, or retire. The step is done when every active configuration appears in a written inventory with its repository, trigger, agent requirements and downstream dependents. Ask the vendor or your DeployOpen contact to confirm which versioned settings format your TeamCity version produces before you start.Export build history, artifacts and logs
Decide which build history, artifacts and logs must survive the move for audit or release traceability, then export them from TeamCity to storage you control. Record test reports and release-related artifacts in a retention register that names the owner and the location of each file. This matters because GitLab starts with an empty build history, so the archive becomes the only record of earlier runs. The step is done when the archive can be opened and sampled by someone outside the build team, and the retention owner has signed off on what was kept and what was dropped.
Recreate secure values in GitLab
Treat every TeamCity secure parameter as a secret to be re-entered, not copied. TeamCity does not expose stored secure values for export, so the owner of each credential supplies it again as a masked or protected CI/CD variable in GitLab, scoped to the group or project that needs it. Rotate credentials that the team cannot confirm are still in use, and remove any that belonged to retired projects. The step is done when the secrets register lists each variable, its scope, its owner and the date it was last rotated, and a test pipeline on a non-production branch reads each one successfully.
Map configurations to GitLab pipelines
Translate each build configuration into a
.gitlab-ci.ymljob or an included template, and translate build chains and snapshot dependencies into parent-child pipelines orneedsrelationships. Keep stages that gate production as explicit jobs with protected branches or environments, so approval steps are visible in the pipeline and not hidden in a server setting. The engineer doing the mapping writes a short note for each chain explaining where the dependency moved. The step is done when every inventory item has either a pipeline definition in its repository or a documented decision to retire it.Move agents to GitLab Runner executors
Replace each TeamCity build agent with a GitLab Runner registered to the GitLab instance, choosing an executor that matches the workload, such as Docker for containerized Linux builds or a shell or VM-based executor where a build needs specific tooling or Windows. The platform team confirms that each runner has the network access, toolchains and tags the mapped jobs need, and that runners that build untrusted code are isolated from production networks. The step is done when every agent requirement from the inventory is matched by a tagged runner and a sample job has run on each one. Confirm runner support for each operating system with GitLab before you plan Windows builds.
Run both systems in parallel
Keep TeamCity running and let the GitLab pipelines run on the same commits, without deploying from GitLab yet. Compare artifacts, test counts, failure categories and deployment outputs for each pair of runs, and record every difference with a reason and a fix. This step gives the team evidence that the new pipelines behave the same way, including on failure paths, which are the cases most often missed. The step is done when each mapped pipeline has a run of matching results accepted by its owning team, and every open difference has an assigned owner.
Import repositories and cut over one at a time
Use GitLab's import documentation to bring each repository across, including its history and merge requests where the source supports it, then point the team's workflow at GitLab for that repository. Cut over one repository at a time, starting with a low-risk project, and keep its TeamCity configuration disabled but present so a rollback is possible. The step is done when the repository's pipeline runs from GitLab for its normal triggers and the repository owner confirms that releases and approvals work end to end.
Verify results before retiring TeamCity
Before any TeamCity project is removed, the team checks that each migrated pipeline has produced the expected results across a defined set of releases, that deployments and rollbacks work from GitLab, and that the archive and secrets register are complete. Security and compliance owners confirm that the retention, access and audit evidence they need is available from the new system. Retire TeamCity configurations only after this check is signed off in writing. The step is done when the sign-off record lists each project, its verification evidence and the date TeamCity access was removed.
Questions buyers ask before choosing GitLab CI/CD over TeamCity
What drives the cost of moving from TeamCity to GitLab CI/CD?
The cost of moving is driven by the work, not by a fixed fee. The main components are the GitLab self-managed platform (Free, Premium or Ultimate), the infrastructure to run GitLab and its runners, the conversion of build configurations into .gitlab-ci.yml pipelines, the re-entry of secrets, the export of build history, and the ongoing operations that follow. GitLab Free costs 0 dollars, while Premium is listed at 29 US dollars per user per month billed annually, and Ultimate is custom priced, according to the GitLab pricing page. Ask for a written scope that separates one-time migration work from recurring licenses, infrastructure and support, and ask each vendor to state which GitLab tier its quote assumes.
Can our team run the TeamCity to GitLab migration without outside help?
Yes, a team with strong GitLab and pipeline experience can run the migration itself, but the answer depends on the size of the TeamCity estate and on who owns the work. Build chains, snapshot dependencies, templates and agent requirements have to be mapped by hand, and each project needs its runners and variables checked. Teams that lack spare capacity often bring in a partner for planning, conversion, hardening and backups. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in the client's own infrastructure, and most engagements are fixed-scope with the scope, deliverables and timelines agreed in writing before work starts.
How long does a TeamCity to GitLab CI/CD migration take?
No duration can be given from the supplied facts, so treat any number from a vendor as unverified until it is tied to a scope. The length of a migration is set by the count of build configurations and build chains, the number of agents and their platforms, the volume of secrets and integrations, the required parallel run period, and the depth of the security review. Ask for a written plan with phases, exit criteria for each project, and the point at which TeamCity is switched off. Ask for the timeline in writing, with the assumptions behind it.
What does our engineering and administration team need to contribute?
The team needs engineers who can read the current TeamCity settings and write GitLab pipelines, plus administrators who can run GitLab, its PostgreSQL and Redis dependencies, and GitLab Runner. Someone must own the export of versioned settings, the review of pipelines and the sign-off on each cutover. Security staff should review how runners reach deployment targets and how secrets are scoped. Ask any partner to name the roles needed, the hours each role contributes and the handover material delivered at the end.
Do TeamCity Professional limits change the decision to move?
They can, because TeamCity Professional is free only within its limits, and exceeding them changes the cost picture. TeamCity Professional stops at 100 build configurations, 10 pipelines and 3 agents, and blocks new builds when agents exceed licenses. If your estate is near those limits, the choice is between buying TeamCity Enterprise or agent licenses and moving to GitLab CI/CD or another engine. Compare the recurring cost of each path, and include the GitLab tier you would need for advanced CI/CD and priority support, which the pricing page lists for Premium.
Can secrets and build history be carried over to GitLab?
Secrets usually cannot be exported as plain values, so they are normally re-entered in GitLab and rotated as part of the cutover. Many CI platforms expose secret names but not their values, and TeamCity secure parameters follow the same pattern in practice, so confirm the behavior in your own instance. Build history and artifacts also need a deliberate export, because the record is not a migration target by default. Ask the partner to list every secret, its owner and its rotation plan, and to state how logs and artifacts will be archived and where they will be stored.
Can self-managed GitLab run in an air-gapped network?
GitLab documents running self-managed instances in offline, air-gapped environments, with separate guidance for running its security scanners and GitLab Duo Self-Hosted offline. The practical questions are how packages, runner images, container images and scanner data reach the isolated network, and how updates are staged. Confirm each feature you rely on against the offline environments documentation, and ask for a written design that lists every artifact the network must import and how those imports are verified.
What does running self-managed GitLab require for upgrades?
A self-managed GitLab needs a planned upgrade cadence. GitLab ships a major release yearly, a minor release on the third Thursday of each month and patch releases twice a month, and it requires upgrades to pass through required upgrade stops. Since GitLab 17.5 these fall at versions x.2, x.5, x.8 and x.11, for example 18.2, 18.5, 18.8, 18.11, 19.2, 19.5, 19.8 and 19.11. Security fixes are backported to the previous two monthly releases, while bug fixes go only to the current stable release, so you need a staging environment and a documented rollback path. Ask the partner for the upgrade runbook and the backup restore test it will include.
How DeployOpen helps evaluate, implement or migrate
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For TeamCity vs GitLab CI/CD, we start from a written scope that compares your build chains, agents and secrets with GitLab pipelines and runners before any change is made.
How we scope
- Inventory your TeamCity build configurations, build chains, agent pools and licensing position before choosing a target
- Agree in writing which projects move to GitLab CI/CD, which stay on TeamCity and what is out of scope
- Confirm GitLab edition, hosting method and offline requirements with your security and compliance owners
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
How we build
- Map build chains and snapshot dependencies to parent-child pipelines and GitLab Runner executors in a non-production environment
- Plan runner placement, network access and agent isolation for Windows or Linux builds as your scope requires
- Migrate secrets by re-entering values into GitLab CI/CD variables, since existing values cannot be exported from TeamCity
- Test pipelines against real repositories and document any behavior that differs from TeamCity before cutover
How we hand over
- Deliver pipeline definitions, runner configuration, backup and restore procedures and a tested rollback plan
- Document a migration inventory showing each TeamCity configuration, its GitLab equivalent and its owner
- Provide evidence for your compliance assessments, while independent auditors and certification bodies issue any reports
- Walk your platform and development teams through daily operation, upgrades and troubleshooting
How we support
- Ongoing support, GitLab upgrades and continuous security testing are available as retainers after handover
- Plan upgrades around GitLab's required upgrade stops and maintenance policy, confirmed against your version at the time
- Review runner access, variable scopes and pipeline permissions as your team and repositories change
- Scope retainer work in writing so responsibilities for patches, backups and incidents stay clear
