Software teams ship more often with JIRA Software and Bitbucket

By on April 5, 2016

Every software team aspires to be faster. Agility and dev speed lead to happier customers, partners, and employees. We at Atlassian are committed to helping teams deliver software at speed, and we’ve made significant investments integrating our products so that it all flows smoothly from concept to launch.

JIRA Software and Bitbucket are two of the most popular developer tools among software teams and many of our customers choose to integrate them. While they swear by the integration, we were curious as to whether there was a measurable improvement to their processes and if so, how. So we asked one of our product analysts to pull the data for us (anonymized and sanitized for your protection, of course).

JIRA Software and Bitbucket teams release 14% more often

We compared the number of released versions completed during the second half of 2015 by JIRA Software teams with the Bitbucket integration vs. teams without it. There was definitely a correlation. We found that software teams released 14% more often on average when JIRA Software is integrated with Bitbucket. The contrast was especially significant for smaller teams (10 users customer tier) who released 25% more often on average vs. larger teams (2000 users customer tier) who released 5% more often.

All their information is in one place…

Why do software teams with JIRA Software and Bitbucket integrated release more often? For starters, they’re using agile and Git in their development process – plus the integrations themselves, which do a lot to enhance that.

JIRA Software and Bitbucket allow you to have all important information in one place so you can stay in the tool of your choice. You can track the health and status of your next release using the release hub. It shows a summary and a breakdown of the issues in the version, grouped by status.

Another important feature, the development panel, gives you visibility into development status within the context of an issue. Lastly, when you’re ready to start work, you can create a feature branch directly from the issue in JIRA Software. JIRA Software will automatically suggest a name for your new branch in Bitbucket based off the issue key so you never get lost in your branches.

…which helps them close 23% more issues

We also compared the number of issues created in the second half of 2015 that were transitioned to a “complete” state during the same time period. We found that on average, JIRA Software customers with the Bitbucket integration closed 23% more issues vs. JIRA Software customers without the Bitbucket integration. Again, the contrast was especially significant for small teams who closed 49% more issues on average with the integration.

Integrate to accelerate

Teams that use JIRA Software and Bitbucket accelerate development by taking advantage of features like workflow triggers to automatically transition issues from one status to another based on actions taken in Bitbucket (creating a branch, merging a pull request, etc.)

Likewise, smart commits in Bitbucket let you update your JIRA issues (add a comment, log time, or transition the issue) by adding special commands to your commit messages. Features like these let you avoid repetitive tasks and focus on coding, thus helping you ship more often.

“JIRA Software and Bitbucket allow us to more easily and reliably create better software for our customers, faster”, said Itay Neeman, Director of Engineering, Splunk.

Get started today

If you still aren’t convinced, why not try it yourself? It will take you less than 30 seconds to connect JIRA Software with Bitbucket. Whether you have both tools, just one, or neither, visit our integration page to get started.

Learn more about JIRA Software and Bitbucket


Did you find this post helpful? Share it on your social network of choice so your fellow software makers can learn from it, too!

Automating quality checks and Docker containers in a Git workflow

By on March 28, 2016

As a marketer for our family of developer tools, I get the chance to talk with developers doing really cool things with code they host on Bitbucket. Recently I had the chance to meet the team over at CloudCannon and discuss how they develop their application.

Similar to other small teams, they’ve faced challenges with setting up a solid continuous delivery model and ensuring the code released is of the highest quality possible. But thanks to the bitHound Bitbucket add-on and their own custom Bitbucket extension, they were able to create a workflow that’s a perfect fit. Here’s how it works – hopefully this will inspire a few ideas for your team’s process.

CloudCannon’s need for speed

CloudCannon makes it possible for non-tech savvy users to update their own websites. Developers build a static or Jekyll site with full control over design, libraries, and frameworks used. Then non-developers log in and update the content inline, with no prior knowledge of development needed.


Like all SaaS companies, they live and die based on their ability to release fixes and features to their customers as frequently as possible. Git’s support for branch-and-merge workflows, plus Bitbucket’s extensibility, plus Docker’s flexibility is their recipe for dev speed (with a dash of automation thrown in).

Node.js, microservices, and bitHound (oh my!)

Their infrastructure, written in Node.js, is entirely composed of microservices. Each repository contains a stable master (trunk) branch, a production branch, and feature branches as needed.

For each new feature, they create feature branches within every microservice repository it touches. To keep track of changes on their feature branches, they implemented a strict commit message convention. Each commit has to indicate the type of change made with “fix, feature, or chore”. For example:

