Create your FREE Codefresh account and start making pipelines fast. Create Account

Codefresh versus Bitbucket pipelines

10 min read

Bitbucket pipelines are the native Continuous Integration (CI) part of the Bitbucket GIT repository service. If you are already using Bitbucket for your source control needs, you might think that adopting Bitbucket pipelines is also natural as they are tightly integrated.

Choosing Bitbucket pipelines just because they are already part of the bitbucket service might seem a good idea at first glance, but in reality, it forces you to use what is readily available instead of what is truly appropriate to your needs.

Bitbucket is one of the supported providers in Codefresh (like GitHub and GitLab) so it is perfectly possible to still use Bitbucket as a source code repository and delegate all pipelines to Codefresh.

In this post, we will see a comparison between Bitbucket pipelines and Codefresh. The reality is that like all other traditional solutions, Bitbucket was originally a pure CI solution which was later retrofitted with deployment capabilities. Codefresh, on the other hand, was designed from scratch with the full CI/CD lifecycle in mind.

Table of contents:

  1. Bitbucket pipelines only work with Bitbucket, Codefresh works with Bitbucket, GitHub, and GitLab
  2. Bitbucket pipelines are limited to 10 steps
  3. Bitbucket pipelines are not designed for microservices
  4. Bitbucket pipelines git triggers are very limited compared to Codefresh
  5. Build caching must be manually configured in Bitbucket pipelines
  6. Docker support is not first class in Bitbucket pipelines
  7. There is no Docker cache in Bitbucket pipelines
  8. Codefresh has explicit support for Kubernetes deployments
  9. Codefresh has explicit support for Helm deployments
  10. Bitbucket pipelines are SAAS only

Let’s see all these points in order…

Bitbucket pipelines only work with Bitbucket, Codefresh works with Bitbucket, GitHub, and GitLab

This is probably the first important point regarding this comparison: Bitbucket pipelines only work with Bitbucket repositories. If your organization works purely with Bitbucket this might not be a problem. But in more realistic situations (with big companies) it is very common to work with multiple source code providers.

Bitbucket pipelines only work with the integrated Bitbucket repositories and the only way to work with another repository is by importing it first as a native source code repository (essentially creating a second copy of it). This means that if you want to collaborate with people that have repositories in GitLab, GitHub or any other external source, you will be forced to maintain a completely separate repository just for taking advantage of Bitbucket pipelines (a very impractical solution).

Codefresh is agnostic as far as the source code is concerned. You can connect any type of git repository from GitHub, GitLab or Bitbucket (or even your on-premise git platform) and use all of them in the same manner. You can even mix source code from different git providers in the same Codefresh pipeline.

In summary, if you have code repositories outside Bitbucket or want to collaborate with people that are not using Bitbucket, Codefresh is only viable CI/CD platform.

Bitbucket pipelines are limited to 10 steps

This is a second Bitbucket limitation that may prove a deal-breaker for big organizations. Bitbucket pipelines can only have a maximum number of 10 steps and even if you use parallel steps this number is still a limit on the total number of steps used.

You may never hit the limit if you work on small pipelines. Any large organization, however, will most likely need pipelines with more steps, especially when it comes to building microservices that consist of multiple applications.

Codefresh has no limit on the pipeline steps (as long as runtime resources are available) so you are free to create and design any pipeline structure you want.

A common Codefresh pipeline
A common Codefresh pipeline

In Bitbucket the pipeline shown above would not be possible as it contains 15 steps.

Bitbucket pipelines are not designed for microservices

Bitbucket pipelines are mainly a CI platform that existed long before containers and microservices gained popularity. As such, it was retrofitted with container support, while still keeping the legacy design that was present before.

This is more evident in how thing are organized in Bitbucket pipelines. Everything is attached to a single project. This made sense in the era of monolithic applications but is totally inflexible for microservices.

As a quick example, the build view in Bitbucket pipelines always shows the builds for a single project:

Bitbucket build view
Bitbucket build view

If you have multiple projects that form an application, it is impossible to see all of them together in Bitbucket pipelines.

Codefresh on the other hand is designed with micro-services in mind and integrations and view are at the account level instead of the project level. In the same example, Codefresh allows you to view builds from multiple projects at the same time.

