Limiting repo access by IP address (BB-3715)

Issue #3717 resolved
created an issue

Hi There

Could bitbucket allow block repo access by IP Address? For example, one of our repo should only be accessible from our office IP.

Competitor products (e.g. beanstalk) have this feature so hoping bitbucket supports it too.

Cheers Ashik

Official response

Comments (149)

  1. Deputy reporter
    • changed status to open

    Hi Dylan

    Thanks for taking the time to reply.

    I am a bitbucket evangelist and I can tell you whilst I talk to other people about your product, sensitivity and security of the source code people take VERY VERY seriously.

    The fact that people can log in from home to work -> itself is a great benefit in today's world. However, some of us are quite conscious of IP theft, code sensitivity etc for which we believe doing this slight extension to the security model is only beneficiary to the business customers of bitbucket.

    More so, your competitor beanstalk does provide this feature:

    I will really appreciate you guys having a second thought into this. It's not only about current permission being enough for majority of your existing users. It's also all the customers you will have with added features and benefit.

    Many thanks in advance, Ashik

  2. Marcus Bertrand staff

    We do not monitor or count +1s on issues. Please use the vote using the link near the top of this issue. This will help us decide if this will be done in the future. At the moment, it isn't on the roadmap. If you need detailed control and auditing in your organization, try Stash, our behind the firewall version of Bitbucket which you can control 100%.

  3. joecity


    Security of the source code is top priority for a lot of companies. In fact my company will probably stop using bit bucket due to the lack of an IP restriction feature.

  4. andrey


    We would also upgrade from free to paid if this feature is implemented. Our still company is still very small, however we hired a couple of new programmers and its very important for us the code is not stolen. Ideally, if it would be possible to use different IP-based security settings for different team members e.g. we can allow our old staff to work from home, but not for the new ones.

    Please escalate this feature request at the higher level and we hope you'll implement it shortly. Otherwise, we'll have to search for another solution.

  5. rosh

    Yes, its a very good feature.

    Could you please illuminate us with your reasons for not including this in your roadmap? Your colleague Charles McLaughlin commented earlier on this thread that its a good idea. Aren't good ideas supposed to be rolled out?

  6. Swapnil Kadam

    +1 for this feature, But make something Mutual SSL kind of feature as well, Because if a company is working on cloud IPs, The IPs are shared among multiple companies.

  7. Andre Guergolet

    +1 for this feature, for my personal projects I still using Jira, but for our office projects I will need this feature. Our security policy disallow home-office for our developers.

  8. andrey

    Bitbucket team, are you there? It's been awhile since you replied back to this issue. There're lots of +1 here and I believe there're lots of customers who want this functionality but don't post tickets. Please escalate this issue at a higher level since it's really important for teams, especially for distributed ones. Thanks in advance.

  9. Swapnil Kadam


    I like BitBucket but because of our business needs and security we moved to Beanstalk already.

    This is the essential requirement for companies using bitbucket for their products and service codebase version control.

  10. Chintan Jadwani

    Thanks for the reply. My decision to use bitbucket because it is atlassian product and it is integrated with JIRA very easily. The issue tickets are raised on JIRA so we are using the link from Eclipse IDE > GIT and BitBucket > JIRA (where developer's commits are shown) So, can you help me to understand if beanstalk is also easy as bitbucket is? Thanks

  11. Matt Grofsky

    We use beanstalk with JIRA as well and Eclipse.

    Basically you can

    Post commit information Link to associated ticket Change ticket state Reassign a ticket Add labels to a ticket

    They offer a free account so can try it and see if its a viable alternative for you... It worked for us.

  12. Team Ceesark

    Today we have started using bitbucket for a small team in our org. By seeing non-existense of IP based restriction, bit nervous to provide the access to team member. Our expectation is to protect our product code in the safe manner. Make this option as soon as possible.

  13. Abhijit Deshpande

    Just started to evaluate and absence of this feature is a show stopper. Surprising that bitbucket team was prompt in saying wont fix as "most" users dont need it and when "most" users start asking for it they wont even bother to comment. Ofcourse this is a needed feature how do you expect companies to protect their IP without this. Expecially for startups and teams where thhere re lots of new guys/interns this is a must

  14. Abhay Deshpande

    I guess this has something to do with their product positioning. We still use paid BitBucket for our other projects but for projects where this feature is a must, we have moved to other vendor.

  15. manny veloso

    What's to prevent someone from pwning creds and sucking down source? Answer: nothing.

    +1 for this feature. In fact, we can't use bitbucket for our next project without this feature, and it's likely that our current projects will be moved off of bitbucket because this is currently impossible.

  16. Inder Sidhu


    BitBuket team, are you planning on adding the IP restriction feature in near future?

    If not, whats the other way for ensuring code security?

    Thanks, Inder

  17. Abhay Deshpande

    @Carlos Torres - or have a look at We are using them since last 1 year or so, it has no frills, is cheap yet reliable. It also has Amazon S3 integration if you need double protection. We still hold BitBucket account but use xp-dev account for data-sensitive projects. Cheers, Abhay

  18. Robert Noack

    Plus infinity votes for this.... did a google search knowing i would find how to do it, and once again discovered a basic basic feature missing from bitbucket. I don't understand the product management at Atlassian. Lots of big shots there who don't seem to understand the basic necessities of real world software development. Actually, it's quite depressing. I hope that one day Atlassian will wake up. It's just a matter of time because some of your customer's repos are hacked due to something like this. Is that what it will take to get Atlassian to give a damn about security? Who has to get fired for this to be fixed?

  19. Gaber Terseglav

    I think it is a shame that bitbucket team is giving security lowest (or no) priority. I really can not understand this decision and when I read comments from year 2012 (!) for this issue I understood it even less. Because of this limitation we are using bitbucket only for non strategic projects. Future usage of bitbucket cloud solution depends on this issue for our company.

  20. Alastair Wilkes staff

    Thanks for this thoughtful feedback, all. We remain incredibly committed to customer data security, as indicated by our security statement. We’ll take this feedback into consideration as we prioritize related changes, but right now these improvements aren't slated for release.

  21. Vicky Chandnani

    This feature can encourage me to move some of my repository (which are currently on internal network) to BitBucket. Actually I spent quite a bit of time finding such setting in BitBucket Admin panel (coz I was so sure that it should be there...) but then I had to Google search for the same and eventually I landed here..

    Eagerly waiting for this

  22. Dipesh Patel

    I do agree, this is must feature for enterprise, as ISO 27001 requires data security and if you cannot control the restriction by IP, this will violate ISO 27001

  23. Chris Feldhacker

    Source code is intended to be downloaded to the user's device and worked on. Before allowing local storage of potentially sensitive IP data, it is necessary to ensure the device has appropriate security controls in place. Things like full device encryption, up-to-date AV, firewall, removable media disabled, procedures in place to sanitize the device upon decommissioning, etc. In addition, for users in certain countries with lax IP laws, it is only risk appropriate if those users can access certain systems when they are located "in the office" and not from home. These are normal and common security controls -- NIST, PCI, ISO, take your pick.

    Bitbucket is not able to enforce these controls or perform these checks, nor do I expect it to. However, in lieu of providing these controls, offering the ability to restrict access by IP address is a great alternative. By restricting access by IP, now Bitbucket no longer needs to be responsible for ensuring the desired device/user security controls are in place, rather the responsibility can be pushed "up stream". Now it becomes my responsibility to somehow make sure the desired security controls are in place before the user can even get network access to generate traffic that would originate from the specific IP address(es) that I configure. I could whitelist my corporate and branch offices, public IPs of my AWS account, and the IPs of other SaaS solutions (code review services, CI solutions, etc.).

    I would love to move away from managing and maintaining on-premise solutions and toward SaaS solutions like Bitbucket Cloud, but when SaaS vendors seem to be oblivious to common security standards and controls and fail to recognize the tremendous value something as simple as "restricting access by IP address" would provide, it should be obvious why enterprise adoption of SaaS solutions is slow. It doesn't matter if you're a big or small vendor, the first SaaS vendors that recognize and understand the security needs of enterprises have the best shot at winning. This issue has been open since 2012 -- that's 4 years now you could have been drawing in enterprise users...

    In the mean time, I'm just waiting to see which vendor will implement this feature first -- Bitbucket or Github? (Given the amount of time it took to offer 2FA, I think the smart money is on Github...)

  24. Nilay Khandhar


    This is really nice feature you should have. I already vote for this issue. I came on this page after searching on google for the same solution. Till i reach to this page, lot of other options i see as Ad(s) so this is loosing factor for bitbucket.

    This is my Love to the Atlasian products that i still want this feature despite of other options, so i can use this in my organization as cloud deployment git freely.

    Please add this.


  25. Ewart MacLucas

    We have a paid bitbucket account but as we grow and utilise short term temporary development help, I am more concerned about developers having access to our code outside the office, as well as someone outside of the office getting hold of the developers credentials. Microsoft Azure handles this very well with it's database IP firewall. It's been 3 years, any updates on this essential security requirement?

  26. Arian

    We also need this feature and will move to self-hosting if its not coming soon. Is it that hard to implement a IP Restriction filter or just 'we have other priorities on roadmap'?

  27. Arian

    P.S. if its that big of an issue, move the git server in-house with another Atlassian solution Stash (aka now 'Bitbucket Server'). Thats what we decided to satisfy our security needs.

  28. Norbert Kiesel

    I do not believe that BitBucket is even looking at solving this: more than 4 years ago they marked this a "wont fix", and they never looked back. Like many others, I moved on to greener fields (in-house GitLab in our case, but that's of course not the only alternative). I will stop following this thread...

  29. Grigoris Minogiannis

    This is not a "nice to have" feature; this is a "must have" one that boosts security since a private repository is accessed over the internet. Note that similar products offer the same feature as well.

  30. Robert Noack

    Yeah, this is sad. It's pretty clear that atlassian is just focused on providing 'growth' features and products, since they are a publicly traded stock now, it won't be worth it for them to implement this feature until a high-profile customer gets hacked and their source code and private information stolen. Big business these days is to put security dead last, which ultimately guarantees that Atlassian will fail as a company. I'm getting out while I can. Also going to unsubscribe from this thread now.

  31. John Simpson

    One other request, now that it looks like somebody's actually going to do this ... for managed accounts, there should be a per-account IP list, along with a way to override the list on a per-repo basis, with a per-account setting to enable or disable the ability for non-admin users to tinker with the per-repo overrides.

    Our account has about 360 repos. I need a global IP list, with a different list for three or four specific repos, and while I don't mind my users seeing the IP lists, I don't want non-admin users to be able to change any of the lists, either per-account or per-repo.

  32. Daniel Tao staff

    @John Simpson You'll be pleased to know we've been having internal discussions along similar lines, but probably slightly less pleased to know that at least our initial implementation will not be as granular as you're proposing. The first iteration of this feature that we release will in all likelihood be a per-account setting, which will allow you to specify a list of IP addresses that apply to all repos owned by the account (no per-repo overrides). This isn't because we don't think per-repo overrides is a good idea; it's just an MVP thing where we want to ship something useful as early as possible and then build upon that.

    That said I totally get what you're saying, and the scenario you described (same IP list for most repos, with just a few having slightly different lists) is one we'll definitely keep in mind.

  33. Samir Al-Amar

    @Daniel Tao - Please can you give us some kind of timescale on when it will be released please.

    Our IP Protection is currently done as follows: We have a global password for login to Bitbucket and the IT Support guy changes each individual user password for the dev team one-by-one at COB (by logging into each account manually and changing the password). This is then displayed to them the following morning in order for them to successfully log in to Bitbucket. Repeat every day...

  34. John Simpson

    @Daniel Tao My real concern is that I don't want to have to go through and set IP lists for 350+ repos... being able to set it once for the entire account is good enough for now. I don't have a specific need for per-repo overrides, but I can see where others might.

  35. Dheeraj Reddy

    @Nathaniel van Diepen - Seriously, you're wasting time posting this! I'm just trying to reiterate on the timeline. This issue has been there since ages but Atlassian never took this up until these many users reiterated the need. I have had that experience with Atlassian before, so you want something, you keep reiterating it. And also I am making my point there that MVP is important and features can be added later!

  36. Nathaniel van Diepen

    @Dheeraj Reddy @Samir Al-Amar

    @Nathaniel van Diepen - Seriously, you're wasting time posting this

    There you go again!

    In all seriousness, of course I read your comments. In both of your comments the request for a timeline was quite separate from the main content and not really necessary. If I was the developer working on this, all repeat requests for a timeline would do is make me not want to provide it. If you were patient and waited until he has an actual timeline to post instead of asking for it again since he hasn't replied and it's only been a day I'm sure he'll feel much better about it.

  37. Daniel Tao staff

    Now now, everybody, let's all be nice to each other :)

    Concrete timelines are difficult to provide. As I'm sure you can all appreciate, keeping a service with millions of users running takes a lot of time and attention; things come up all the time; and adding new features requires a great deal of planning and caution. That said, we are starting work on this project now and we don't anticipate that it will require a massive amount of engineering effort. (Famous last words...)

    For now I would say to expect this feature in early 2017. Hopefully between now and then I will be back with a more informative update for everyone.

  38. Daniel Tao staff

    Hey folks, apologies if you just got a notification. I responded to the wrong feature request 🐑

    Rest assured my previous comment still stands: we have indeed started work on this feature (IP whitelisting), and I will provide more info as we get closer to a v1 release.

  39. Daniel Tao staff

    I will provide more info as we get closer to a v1 release.

    OK, so I overshot and we are now past the v1 release. Anyway, the good news: yes, IP whitelisting is indeed here. This is the second of our new Access Controls, which provide team admins with the ability to restrict their private content (repos, issues, wikis, and snippets) to only users who meet certain requirements, namely having two-step verification, and now accessing Bitbucket from whitelisted IP addresses.

    I should note for those interested in this feature that there are some limitations at present:

    • IP whitelisting is currently not supported for SSH access. Teams with IP whitelisting enabled must access their repositories over HTTPS.
    • In contrast, requiring two-step verification prevents team members from accessing private content using basic authentication. This means that if you enable both access controls, members of your team will need to use app passwords to access your repositories via the CLI.

    Additionally, if you enable access controls you should bear in mind that they apply to all access; so you will need to take care to ensure that any integrations you have configured (build systems, automated scripts, Connect addons, etc.) will pass your requirements.

    Lastly I just want to emphasize this is an initial release. We have some additional functionality that we plan on adding over the coming weeks, so stay tuned for that.

  40. Fred Chen

    @Daniel Tao

    "IP whitelisting is currently not supported for SSH access. Teams with IP whitelisting enabled must access their repositories over HTTPS." Can you share more info regarding "not supported for SSH access"?, it is not clear if SSH access will be totally blocked when an ip-whitelist is configued, or SSH access works as if it doesn't recognize the ip-whitelist.

  41. Sebastian Glomb

    What about services like dyndns? It appears bitbucket doesn't recognize a dyndns ip as a valid ip. I need to manually add IPs to the list every day currently. Being able to also use a dyndns IP would make this feature way more convenient.

  42. Rustam Aliyev

    Currently, SSH access is totally blocked for repos whose owners have enabled IP whitelisting.

    Are there plans to enable SSH access? If so, what's the ticket number to watch?

  43. Daniel Tao staff

    @Sebastian Glomb I'm not sure I understand what you're asking for. Are you referring to Dynamic DNS? This service allows you to make resources on your computer available on a publicly accessible domain which dynamically updates to resolve to your non-static IP address. That does not change the IP address that you make requests from. When your computer makes a request to Bitbucket, it does not include your Dynamic DNS domain.

  44. Sebastian Glomb

    I want to whitelist the IP behind said dynamic DNS domain. Right now I have to manually whitelist the IP every time it changes (twice a day). If I could add the DNS domain und Bitbucket simply pings the domain and whitelists whatever IP is behind it I wouldn't have to manually add it twice a day every day.

  45. Mike Neilly

    It would be useful to be able to restrict access for particular SSH keys by IP address. Is this something you would consider adding? So, for example, if a key that is part of a docker image in the cloud is compromised it cannot be used from another IP address before being removed from service.

  46. Alastair Wilkes staff

    Hi @Mike Neilly,

    Thanks for your question. The existing IP whitelist should cover that case already - i.e. if IP whitelisting is enabled, the hypothetical compromised SSH key already could not be used from non-whitelisted IPs. Are you suggesting that you want some keys to not be subject to the whitelist? Would that be for developer convenience, or...?


  47. Mike Neilly

    Hey Alastair, sorry for the jumbled thinking. I was running to a meeting and should have waited to think through and compose my message. Clearly, if the IP is whitelisted the key cannot be used from a non-whitelisted IP... a silly statement on my part. :)

    In general, I'm thinking of a scenario where there is a key in a cloud account used for automated processes that should only be used from that IP/network and other keys used by both travelling and stationary users. Somebody travelling should be able to use a key from an unknown IP while, for most users, keys can be restricted to a smaller set of IPs. Somebody should also not be able to use the cloud key from the whitelisted user addresses.

    If I understand the whitelist feature correctly, there is one set of whitelisted IPs that is applied without regard to keys. Is that correct?

    In the above scenario, either a whitelist is used and it restricts travelling user's access or a whitelist isn't used at all, right?

    In any case, it is a good new feature. Not trying to diminish it. Just thinking about how it applies to our setup.

  48. Alastair Wilkes staff

    Aha, no worries! I understand what you mean.

    If I understand the whitelist feature correctly, there is one set of whitelisted IPs that is applied without regard to keys. Is that correct?


    In the above scenario, either a whitelist is used and it restricts travelling user's access or a whitelist isn't used at all, right?

    Yes. Unless the traveling user uses a VPN or some other means to get behind the corporate IP, which we found fairly common in our research of customers who were interested in this kind of access control.


  49. Frederic Decoster

    We would like give only certain IP addresses access to certain repositories, other repositories need to be accessible by the whole team. So we can't use the IP whitelist feature in the account because this would affect all the repositories.

    Is it possible to whitelist IP's per repository? Or is this something you can add or thinking to add?


  50. Log in to comment