fix(broken sharing ui)
feature(added ssl interface)
chore(fixed mixed whitespace)

These conventions come in handy when it comes time to tell customers about each release. They group commits together based on keyword to create detailed release notes they can publish in their documentation.


Once feature development is complete, they merge those changes back into the stable master branch. At this point in their workflow, CloudCannon needed a way to enforce additional quality checks. After meeting the bitHound team at Atlassian’s very own AtlasCamp event last year, they discovered that bitHound could do just that.

If you’re unfamiliar with bitHound, it’s a continuous code analysis tool for JavaScript that identifies risks and priorities inside the project’s code and dependencies. Using bitHound’s add-on for Bitbucket, CloudCannon could flag and update any packages or JS warnings before they made it into a release. bitHound statistics display right inside the Bitbucket UI on every repository CloudCannon creates.


Using Docker containers for deployments

Once features have passed the package quality check, changes are deployed to their staging environment. How does this happen? I’m glad you asked – this is where things get really interesting.

When CloudCannon set out to build their continuous integration and delivery pipeline, they found it difficult to find a solution that fit their exact requirements. What do you do when you’re an engineer and in need of a tool? You build your own! So CloudCannon did just that, creating their very own continuous integration and delivery tool called Weldr.


Named for its ability to ‘weld’ together Docker containers, Weldr is a node.js application that uses Express.js to create web services for the team to interact with. CloudCannon automatically kicks off builds using Bitbucket’s webhooks with each push to their master branch.

Tying together several bash scripts, Weldr then pulls the latest repository change from Bitbucket, spins up a new Docker image, starts up all necessary services, and finally publishes a log file of how the build went. If all is well in the log file, the developer then runs through a series of scripted manual tests to ensure everything is working as expected.

Currently the team needs to open Weldr to view the results, but they plan to enhance the process by sending build status updates to Bitbucket’s Build Status API. This will show them the status of builds without having to leave the Bitbucket repository.


When a batch of new features and fixes are ready for release, they repeat the process to deploy to production (which happens 2-3 times a week), with one minor change. Instead of automatically triggering production deployments, they decided to make it push-button to avoid any accidental mistakes.

…and so can you

Using Bitbucket’s extensibility, bitHound’s quality control, and their own custom continuous integration CloudCannon is able to deploy to their end-users with zero downtime – a feat they’re rather proud of.

If you’d like to implement pieces of CloudCannon’s process, you can find the bitHound add-on for Bitbucket here. And although Weldr is unique to CloudCannon, you can use just about any continuous integration tool to mimic their process. Many of which, like Bamboo, Wercker, and AWS CodeDeploy, integrate directly with Bitbucket for automatic deployments and build status.


Automation is just the beginning. For more on Git workflows and using Bitbucket for continuous delivery, head over to The Pipeline our continuous delivery hub.



Introducing code search for Bitbucket Server

By on March 24, 2016

How often has this happened to you: you see an error message and you’re not sure which part of the code it came from, or you know the function name but you don’t know what repo contains the code for it. “Ghaah!” Many of you’ve been asking for a way to search through your code in Bitbucket Server, and I’m pleased to tell you that the wait is over.

Today, we’re inviting our customers to take a first look at code search in Bitbucket Server via our early access program (EAP). Now you can search through your code to find exactly what you’re looking for right from the search bar:


How does it work?

We understand that many of your teams have a lot of code. So we’ve made it easy for you to restrict your search results to a specific project or repository using search filters. You can also search for code in a particular language (e.g., lang:java) or with a particular file extension (e.g., ext:css).


Search operators like AND, OR, and NOT can be added to searches to help narrow down or broaden the results. This is useful for further filtering results when you get too many.


How do I get started?
Glad you asked! You can download the Bitbucket Server EAP build with code search here and we’ve created this step by step guide to get you started. If you do try it out, let us know how it goes – your feedback is extremely valuable to us. Filling out this short and simple survey will help us make code search installation better for you and your fellow Bitbucketeers when it is officially released.

We look forward to bringing you more soon. Happy searching!

Download code search EAP now

New improvements for Bitbucket Cloud Projects

By on February 24, 2016

A few weeks ago, we introduced the concept of projects in Bitbucket Cloud based on requests from many of you. This is a unique feature of Bitbucket and has already proven helpful for teams who need a way to organize their repositories – especially teams in larger organizations managing hundreds (or thousands) of repositories. We’re constantly striving to innovate and add valuable features to Bitbucket Cloud, and we wanted to let you know about several improvements to Bitbucket projects already in the works:

Why should you use Projects?
As organizations grow, team sizes get bigger, and more and more repositories get added. It gets progressively harder to find the repository you’re looking for. Projects make it easier for your team to organize repositories and be more productive with Bitbucket Cloud. Some of the main use cases we’ve seen so far include:

Dashboard sorting preview
We’ll be continuously iterating on projects in Bitbucket Cloud, and we’re shipping some changes to our dashboard today. We’re introducing the last updated column as requested by many customers over the last month which, in combination with our updated filter bar, will make it easier than ever to stay on top of your team’s work and find the repositories that you’re most interested in. To accommodate these changes, we’ve removed the “Recently viewed” table, however those repositories are still only a click away in the repositories menu.

Here’s a preview of the new dashboard:


What’s next?
We’re committed to helping your teams deliver software at speed, so please keep the feedback coming! Projects are already making a big impact on the way teams organize and manage their repositories with Bitbucket and we’re looking forward to continuing to iterate on the experience based on everything we’ve heard so far. For further discussion, we will be available on this Reddit thread to answer any more questions you might have around Bitbucket projects.

Happy coding!

What designers, game developers and architects need to know about Git LFS

By on February 19, 2016

<This is a cross-post from Atlassian Blogs>

Atlassian is dedicated to unleashing the potential in software teams. We want to help you work smarter and faster. This is the reason we keep adding new features to Bitbucket  – branch permissions, merge checks, smart commits, smart mirroring and many more.

Last year, we were working on solving another big problem for our users: tracking large files in a Git repository. Git large file support (LFS) provides the ability to store really big files where they’re needed, not just where they fit. We want to make Git right for everyone and that’s why we decided to collaborate with GitHub on building a standard for large file support.

Why Git LFS?
It’s a known issue that Git doesn’t play nicely with large files, and it’s not just developers who struggle with large files and version control. Native Git’s limitations make it challenging for team members like designers, tech writes, sys admins, and build engineers to work closely with developers.

They often need to store their assets in stand-alone systems or cloud storage providers because of Git’s historic inability to track version history for large assets (schematics, graphics, or other media files). Co-locating non-code assets with the code itself means the large assets can be updated quickly, easily versioned, and become a natural part of the deployment pipeline. As a design team incorporates feedback on their interface assets, iconography, and images, they can deploy those changes in a fully-built version of the product and see the results.

Git LFS also allows people like designers to version the assets they share with their team, just like all the other assets in a repository. This means developers can find the latest revision of an asset they need to use without needing to track down the right version of a file or interpreting what “menubar_v2_final_v3_final_final.psd” means. (Sounds almost too good to be true, doesn’t it?)


For mobile software teams and game development teams, Git LFS relieves the pain of working with the ever-larger image, texture, and video assets that cater to the ever-improving resolution on mobile devices. It also means tests and builds don’t need to rely on an external step to succeed. And if you’re building a video- or audio-intensive app, you can keep those stored in Git LFS too.

Git LFS in Bitbucket
Naturally, we want to do everything we can to make Git more accessible to all team members. And that’s reflected in the changes we’re making to Bitbucket, our Git repository manager, available as a cloud service or on-premises server. Any software team using Git LFS can now view every version of project assets through the Bitbucket interface and in select media types we’re now making it easy to compare the latest version updated with our visual diff tools.


Bitbucket Server implemented Git LFS in v4.3, and we’ll be releasing support for LFS in SourceTree (our desktop client for working with Git) soon. We’ve also made it really easy to use LFS in Bitbucket Server so you can get started quickly. But Atlassian’s LFS journey is far from complete. We’re bringing LFS to Bitbucket Cloud soon.

Git for everyone!
We’ll continue collaborating with GitHub on the LFS protocol to extend the capabilities of Git for all software teams using features like file locking to prevent change conflicts, better handling of vector and layered files, and more. In Bitbucket, we’re making it easier to work with media files and our design teams are helping us bring a great UI experience to every member of your software team like designers, tech writers, marketing, etc. – even if they don’t write code.

If you haven’t used Git yet, check out our collection of Git tutorials and articles. Or if you’re ready to get started, signup for a Bitbucket Server account. If you’re already using Bitbucket Server,enable Git LFS for your team and let us know what we can do better.

Smart mirroring: the cure for poor Git performance

By on February 9, 2016


<This is a cross-post from Atlassian Blogs>