Codefresh build view
Codefresh build view

The same mentality of a single monolithic application is evident in all other aspects of Bitbucket pipelines. Even pipelines themselves are attached to a single project. Codefresh is a much more flexible solution that allows you to create pipelines attached to multiple git repositories (or even none).

Codefresh pipeline view
Codefresh pipeline view

Bitbucket pipelines git triggers are very limited compared to Codefresh

Building a basic pipeline that only checks out the code at each commit is very easy to do in Bitbucket. Unfortunately, this is the only way git triggers can be used. The only choice you have is whether you will build a commit, a tag or branch.

Codefresh has a much more advanced triggering system that can be used with multiple conditions:

Codefresh triggers
Codefresh triggers

For example, you can define a trigger only when a Pull request is created against a specific branch. With Codefresh you also have full monorepo support where a trigger will only happen if specific files within the repository change. Bitbucket pipeline have no such support out of the box.

Build caching must be manually configured in Bitbucket pipelines

In Bibucket pipelines (like GitLabCI) you have to setup manually caching for your pipelines. Bitbucket will not cache anything out of the box and it is your responsibility to define which directories will be cached.

To enable cache, you need a special directive in your Bitbucket pipeline definition to select which programming language you want to use. Here is an example for Node:

    - step:
         - node
         - npm install
         - npm test

The same is also true for build artifacts. There is a separate syntax in Bitbucket pipelines where you define you artifacts.

Codefresh has instead fully automatic caching. If you want to move a folder from one step of the pipeline to the next (that either contains dependencies or artifact) you need to do exactly… nothing!

Codefresh accomplishes this by automatically mounting a shared volume between all the pipeline steps. The project folder itself is checked out on this volume.

Codefresh automatic caching
Codefresh automatic caching

In the example above the node_modules folder is automatically shared with all the steps in the pipeline. You don’t need to define it as a special cache folder.

Notice that this shared volume is also cached by Codefresh between subsequent builds of the same pipeline. This makes Codefresh builds very fast without any extra configuration.

Docker support is not first class in Bitbucket pipelines

Like several other legacy CI solutions, Bitbucket pipelines was originally a VM based platform. When Docker appeared into the scene, Bitbucket pipelines added support of running Docker commands manually. Here is an example Bitbucket pipeline:

    - step:
         - docker
         # build the Docker image (this will use the Dockerfile in the root of the repo)
         - docker build -t $IMAGE_NAME .
         # authenticate with the Docker Hub registry
         - docker login --username $DOCKER_HUB_USERNAME --password $DOCKER_HUB_PASSWORD
         # push the new Docker image to the Docker registry
         - docker push $IMAGE_NAME

The commands just represent what you would run locally in your workstation. You also need to litter your pipeline with Docker credentials. In summary, with Bitbucket pipelines “Docker support” just means the ability to run Docker commands.

Codefresh was designed with containers in mind and it has proper Docker support by including the following:

  1. A free private Docker registry built into the platform
  2. Special Docker pipeline steps for creating and pushing images
  3. Automatic pushing to the internal Docker registry
  4. Account-level external Docker registry integration.

Codefresh has a built-in registry (comes for free with all accounts) as well as handy UI dashboard that allows you to inspect your Docker images.

Built-in Codefresh registry
Built-in Codefresh registry

Apart from the internal Docker registry, you can also link any external Docker registry (and promote images between registries). The Docker credentials are defined once in the account level and all your pipelines are just using the integration.

Adding an external docker registry
Adding an external docker registry

All Codefresh pipelines automatically push their artifacts to the internal Docker registry. If you want to push to external registries as well you can easily use the dedicated push step.

Here is a Codefresh pipeline:

  title: Building DockerImage
  type: build
  image_name: my-app:master
  type: push
  title: Pushing to ECR
  candidate: ${{build_image}}
  tag: latest
  image_name: codefresh/my-app  
  registry: my-ecr-registry

Notice the lack of Docker login instructions or credentials.

In summary, Codefresh offers everything you need to work with Docker images (including a private Docker registry), while with Bitbucket pipelines you need to setup everything by yourself with custom scripts.

