Which to choose: Bitbucket Pipelines or GitLab CI/CD?
GitLab CI/CD fits when both the repositories and the pipelines are leaving Atlassian and you are ready to operate a GitLab instance yourself. Bitbucket Pipelines stays the simpler choice when repositories remain in Bitbucket Cloud and the only problem is the cost of self-hosted runner slots, because a separate CI engine such as Woodpecker CI can run your builds without a forge migration. The first question is therefore whether the source code moves. If it does not, GitLab CI/CD means a second forge to run, and the case for it rests on that forge, not on the pipelines alone.
Next, decide where data and builds must live. If the organization needs offline or air-gapped operation, check GitLab's offline environment guidance and confirm with your security team which GitLab features, including its security scanners, work without outbound connections in your network. Teams with data residency rules should also confirm where GitLab backups, artifacts and runner logs will be stored, since Bitbucket Pipelines keeps artifacts for at most 14 days and that limit does not carry over to a self-managed GitLab.
Then assess team capacity. A self-managed GitLab needs people to handle upgrades on the required upgrade stops, backups and restores, database and Gitaly operations, and the monthly and patch release cycle. Confirm that someone owns this work before you choose the Premium or Ultimate tier, because the tier decides which CI/CD and security features you get, and price is set per user per month for Premium and by custom quote for Ultimate. Ask your GitLab representative for a written quote that separates subscription, infrastructure and staff time.
Which option fits which scenario
This table matches common situations to the better fit between staying on Bitbucket Pipelines and moving to a self-managed GitLab CI/CD. Read each row for the condition that decides the choice, then confirm the points marked for checking against your own repositories and environment before committing.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Light builds, repositories stay on Bitbucket Cloud | Stay on Bitbucket Pipelines for now | Build volume is low, no self-hosted runners are needed and repository hosting is not under review. Moving CI alone to GitLab would mean keeping two forges in sync. |
| Moving repositories and CI together | Self-managed GitLab CI/CD | The team wants one system for code, merge requests, pipelines and registry. Plan the repository import and the translation of bitbucket-pipelines.yml as one project. |
| Air-gapped or tightly regulated environments | Self-managed GitLab CI/CD | Builds and source must run without internet access. GitLab documents offline installation, so confirm the offline scope for your edition and the features you need. |
| Single DevSecOps platform across code, CI and security scanning | Self-managed GitLab CI/CD, with a tier check | Scanning and compliance features depend on the GitLab tier. Confirm which tier includes each feature you need before comparing costs. |
| Small team without platform staff | Stay on Bitbucket Pipelines or a managed option, unless someone owns upgrades | A self-managed GitLab instance needs regular upgrades, backups and monitoring. Without an owner for those tasks, the operating burden can outweigh the benefit. |
| Strict control over runners and build infrastructure | Self-managed GitLab CI/CD with GitLab Runner | Your team will run its own runners. Confirm how runner capacity, executor types and access controls will be managed in your environment. |
Free, Premium and Ultimate: what each GitLab tier adds to CI/CD
GitLab Free costs 0 US dollars and is available for self-managed installations. It covers the core of GitLab CI/CD: pipeline definitions in .gitlab-ci.yml, GitLab Runner for executing jobs, and the repository, merge request and issue features that pipelines attach to. For many teams replacing Bitbucket Pipelines, the Free tier is enough to run the build and test stages that previously ran in Bitbucket.
- Pipeline definitions: Jobs, stages and dependencies are written in
.gitlab-ci.yml, which lives in the repository alongside the code. - Runners you operate: GitLab Runner executes jobs on machines you manage, with executors such as Docker and Kubernetes.
- Core repository workflow: Merge requests can display pipeline status, which gates merges when you configure it that way.
- No per-user fee on the license: Your costs are the servers, storage and staff time, not a GitLab subscription.
- Limits to check: Confirm which CI/CD functions are included at this tier, since some advanced features sit in paid tiers.
Before relying on the Free tier, ask GitLab to confirm the current list of CI/CD features that are included, and check it against the pipeline features your Bitbucket Pipelines setup actually uses.
GitLab Premium costs 29 US dollars per user per month, billed annually, and the pricing page lists it for self-managed installations. The pricing page associates Premium with advanced CI/CD and priority support. Your license bill grows with the number of users, so the cost depends on how many people need the platform, not on the number of builds you run.
- Advanced CI/CD: The pricing page lists advanced CI/CD features for Premium, which you should map against your current pipelines.
- Priority support: Premium includes priority support from GitLab, which matters if your teams cannot wait for community answers during an outage.
- Per-user billing: The fee is per user per month billed annually, so adding contractors or service accounts that count as users changes the total.
- Recurring cost: The license fee recurs every year, on top of the servers and staff time needed to run the instance.
- Pricing details: Ask GitLab how it counts users, whether it applies to all instances and how renewals are priced.
Before you choose Premium, list the advanced CI/CD features you need and confirm with GitLab that they are included at this tier.
GitLab Ultimate is custom priced, so the cost comes from a quote rather than a published list price. The pricing page places application security testing, software supply chain security, vulnerability management and compliance features in this tier. It matters most to organizations that need security scanning and compliance evidence inside the same platform that runs their pipelines.
- Application security testing: The tier includes application security testing features that run as part of the pipeline.
- Software supply chain security: Features in this area relate to tracking dependencies and the provenance of build outputs.
- Vulnerability management: The pricing page lists tools for triaging and tracking findings across projects.
- Compliance features: Compliance-related capabilities are listed for Ultimate, which you should compare with your control requirements.
- Custom quote: Request a written quote that names the users, instances and features included.
Before buying Ultimate, have your security team confirm which scanners and compliance features they need and ask GitLab to confirm where each one is placed in its current tier structure.
Where your pipelines, secrets and data live
Moving CI from Bitbucket Pipelines to a self-managed GitLab changes where build logs, secrets and artifacts are stored and who operates them. The cards below cover the decisions that follow from that change, from data location and offline operation to identity, licensing and the compliance work that stays with your organization.
Data location moves to your servers
Bitbucket Pipelines runs on Atlassian's cloud, so pipeline logs, variables and artifacts sit in a vendor-operated service. A self-managed GitLab instance keeps repositories, job logs, artifacts and the PostgreSQL database on infrastructure you choose. Check where backups are stored, who holds the administrator role on the host and which regions your data may reside in. Also confirm how GitLab Runner machines reach the instance, since runners hold job-time credentials.
Air-gapped operation is documented
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. This matters if your pipelines must run without internet access. Confirm which scanners, container images and runner dependencies you need, and plan how security database updates and package sources will be transferred into the enclosed network.
Identity through GitLab authentication
Bitbucket users sign in through Atlassian accounts, while a self-managed GitLab instance can authenticate against its own user store or external identity providers, as described in its authentication and authorization documentation. Decide which identity source is the source of truth for developers and service accounts, how group membership maps to project permissions, and how departing staff lose access to repositories, runners and deployment variables.
Open-core licensing split
GitLab's source repository is open core. Content under the ee/ directory is licensed under the GitLab Enterprise Edition license, while content outside it is available under the MIT Expat license. Your legal team should confirm which features your tier includes, what the license permits for internal modification and how that affects any custom patches you plan to maintain.
Compliance stays with your organization
Moving CI to a self-managed platform moves control evidence to you. Access reviews, change records, secret rotation, backup restore tests and log retention become your responsibilities, and GitLab's documentation does not make your instance compliant on its own. Ask any implementation partner for a written scope covering these controls, and ask independent auditors which evidence they expect. DeployOpen prepares systems and evidence, but audit reports and certifications come from independent auditors and certification bodies.
What running GitLab yourself involves
The first decision is how to install GitLab. The Linux package is the method GitLab describes as the most mature and scalable option, because it bundles PostgreSQL, Redis and Sidekiq, so one package upgrades and configures the whole stack. The Helm chart, the GitLab Operator, Docker and installation from source are also documented, but each shifts more of the component management onto your team. Pick the method before sizing hardware, since it determines how backups, upgrades and component failures are handled. Confirm with your platform team which method matches your existing configuration management and Kubernetes standards.
Sizing starts with the GitLab reference architectures, which run from 1,000 users at 20 API requests per second up to 50,000 users at 1,000 API requests per second. Map your user count and your peak automation load, including CI jobs that poll the API, to the nearest tier. GitLab generally recommends a high availability strategy at 3,000 or more users, built on Gitaly Cluster with Praefect for repository storage, PostgreSQL with Patroni, Redis Sentinel and Consul. That is a multi-node design with its own operators, monitoring and failover tests, so ask your vendor or partner to price it as a separate workstream from the initial install.
Plan the runtime placement before you commit to Kubernetes. GitLab's reference architecture documentation states that running stateful components such as PostgreSQL and Redis inside Kubernetes is not supported. The Cloud Native Hybrid pattern fits this constraint: stateless GitLab components run on Kubernetes, while PostgreSQL, Redis and Gitaly run on virtual machines or managed services. If your organization wants everything in one cluster, confirm the supported topology with GitLab before design sign-off, because it changes the backup, restore and staffing model. Teams in air-gapped networks should also check GitLab's offline environment guidance early, since packaging and update delivery change in that setting.
How often GitLab releases and what upgrades demand
How often does GitLab publish a major release?
GitLab ships one major release each year, and the maintenance policy plans GitLab 20.0 for May 2027. A major release is the point where breaking changes and removed features are most likely, so it is the version to read release notes for before scheduling work. Major versions do not replace the monthly cadence below, so your team still needs a routine for minor and patch updates between them. Confirm the planned date and any deprecations on the maintenance policy page before you set a budget or a window for the year.
When does GitLab release its monthly minor version?
GitLab releases a minor version on the third Thursday of each month. Minor releases add features and fixes, and they are where most of your routine upgrade effort will fall. Put the third Thursday on the operations calendar so someone reviews release notes, checks the upgrade path and schedules a maintenance window before the release reaches production. Staging a minor release on a test instance first gives you a realistic check of runner and pipeline behavior before production changes.
How often are GitLab patch releases published?
GitLab publishes patch releases twice a month. Patches carry bug fixes and security fixes for the versions that are still maintained, so they arrive more often than minor releases. Security fixes deserve the fastest response, because they are backported to more than one line. Plan a fixed patch review each cycle, with an owner who can decide quickly whether an instance needs an out-of-cycle update. Your team should track both patch dates and advisories, since a patch that affects your deployment may need to go out sooner than the routine schedule.
Which GitLab versions does the project currently maintain?
At the time of the research, GitLab maintains versions 19.5, 19.4 and 19.3. Those are the lines that receive fixes, so an instance on an older line falls outside the support window and should be planned for upgrade. Check the maintenance policy page for the current list before you commit to a version, because the list moves forward with each monthly release. Confirm which version your team runs today and whether it appears in that list.
Does GitLab backport bug fixes and security fixes to older versions?
Bug fixes are backported only to the current stable release. Security fixes go further, because they are also backported to the previous two monthly releases. In practice, a team that falls one or two monthly releases behind can still receive security fixes, but not ordinary bug fixes, and it should not count on that protection for long. Staying on the current stable line gives the widest coverage. Ask your GitLab contact or review the maintenance policy to confirm how the backport window applies to the version you plan to run.
What are GitLab required upgrade stops and why do they matter?
Since GitLab 17.5, upgrades must pass through required upgrade stops at versions x.2, x.5, x.8 and x.11. Examples from the upgrade paths documentation include 18.2, 18.5, 18.8, 18.11 and 19.2, 19.5, 19.8 and 19.11. An instance that skips a stop may need extra steps, or may not be able to upgrade directly at all. Build the upgrade plan around these stops so that a team several releases behind does not discover a long chain of intermediate upgrades on the day it must patch. Read the upgrade paths page before any version jump.
How much staff time does keeping GitLab current take?
The effort depends on how many instances you run, how often you update, and whether backups and tests are automated. Recurring work includes reviewing each monthly release, applying patches, checking the upgrade path, taking a backup before each change and testing runners and pipelines afterward. The cadence described above is fixed by GitLab, so the variable is your process and your staffing. Ask any implementation partner for a written calendar that lists which releases they will test, who approves changes and how rollback is handled. Your internal estimate should come from that calendar, not from a general figure.
Can a team build a patch calendar for GitLab itself?
Yes, a team can build its own calendar from the published schedule: the third Thursday for minor releases, the twice-monthly patch cycle, the maintained version list and the upgrade stops. The calendar should name an owner for each step, a test instance that mirrors production, a backup before every change and a rollback plan. Teams with several GitLab instances or strict change control often pair the calendar with an outside partner for testing and documentation. DeployOpen plans, implements, upgrades and documents self-hosted platforms in your own environment under a written scope, and ongoing upgrades can be covered by a retainer. Confirm the exact responsibilities in writing before work starts.
How a move from Bitbucket Pipelines to GitLab CI/CD works
The sequence moves repositories, pipeline definitions, build history and deployment settings from Bitbucket into a self-managed GitLab instance, with both systems running side by side until builds and deployments are verified on GitLab.
Inventory pipelines, variables and deployment targets
Your engineering lead and the owners of each repository list every bitbucket-pipelines.yml file, the pipes and custom images each build uses, the deployment environments, and the secured variables each project depends on. Confirm with each team which repositories and pipelines it owns, because ownership decides who signs off on each cut-over. The step is done when you have a written list per repository with its owner, its deployment targets and the secrets it needs.
Export build history and artifacts inside the window
Platform engineering downloads the build logs, test reports and artifacts that your audit or release process needs to keep. Bitbucket Pipelines keeps artifacts for at most 14 days, so this export has to start early and cannot wait for the cut-over. Store the exports in your own archive with the build number and commit hash attached. The step is done when each retained build has its logs and artifacts saved outside Bitbucket and someone has checked a sample file can be opened.
Plan the replacement of secured variables
Security engineering and the deployment owners write down every secured variable and decide where each value will live on GitLab, such as project or group CI/CD variables, protected and masked settings, or an external secrets manager. Bitbucket secured variables can only be replaced or deleted, so the values must come from the people or systems that hold the originals, such as cloud accounts, registries and signing keys. Rotate credentials where the team cannot prove who holds a value. The step is done when each variable has a named source, a target location and an owner who will re-enter it.
Import repositories into GitLab
Platform engineering uses GitLab's import and migration tools to bring repositories into the self-managed instance, with branches, tags and merge request history where the import method supports them. Confirm in your environment which metadata transfers and which does not, and record the gaps for pull requests, permissions and webhooks. The step is done when each repository's default branch and tags match the source commit for commit and the team lead has accepted the list of missing metadata.
Convert pipeline YAML and pipes
Pipeline engineers rewrite each bitbucket-pipelines.yml into a
.gitlab-ci.ymlfile, mapping steps to jobs, stages and needs, caches to GitLab cache keys, and each pipe to a container image, script or included template. Where a pipe has no direct equivalent, the team writes the script itself and tests it. The conversion is not automatic for every feature, so the step includes a line-by-line review. It is done when every converted pipeline runs on a test branch and its output matches the Bitbucket run for the same commit.Register GitLab Runners and re-enter secrets
Platform engineering installs GitLab Runner on machines or clusters you control, selects executors that match the build needs, and registers each runner with the right tags and protection settings. Then the deployment owners re-enter the secrets from the planning step through GitLab's variable settings, not by copying values from Bitbucket, which cannot export them. The step is done when test pipelines run on the runners, every secret is present in GitLab with the expected scope, and no runner has access to variables outside its project group.
Run both systems in parallel
Release engineering runs the converted GitLab pipelines alongside the existing Bitbucket Pipelines for an agreed period, comparing build results, test counts, artifacts and deployment outcomes for the same commits. Deployments stay on the Bitbucket path, or go to a non-production target, until the comparison matches. Agree the length of the parallel period and the pass criteria in writing with the service owners before you start. The step is done when every pipeline has a documented set of matching runs and the owners sign off.
Cut over and retire Bitbucket Pipelines
Once each owner has signed off, the team switches the repository's deployment triggers, branch protections and status checks to GitLab, disables the Bitbucket pipeline for that repository, and records the change in the runbook. Keep the Bitbucket repositories, logs and exports available for the retention period your policy sets, then remove the remaining secrets from Bitbucket. The step is done when no production deployment runs from Bitbucket, the cut-over record is complete and the owners confirm the cleanup.
Questions buyers ask before choosing GitLab over Bitbucket Pipelines
What does running a self-managed GitLab cost in staff effort?
The main cost is the people who run it, not the software licence, because GitLab Free carries no fee for self-managed installations. Effort comes from installing and sizing the instance, running backups and restores, applying monthly and patch releases, and planning required upgrade stops. The GitLab maintenance policy describes a monthly minor release, patch releases twice a month and a yearly major release, so someone must own that cadence. Size of the user base, whether you need high availability, and whether you run Runners on your own hardware all push the effort up. Ask any partner for a written estimate of platform administration hours per month, the upgrade plan and who covers on-call duty.
How long does a migration from Bitbucket Pipelines to GitLab take?
The timeline depends on how many repositories, pipelines and secured variables you move, how much build history you need to keep, and whether repositories move at the same time as CI. Bitbucket Pipelines keeps artifacts for at most 14 days, so build history has to be exported before cutover, and secured variables cannot be read back, so each one must be re-entered from its source. Teams with a few dozen simple pipelines face a very different job from teams with shared deployment templates and many environments. No duration is supplied for this work, so ask for a timeline in the written scope that lists the repository inventory, the pipeline translation approach and the cutover window.
Can our team run GitLab without outside help?
Yes, many teams run GitLab in-house, but the answer depends on existing Linux, PostgreSQL, Redis and backup skills. GitLab documents several installation methods, including the Linux package, which bundles PostgreSQL, Redis and Sidekiq and is described as the most mature, scalable method. Larger deployments follow reference architectures, and the documentation generally recommends a high availability strategy for 3,000 or more users. The GitLab reference architectures documentation says PostgreSQL and Redis inside Kubernetes are not supported, which shapes the platform you can choose. A useful test is whether two or three staff can perform a tested restore and an upgrade without a vendor on the call.
What skills and staff time does the work need from our team?
Expect a mix of platform engineering, identity integration and CI knowledge. The platform side covers the instance, storage, backups and upgrades. The identity side covers single sign-on and role mapping so that access follows your directory. The CI side covers rewriting bitbucket-pipelines.yml into GitLab CI/CD configuration, setting up GitLab Runner executors and moving deployment credentials into protected variables. Security owners should review runner isolation and hardening guidance before production use. Ask for a skills matrix in the scope that names which tasks your staff do and which tasks the partner performs.
Can GitLab run in an air-gapped network?
GitLab documents running self-managed instances in offline, air-gapped environments. It also publishes separate guidance for running GitLab security scanners and GitLab Duo Self-Hosted offline, so those features need their own check. Plan for an offline installation package, a local process for updates and a way to deliver container images or dependencies into the isolated network. Confirm which Ultimate or Premium features your scanners need offline before you commit. The GitLab offline environments documentation lists the steps to review with your security team.
Do our repositories have to move to GitLab when CI moves?
No. GitLab CI/CD can be the pipeline engine while source stays where it is, but this only works if the GitLab runners can reach the Bitbucket repositories. The more common path moves both repositories and CI, because it removes Bitbucket from the build chain. Woodpecker CI is an alternative if you want to keep Bitbucket as the forge, and the separate Woodpecker sibling comparison covers that choice. Decide the repository location first, because it determines webhooks, access control and how build status returns to pull requests.
How should we compare quotes for a GitLab migration?
Compare quotes on the same written scope, not on headline day rates. Ask each provider to list the number of repositories and pipelines in scope, the environments and secrets to be handled, the platform components they will install and support, the backup and restore test, the upgrade plan and the handover documents. Separate one-time work such as installation, migration and hardening from recurring work such as upgrades, monitoring and support. Ask what happens if the repository inventory grows during the project. GitLab's own tier prices are a separate line: the pricing page lists Premium at 29 US dollars per user per month billed annually, and Ultimate is custom priced. DeployOpen does not publish a price list, and a quote follows from the written scope.
How DeployOpen works on this
DeployOpen plans, implements and hands over self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Bitbucket Pipelines vs GitLab CI/CD, we start with a written scope that tests the GitLab fit against your pipelines, runners and compliance needs before any build work begins.
How we scope
- Inventory bitbucket-pipelines.yml files, deployment environments and secured variables that need mapping to GitLab CI/CD
- Decide between GitLab Free, Premium and Ultimate tiers against the features your pipelines and compliance controls require
- Agree in writing the GitLab installation method, runner executors, and whether the instance runs in offline environments
How we build
- Install and configure a self-managed GitLab instance and GitLab Runner fleet inside your infrastructure
- Translate pipeline steps, caches, artifacts and deployment jobs into
.gitlab-ci.ymland test them against sample branches - Harden the instance, configure backup and restore, and plan high availability sized to your user count
How we hand over
- Deliver runbooks for runner operations, upgrade paths and the GitLab maintenance cadence your team must follow
- Document how secrets were recreated in GitLab, since Bitbucket secured variables cannot be read back for export
- Train your platform and engineering staff to operate, troubleshoot and extend the pipelines after handover
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope engagement ends
- Plan each GitLab upgrade around required upgrade stops and security backport windows in your change calendar
- Confirm with you and your vendors any licensing, tier or feature details that change before work starts