Are you on one of those teams that finds all kinds of ways to stretch the limits of its development tools? If you’re at a big company, working on big projects stored in big repositories – possibly repos that are shared with teammates across multiple continents – the answer is probably “yes”.

Using Git at massive scale can be so inefficient that it poisons your team’s productivity. So I want to bring you up to speed on the antidote we’ve developed. It’s called smart mirroring, and it’s now available in Bitbucket Data Center.

Does your team need smart mirroring?

Some teams do, some don’t. But the teams who do need it have a few things in common.

For starters, we’re talking about teams with hundreds, if not thousands, of developers. A few thousand coders will tax any repository server, even if that server is sitting just a few feet away from you. And as important as the performance of Bitbucket itself is, there are other factors in play.

We’ve noticed that an increasing number of large development teams using Git are geographically distributed, with little or no control over the network performance between themselves and their Bitbucket instance. These teams suffer from high latency and every operation they perform competes for limited bandwidth. In addition, these same teams often need to work with large repositories for a variety of reasons (sometimes even good reasons!).

All these factors conspire to rob developers of valuable time, making them wait long periods – often hours – to clone a large repository from across the globe. It can get so bad that people have resorted to sending portable drives around the world via mail. That kinda sucks.

If this sounds like you, smart mirroring will help.

How smart mirroring improves Git performance

Bitbucket Data Center has always been able to run multiple application nodes in a local cluster to help serve all those users and build bots that demand performance and availability. Smart mirroring takes the performance improvements a step further for Git read operations in a way that’s tailored for distributed teams working with large repositories.

image2016-2-2 12-55-43
It works by setting up one or more active mirror servers to operate with read-only copies of repositories in remote locations, automatically kept up-to-date from the primary Bitbucket instance. A mirror can host all of your primary instance’s repositories, or just a subset. Mirror servers delegate user authorization and authentication to the primary server, so no additional user management is required. And you can connect as many mirrors to your Bitbucket Data Center instance as you need at no additional cost.

Aside from dramatically improved Git performance, developers are automatically presented with alternate clone locations in the Bitbucket interface, so administrators don’t have to provide extra training. Once set up, the mirrors are fully self-serve.

Predicting performance improvements


The performance gains you can expect vary as a factor of network bandwidth and repository size. What it basically comes down to is how slow remote cloning is for you today. In a simple test, we saw that a 5GB repository took over an hour to clone between San Francisco and Sydney. But with smart mirroring, that time was reduced by 25x to just a few minutes.

We heard from one customer where a remote user had a clone that took 9 hours. (9 f’ing hours!) They could expect a more substantial performance increase – basically, a whole working day given back to each developer who clones a large repo.

Imagine: the mobile team in Bangalore, that web team in London, the secret project team working from a lab in Thailand… all able to reap the benefits of Git, without suffering from the tyranny of distance.

Whether you’re just adopting Git or already a guru, your distributed teams should be able to make cool stuff without unnecessary delays. If you’re ready to talk to a real live human about smart mirroring and how it can help your team, get in touch with one of our customer advocates using our handy contact form. If you’ve temporarily lost your ability to speak due to banging your head against your desk while wondering if that 8GB clone is ever going to complete (or you’re busy hand-delivering a hard copy of it to your teammate in Poland), you can get more information about our Data Center offerings online.

Interested in learning more? Join Roger Barnes, Senior Bitbucket Product Manager, on March 3rd at 11:00am PST, CET, and AEST to learn:

Register for Webinar

Did you find this post helpful? Please share it on your social network of choice and help your fellow Git users end their performance woes!

Pull request guidelines for Bitbucket Cloud

By on January 26, 2016

Sometimes, developers mess up. We don’t mean to do it, but sometimes, our code is exposed to situations we didn’t anticipate. The best we can do when that happens is to fix our mistakes and learn from it. Some of us even try to find ways to make sure this doesn’t happen again. How? Document our mistakes and make sure developers can discover them in the future.

Over time, these learnings grow into an unmanageable collection of documents. The effectiveness of these documents decreases because no developer writes code with multiple pages full of caveats open in a separate window. We’ve heard from our customers that it would be great if there was an easy way to scan and access a checklist that is available during development and pull request reviews.

Many projects have solved this problem by having a file in their repository, which not only mentions how to contribute to that repository but also lists the things to look out for. A good file serves as a helpful checklist during development. It would be even better if we could somehow enforce that during the review process.