There is no Docker cache in Bitbucket pipelines

We have already seen the fact that Codefresh also includes a private Docker registry (and associated dashboard). Codefresh takes Docker support one step further by having full Docker cache for all build nodes resulting in very fast builds.

The Docker cache in Codefresh works exactly like the local Docker layer cache that you are familiar with and can help you achieve very fast builds as only the changed layers will be fetched for each build.

Docker caching in Codefresh
Docker caching in Codefresh

In the pipeline above, you can see that Codefresh automatically detects which layers have already been built.

Bitbucket pipelines on the other hand have zero support for Docker cache. Thus, everytime that you build a container you pay the full price for the build even if only some layers are actually changed.

Bitbicket pipelines with no Docker cache
Bitbicket pipelines with no Docker cache

Here I am running a Bitbucket pipeline a second time (without actually changing in my Dockerfile) and you can see that all Docker layers are downloaded again and again.

Depending on your Docker migration path, not having Docker cache in your pipelines might become a serious blocker in the way developers interact with the CI/CD platform.

Codefresh has explicit support for Kubernetes deployments

Codefresh is currently the only CI/CD solution that offers an integrated Kubernetes dashboard.

Codefresh Kubernetes dashboard
Codefresh Kubernetes dashboard

Once you connect your cluster you can see in real time all the services, pods, and deployments from your releases.

Bitbucket offers nothing for verifying deployments. Once a deployment is finished you need to use an external service to actually see it running.

Codefresh has explicit support for Helm deployments

Similar to Kubernetes, Codefresh comes also with full support for Helm. Out of the box, you get:

  • A private Helm repository for your releases
  • The ability to connect any external Helm repository
  • A Helm release dashboard
  • A Helm deployment dashboard
  • A Helm environment dashboard.

Here is the Helm dashboard:

Codefresh Helm dashboard
Codefresh Helm dashboard

Here is the list of all Helm releases (public and private repos are supported):

Helm app browser
Helm app browser

And here is the Helm environment board:

Helm environment board
Helm environment board

In summary, the Helm support in Codefresh is very comprehensive. There is zero support for Helm releases in Bitbucket pipelines.

Codefresh also offers on-premise and hybrid installation modes

Bitbucket Pipelines are only offered as a SAAS product. This is fine if your application and source code is already on the cloud. There are several companies however with strict security requirements for keeping source code on premise (e.g. financial or medical).

Codefresh also offers an on-premise installation mode for companies who wish to run the Codefresh platform on their own infrastructure. There is also a hybrid mode available so that the builders themselves are running in the customer infrastructure while the UI is still in the SAAS product.

In summary, Codefresh can cater to any type and size of company, while Bitbucket pipelines offer only a single usage mode (cloud version).


Bitbucket pipelines is a CI solution limited only to Bitbucket and small pipelines (10 steps maximum) which was later retrofitted for Docker support as a way to run Docker commands.

Codefresh is a full CI/CD solution with Docker caching, private Docker and Helm registry, Kubernetes and Helm release dashboards.

If you prefer a matrix-style comparison, read the table below:

Feature Bitbucket pipelines Codefresh
Git Repository dashboard No Yes
Git support Bitbucket GitHub, GitLab, Bitbucket
Quay/ACR/JFrog/Dockerhub triggers No Yes
GIT triggers Commits only Any git event
Native Monorepo support No Yes
Global pipeline view No Yes
Max pipeline steps 10 Limited to resources only
Built-in dynamic test environments No Yes
Local builds No Yes
First class docker support No Yes
Automatic build caching No Yes
Docker layer caching No Yes
Internal Docker registry No Yes
Docker Registry dashboard No Yes
Native Kubernetes deployment No Yes
Kubernetes Release Dashboard No Yes
Integrated Helm repository No Yes
Helm deployment dashboard No Yes
Helm release dashboard No Yes
Helm environment dashboard No Yes
Installation Cloud Cloud/On-prem/Hybrid

New to Codefresh? Create Your Free Account Today!

Kostis Kapelonis

Kostis is a software engineer/technical-writer dual class character. He lives and breathes automation, good testing practices and stress-free deployments with GitOps.

Leave a Reply

* All fields are required. Your email address will not be published.