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 bitbucket.org 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 ‘bitbucket.org’ differs from the key for the IP address ‘104.192.143.1’

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 support@bitbucket.org if you have any questions.

53 Comments

  • Amos S
    Posted December 9, 2015 at 5:00 pm | Permalink

    To remove the old entries from `~/.ssh/known_hosts`, you can also use `ssh-keygen -R bitbucket.org` (perhaps multiple times if you have mutliple entries).

    • Posted December 11, 2015 at 2:47 pm | Permalink

      That’s generally a good way to handle changes to known_hosts, but in this case that will remove the existing bitbucket.org entry (which is not changing) rather than the one for the IP in question (which is). You should instead use `ssh-keygen -R 104.192.143.1` if you get a conflict for that specific IP.

    • mufasa_hsu
      Posted December 14, 2015 at 7:09 pm | Permalink

      this is constructive.

  • Hohaha
    Posted December 9, 2015 at 5:04 pm | Permalink

    Do you niggas have ipv6 ones?

    • Posted December 10, 2015 at 11:45 am | Permalink

      Yes, but for now we’re focusing on the IPv4 addresses. Stay tuned for AAAA records.

      • issafram
        Posted December 10, 2015 at 8:58 pm | Permalink

        I love that you replied to that!

      • Daniel Jimenez
        Posted December 11, 2015 at 6:17 am | Permalink

        Respect. ?

  • Valter Silva
    Posted December 10, 2015 at 12:15 am | Permalink

    Great! Hope this solves the problem with the availability of the service also. We suffer with some downtime quite often, from Germany.

    • Posted December 10, 2015 at 11:42 am | Permalink

      It should help, yes. I tried to keep the focus here on the changes users should make to their firewall configs, but we expect this work to provide substantial improvements to all aspects of our upstream network (including reliability).

  • Posted December 10, 2015 at 2:19 am | Permalink

    Guys you are the best!

    • Ben Visser
      Posted December 10, 2015 at 6:53 am | Permalink

      no, they’re literally the worst.

      • Dardan Shaqiri
        Posted December 10, 2015 at 7:01 am | Permalink

        Why ?

      • Smile Detox
        Posted December 10, 2015 at 2:01 pm | Permalink

        In your opinion they’re worst but could you do better than bitbucket?

      • Posted December 10, 2015 at 3:03 pm | Permalink

        So, unlimited free private repos are not good enough for you?

        • Ben Visser
          Posted December 10, 2015 at 3:58 pm | Permalink

          It’s use case I suppose. Github rules the space for community and service integrations (CI services). Bitbucket has an affordable pricing model for private repositories, but their uptime could improve.

          • Amos S
            Posted December 11, 2015 at 4:14 pm | Permalink

            I don’t have issues with their uptime, but perhaps this move will address whatever you are talking about?

          • Posted December 13, 2015 at 10:59 pm | Permalink

            I didn’t know they had noticeable downtime.

          • Jacob Mellin
            Posted December 14, 2015 at 5:20 am | Permalink

            I think there was a DDoS attack a while back, where I couldn’t access all of my repos for half a day. But I guess you can’t really see that coming, and I’m sure they have improved their countermeasures for such cases.

          • James Gray
            Posted December 14, 2015 at 7:10 am | Permalink

            You’re absolutely right – GitHub never goes down! Pfft.

        • Igor Baidiuk
          Posted December 24, 2015 at 4:07 am | Permalink

          Absolute deafness to user requests. Tons of user requests, highly upvoted, are being ignored completely. Instead, Bitbucket team implements some strange stuff known and valuable to them only. The latest story is with their stupid ‘push message’, with no way to disable it. Issue sits there for half a year already, with no reaction from staff.

      • bsodmike
        Posted December 11, 2015 at 11:04 am | Permalink

        Actually, things got even worse that that for me. Been _forced_ onto a project using JIRA. The UX is absolutely abysmal. So much happer with Github’s PR flow (and our team loves it too). Would be interesting if Github consider to tackle kanban/pivots as well – if they do, I’m sure they’d do a fabulous job.

        That said, I’m thankful to Bitbucket for the free repos. But sadly, no match vs. Github.

        • Björn Lundén
          Posted December 12, 2015 at 5:55 am | Permalink

          You can use a similar PR flow on Bitbucket too if you didn’t know, you don’t have to use JIRA.

      • Copolii
        Posted December 11, 2015 at 3:11 pm | Permalink

        Classy. Constructive feedback is as common as common sense, I guess.

  • Chris
    Posted December 10, 2015 at 2:35 am | Permalink

    Does this affect the webhooks? The IP ranges listed there are 131.103.20.160/27, 165.254.145.0/26 and 104.192.143.0/24.

    • Posted December 10, 2015 at 11:18 am | Permalink

      Once everything is migrated, we’ll deprecate the 131.103.20.160/27 and 165.254.145.0/26 blocks. We’ll also update the webhook docs to list the same /28 subnets as I mentioned above.

      • Chris
        Posted December 11, 2015 at 5:52 am | Permalink

        Thanks. Will you post another one of those update notices when they’re officially deprecated? I have a plugin that whitelists your webhook IPs and will need to update it when they change.

        • Posted December 11, 2015 at 10:37 am | Permalink

          We’ll post here and update the knowledge base when the time comes.

          • Srinivas
            Posted December 13, 2015 at 11:32 pm | Permalink

            Bitbucket is quite good. Never had any trouble with it, except for the one search feature it lacks. Am surprised that when someone like Gitlab can have it, why not Bitbucket. Nowadays, we do take these free services for granted, but being a techie, I do understand the millions of dollars you have to spend to keep this up and running. Thanks guys once again. Really appreciate your work.

  • Richard
    Posted December 10, 2015 at 3:54 am | Permalink

    Will you be sending triggers to Bamboo using all the IP addresses in the blocks you defined? If so, do you have a solution for entering these 32 addresses on several projects in a reasonable way, seeing as Bamboo doesn’t seem to accept a range of addresses?

    • Posted December 10, 2015 at 12:09 pm | Permalink

      For now, at least, the first /28 subnet (104.192.143.192/28) will be the primary egress subnet for webhooks. I’ll check with the Bamboo team about range-based whitelisting, though.

  • Wow!
    Posted December 10, 2015 at 10:29 pm | Permalink

    Bitbucket via git push send message. It is creative!

    • Posted December 10, 2015 at 10:57 pm | Permalink

      Thanks! We wanted to be sure to badger as many users as possible about this, so that the transition is as seamless as possible.

      • Posted December 12, 2015 at 9:47 am | Permalink

        I saw that on Ubuntu’s git-cola window and I thought to my self “Oh I should probably check this out” !!
        God work !

  • kmansoft
    Posted December 12, 2015 at 2:06 pm | Permalink

    Will you be upgrading the ssh server on the new servers too? I’d love to be able to use ed25519 keys.

  • alexisribault
    Posted December 14, 2015 at 4:27 am | Permalink

    Thank you, hope it will work afterwards!

  • Mark O
    Posted December 15, 2015 at 1:13 am | Permalink

    Hi, I’m doing git operations through SSH. My operations route to altssh.bitbucket.org which is 104.192.143.16 (NOT in the list). Is it OK to include this in my firewall config as well?

    • Gav
      Posted December 15, 2015 at 2:56 pm | Permalink

      Hi, I’m also connecting through SSH on the same URL. We can’t connect using this any more and our build processes have stopped working. Is it just a case of adding this IP too?

      • Mark O
        Posted December 16, 2015 at 1:29 am | Permalink

        I had a query to support@bitbucket.org and the response was to add that IP and port to the configurations as well.

  • dharmabruce
    Posted December 15, 2015 at 10:01 am | Permalink

    So, like, you know, the ip addresses haven’t changed, man. What’s the deal?

    dig bitbucket.org -t NS +short | for NS in `xargs`; do echo $NS; dig bitbucket.org @${NS} +short; done
    ns-445.awsdns-55.com.
    131.103.20.167
    131.103.20.168
    ns-1305.awsdns-35.org.
    131.103.20.168
    131.103.20.167
    ns-1746.awsdns-26.co.uk.
    131.103.20.168
    131.103.20.167
    ns-584.awsdns-09.net.
    131.103.20.167
    131.103.20.168

    (From the article:
    “Please whitelist these new IPs now; you should be able to remove the old IPs after the migration is complete.”

    Analysis seems to indicate that’s not the case.)

  • Richard
    Posted December 16, 2015 at 8:17 am | Permalink

    Did you guys not make the switch? Today I’m still getting this:

    2015-12-16 17:07:27,765 INFO [http-bio-8085-exec-5] [TriggerRemoteBuild] Build request for plan “Plan” originated from 131.103.20.165 which is not an allowed address (one of […])

    The address listed there is one of the old ones which I obviously didn’t include in my list of allowed addresses.

    • Posted December 16, 2015 at 4:10 pm | Permalink

      I’ve posted an update above.

      • Richard
        Posted December 16, 2015 at 10:52 pm | Permalink

        Got it! I’ve re-added the old ones for now then.

  • Igor Baidiuk
    Posted December 24, 2015 at 4:04 am | Permalink

    It’s funny how Atlassian doesn’t even have way to login here with their own Atlassian account.

    Anyway.

    I clearly understand my question to be offtop here. But.

    You’re migrating to new IPs and doing some other stuff shiny to you. When will you pay attention to your own issue tracker, guys?

    https://bitbucket.org/site/master/issues

    Or at least close it so your users would clearly know you’re deaf to their requests.

  • Posted December 30, 2015 at 11:22 am | Permalink

    Suddenly I can’t do git push and pull in remote server at Siteground. After checking the known_hosts file, I see this.

    bitbucket.org,131.103.20.167 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOv$

    So should I just change the IP to 104.192.143.1? I haven’t tried it yet. 😀

    • Posted December 30, 2015 at 11:25 am | Permalink

      Oh wait, it now works all of a sudden. Haha! 😀 Thanks for this post.

  • s3m3n
    Posted February 1, 2016 at 6:46 am | Permalink

    We receive POST hooks from 104.192.143.193 which is not listed in this blog post, neither in your documentation:

    https://confluence.atlassian.com/bitbucket/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall-343343385.html

    I think it is your responsibility to deliver some simple csv file with all valid IP addresses so our firewalls can parse this file daily or something.

    • Posted February 1, 2016 at 10:53 am | Permalink

      104.192.143.193 is a part of the 104.192.143.192/28 subnet, which is listed both here and in the documentation.

      • s3m3n
        Posted February 2, 2016 at 4:53 am | Permalink

        You are right, thanks. I was too fast and didn’t notice you meant here “whole mask”. So there are 16 IPs under this mask.