So, during an internal hackathon, I built an add-on that attempts to do exactly that. The “pull request guidelines” add-on parses the file in your repository and summarizes it in the form of an easy-to-scan checklist. It then makes the checklist accessible in the pull request itself, so both the author and the reviewer can easily go over the list of guidelines. The “pull request guidelines” add-on also makes it super easy to turn these guidelines into actionable tasks.


The add-on was built using Bitbucket Connect. If you like what you see and have a cool idea, you can make something like this too. Go check out this tutorial and let loose your imagination.

This add-on was a result of a couple of weeks of work, so it’s not quite done yet. But that shouldn’t stop you from trying it out. Check out the add-on page to learn more, and if you just want to install the add-on, click the button below:

Install pull request guidelines

Distributed teams can now build faster with Bitbucket

By on January 21, 2016

Strong innovators have always aspired to be faster. Fast development cycles lead to more innovation and lower costs according to a recent survey on innovation by Boston Consulting Group. We at Atlassian are committed to helping teams deliver software at speed. Last September, we announced critical new capabilities to enable teams to do just that: build faster with Bitbucket. We’re excited to announce that these features are now available:

Smart Mirroring

Git Smart Mirroring

Many software teams using Git can build up large repositories over time due to a large amount of historical information, use of monolithic repositories, storage of large files, or a combination of the three. Developers working from remote locations need to wait hours when cloning, which is a big drain on productivity. Smart Mirroring can drastically improve read (clone, fetch, pull) performance for distributed teams working with large repositories by making them available from a nearby server. As an example, in one of our own internal tests, we have seen clone times get 25X faster for 5GB repositories between San Francisco and Sydney.

A mirror server is simple to configure, easy to maintain, and automatically uses existing authentication mechanisms. Unlike some other solutions available in the market, you don’t need to install or configure a whole new instance in order to create a mirror server, or mirror the repositories one at a time. Administrators will love how simple it is to host a mirror server, and developers will appreciate how the vastly improved clone and fetch times speed up their workflow.

Interested in learning more about Smart Mirroring? Register for the webinar, “Speed up distributed development with Smart Mirroring for Bitbucket Data Center” happening on March 3rd.

Git Large File Storage (LFS)

Git Large File Support | Git LFS

Modern software teams at their core consist of not just developers but designers, QA engineers, writers, and more. These teams track assets such as graphics, videos, and other binary files that are inherently large. Git’s original performance goals for distributed version control weren’t optimized for tracking large binary files, making it unsuitable for storing large assets. With the addition of Git LFS support, software teams can track all the assets they produce together in one single place and be productive at the same time. Large files are kept in parallel storage, and lightweight references are stored in your Git repository making your repositories smaller and faster.


Bitbucket Projects

As organizations grow, team sizes get bigger, and more and more repositories get added. It gets progressively harder to find the repository you’re looking for. Projects make it easier for teams to organize their repositories and become more productive with Bitbucket Cloud. This feature is already available in Bitbucket Server and Data Center. We also took this opportunity to refresh our UI in Bitbucket Cloud and make it easier for you to find what you’re looking for.

Get started with Bitbucket

With the addition of Smart Mirroring, Git LFS, and Projects – Bitbucket is now more suited than ever for professional teams. Organizations of all sizes – from large enterprises such as Verizon and Nordstrom to small startups like Pinger and Kaazing – are using Bitbucket today, and we’ve heard from many that they’ll be using these new features in the coming weeks.

“Many of our customers have distributed teams that have experienced pain around storing large binary files and cloning performance. Smart Mirroring and Git LFS are two huge game changers that will boost productivity for our clients using Bitbucket around the globe. We are excited to roll it out to all our customers.” – Zubin Irani, Chief Executive Officer, cPrime

“Our developers are spread all over the world, and Bitbucket helps them remain aligned as they build powerful solutions for our customers. We are very excited about Smart Mirroring in Bitbucket which will not only improve multi-site clone performance but will also increase developer productivity of distributed teams.” – Kurt Chase, Director of Release Engineering, Splunk

Our JIRA Cloud customers picked Bitbucket as their #1 Git solution. More than 1 in 3 Fortune 500 companies trust Bitbucket and are using it every day to innovate faster. If you’re new to Git, head over to “Getting Git Right.”

Or, if you’ve already made a decision to switch to Git, click the link below!

Try Bitbucket Free

File Viewer for Bitbucket: view files of different formats in Bitbucket

By on December 29, 2015

File Viewer for Bitbucket Cloud is the winner of the Codegeist 2015 Atlassian hackathon, in the category Best Bitbucket add-on.

This guest post is written by Alexander Kuznetsov, one of the developers of File Viewer for Bitbucket Cloud and co-founder of StiltSoft, an Atlassian Verified vendor and Atlassian Expert. Alexander has seven years’ experience as a software developer, five of which have been developing add-ons for Atlassian platforms. He was also the runner-up of Codegeist 2012 for the Awesome Graphs for Bitbucket Server (Stash) add-on.  

With millions of developers on Bitbucket Cloud there is a huge demand for add-ons providing additional functionality. Earlier this year our team introduced Awesome Graphs for Bitbucket Cloud. Then later in October, we decided to participate in Atlassian Codegeist 2015 with the idea that Bitbucket Cloud users would appreciate the capability to view files of various formats directly on Bitbucket pages. That’s how we built File Viewer for Bitbucket Cloud.

File Viewer for Bitbucket Cloud

This add-on allows you to view 3D and 2D models, maps, tables, and PDF files that are a part of your repositories right in Bitbucket without downloading them.

It’s a pack of viewers that includes:

File Viewer adds a new button on the panel of the core Bitbucket viewer, the one you see when you click a file in the Source tab. That button is used to switch from the default view to seeing a file in the add-on viewer.


View PDF documents

While viewing files with the *.pdf extension, you can see how many pages there are in a PDF document. Pages are displayed one at a time and you can navigate between them.


View 3D and 2D models in STL and Autodesk Viewers

There are two viewers for 3D models – STL Viewer and Autodesk Viewer. The latter can be used to view 2D models as well. STL Viewer works with *.stl extension files and renders them as 3D models that you can spin and zoom. This viewer is opened when you select the ‘View as 3D model’ option.


Autodesk Viewer supports over 30 file formats. Using this viewer you can visualize and interact with 2D and 3D design data. To open it, select the ‘View in Autodesk Viewer’ option.


View CSV and TSV documents

Table Viewer presents CSV and TSV files as tables with header and sorting capability.


View Maps

Map Viewer displays files with the *.geojson extension as maps that you can zoom and interact with (i.e. click it).


Try it

You can try File Viewer for Bitbucket Cloud by installing the add-on from the Find new add-ons section in your Bitbucket Cloud personal account settings. File Viewer doesn’t require any configuration. Once installed, you can start using it right away. Navigate to the Source section on the left-hand sidebar in your repository, locate a file you would like to view and select the viewer option in the ‘Default File Viewer’ menu.

We’d love to hear from you. If you have feature requests or feedback you would like to share, please contact us or post your ideas at the File Viewer forum.

Making Bitbucket’s network better, faster, and ready to grow

By on December 3, 2015

UPDATE 2016-01-26:

All IPs have been moved, and the old IPs are no longer handling traffic.

Thanks to you, Bitbucket is outgrowing its old network infrastructure. We’re going to make some upgrades that should make Bitbucket faster, more reliable, and ready for further growth.

What are we doing?

We’re changing our A records in DNS starting at 00:00 UTC on Tuesday, December 15, 2015. There will not be any downtime for this migration, and most people will not have to do anything differently because of this migration.

Why are we doing this?

Our new IP address space, along with some underlying network improvements, should make response times noticeably faster for about a third of our users. Just as important, these changes make it easier for us to improve upstream network connectivity and load balancing, and to perform other infrastructure projects in the near future.

How will this affect you?

Most users will not have to do anything special for this migration. Your DNS servers should pick up the new IPs within a few minutes of the migration, and your systems should start using the new IPs right away. We’ll keep the old IPs running for a few weeks afterwards just in case, though.

Firewall considerations

If you control inbound or outbound access with a firewall, though, then you may need to update your configuration. Please whitelist these new IPs now; you should be able to remove the old IPs after the migration is complete.

New destination IP addresses for will be:

New source IP addresses for hooks will be:

SSH considerations

Our server’s SSH key is not changing, so most SSH clients will continue to work without interruption. However, a small number of users may see a warning similar to this when they push or pull over SSH:

Warning: the RSA host key for ‘’ differs from the key for the IP address ‘’

The warning message will also tell you which lines in your ~/.ssh/known_hosts need to change. Open that file in your favorite editor, remove or comment out those lines, then retry your push or pull.

Stay updated

As we update records, we’ll post updates on our @BitbucketStatus Twitter account and our status site so you can follow along. We’ll also keep our knowledge base up-to-date with any future changes to the lists of IPs.

Thanks for your patience as we work to increase Bitbucket’s speed and reliability. Please contact us at if you have any questions.