Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Data Residency: General Discussion

RJ Gazarek Atlassian Team Nov 18, 2020

Use this thread to chat with RJ about anything related to your Data Residency need. 


JiraJared Community Leader Nov 20, 2020

Hey RJ,

Is there a date for when AU will be available for Enterprise Cloud?


RJ Gazarek Atlassian Team Nov 24, 2020

Hi Jared! Good to see you here :) Sorry for taking so long to respond. I forgot to turn notifications on for this new space, but I am good to go now, so ask away! 

We don’t have a locked in date for AU right now.  However we are looking at early FY22 (which starts July for us as a reminder) for Australia. We are evaluating where the biggest demands and needs for our customer currently are, and prioritizing that. I do know that Australia is high up on the list :)

As we continue work on prioritizing the second half of our year, and collecting more data, we will update our public roadmap with more locked in dates. 

Like Danielle Imbesi likes this


From the perspective of the Medical Device companies, it would be necessary to have this feature on the Premium version too. Many companies in this space are small-medium in size and cannot afford the Enterprise version.



RJ Gazarek Atlassian Team Nov 25, 2020

Thanks Matteo!  We are definitely exploring bringing this into the Premium edition. We want to do what makes the most sense for our customers, without adding additional complexities to our product capabilities.  We have a running discussion going on right now, and I would suspect sometime early in Q3 we'll have a decision and adjust our roadmap if the decision is to do so. 

Like Danielle Imbesi likes this

As requested above, please make data residency a feature that's available out of the box on premium.

The way it currently feels like is:

- there is a lot of nice fluffy marketing stuff around GDPR and SCCs on your web site but that does not change the fact is that by default the data is outside EU and the org cannot change this unless buying the mythical enterprise version.

- enterprise is way too expensive (just like DC edition is) and cannot be justified in SME orgs to CFOs

- you don't care about smaller customers at all, unless it's a mega account you are not interested

- the marginal cost of storing data within EU on AWS is roughly the same as it's to store in US on AWS

This is bad for those companies that really need (or must) to comply with GDPR and not just pretend they do.

Like # people like this
RJ Gazarek Atlassian Team Nov 28, 2020

Hi Kajtzu!

Thanks for the feedback.  I hear your frustration and I'm sorry it feels like we don't care about our smaller customers.  I promise, we definitely do!  And yes, like I mentioned above, we're looking at the possibility for companies interested in Premium to get access to Data Residency capabilities.  We also need to make sure that if we do, we have the infrastructure, the people, and the support system to handle the higher volume of customers.  So we are putting a lot of thought into this decision to make sure we do the right thing for our customers!  

Just please know, I hear you, and I feel good about the direction we're going in!

What I am not sure about: from what I have understood, data residency is where your/our data is stored permanently. But when an app/addon processes your data, data may be moved temporarily to the app provider, who may be located at a totally different region of the globe.

@RJ Gazarek: Please speak up if I got something wrong here.

@kajtzu:would that still be compatible with your data residency requirements (and not only pretend it would be)?

Like RJ Gazarek likes this

Think of it like this (examples follow):

- if customer data is stored in EU but viewed on a customer support representative’s screen in India, well, the data is then in India.

- if data is stored in EU, exported by automated systems to AWS us-west-1 and resent back to EU - data was outside EU

Obviously the data should be stored in EU, processed in EU (even if it is automated systems doing it), etc.

the only “easy” use case is when the user is outside of EU, by his own choice, and accesses the data willingly (and thus exports the data on his/her own).

The law is written slightly vaguely and there aren’t enough court cases, yet, to limit interpretations. It is what it is.

Like RJ Gazarek likes this
RJ Gazarek Atlassian Team Dec 04, 2020

Hi @Thomas Dörfler !  

So when we have talked to our customers around the globe.  We have to balance two things, the useability of our software and the needs of their business, with complying with local regulatory requirements.  In the case of Data Residency, we have reached a great middle-ground with our customers that we store your primary data within the region specified (EU in this example).  The problem with "keeping" data in the EU, is to the exact point both you and @kajtzu are discussing is if you have an employee travelling or any employees outside of the EU, if we only kept your data strictly within the country and never let it leave - employees in the EU would never be able to collaborate or work with employees outside of the EU, since those folks wouldn't be able to access your data.  So, we leave that up to you, which you can handle through IP restrictions if you only want people with EU IP Addresses to access your data.

Many companies that do have a global employee base, often use VPNs to tunnel their access to their company's data.  Which helps with the security of your data.  So you could restrict the IPs to your EU based offices, and then have anyone outside the EU, use VPN to establish their IP address as an EU one.  

Now with respect to your add-on data.  For our ecosystem app vendors, yes, they are the ones responsible for holding your data in the datacenters they have.  We rely on them, to meet your data residency needs, since they control the data.  We are currently working with our app vendors to help them meet the needs of our customers, and also working on ways to communicate what regions they support to our customers.  

Hi @RJ Gazarek ,

thank your for your fast response and your detailed answer.

Currently we run our Jira server locally (actual 20 meters away from my desk) with regular off-site backups. User's access is either through local company network or, as you mentioned, via VPN. We use a few addons, which, in turn, run locally on our server (at least that's what I have been told).

So currently our local mini server has a much easier privacy scheme than what the current cloud solution offers.Much easier actually means: we don't have to check each month whether the cloud delivered privacy level has changed. We just set it up, check for updates regularly and that's it (more or less).

I assume that moving to cloud may offer more functionality, but I am sure it needs much more care regarding changes, that affect data protection and privacy. For small companies, this means much more internal effort, much more additional cost.

Switching to cloud seems like an exciting adventure for me. In general, this would be ok, but not for a system that we use to store and organize our knowhow.

Like # people like this
RJ Gazarek Atlassian Team Dec 04, 2020

Hi @Thomas Dörfler that's what I'm here for :) 

You are correct, it's almost good to think of them as two different products.  And yes you have to evaluate the different tradeoffs.  On one hand you get a product with the latest features, don't have to worry about managing hardware, and all that jazz (you know, the regular cloud arguments).  But on the other end, you do have to put more trust in the company (in this case Atlassian).  

We do our best to make that consideration and transition as easy and as transparent as possible.

And this whole group is to help answer questions you may have that concern you about moving to our cloud.  I empathize with you, that change of any kinda can be difficult and/or scary.  I think you'll find that once you get over the initial hurdle and checking things a few times to make sure we are living up to our promise, that it becomes a lot easier to manage as you move forward. 

We're here to help and answer questions as best as we can, and I personally am grateful for you asking these questions and engaging with us on the product team here!

@RJ Gazarek


"You are correct, it's almost good to think of them as two different products. And yes you have to evaluate the different tradeoffs. "

That's my impression too. And, funnily, when I remember on of Atlassian's inverstor letter right, 85% of users start(?) in cloud. But 75% of customers operate (at least one?) private server. So It seems in the past, most customers so many benefits in private server (I am one of them).

And I would be happy to have a choice between these "different products" after 2024 too...

Like # people like this

@RJ Gazarekthere hasn't been much happening on these pages for the last two months, and given the severity of the impact that Atlassian's recent decisions have, and the heat of the ongoing de-platforming discussions on other media, I feel it would help all of us if instead of opening new discussion topics, the very visible concerns of people on this forum would be addressed soon.

I hear from other SMEs that they are not even engaging in the discussion because they have already given up on Atlassian, and their question is only how and when to migrate to another platform. Given the lack of helpful responses from Atlassian, I do by now wonder whether that may indeed be the correct question to ask. Right now, it still feels as if Atlassian is determined to carry on on the path of destruction regardless of what its SME customers say. Hence some robust responses from Atlassian that genuinely address the concerns voiced here would be much appreciated.

Like # people like this


yesterday I was thinking about giving almost the same response (although I didn't find these nice words ;-) ) In the end I decided it's not worth the time.

Obviously Atlassian doesn't care about the customer concerns.

Why should we participate in improving a product that is not made for us (and will never be)?

RJ Gazarek Atlassian Team Feb 03, 2021

Hi @office  thanks for joining us in this forum for an open discussion. This forum and thread are meant to have an open discussion about feedback and questions you have.  There hasn't been much response on our end, because we haven't had too much activity from our customers in this thread specifically, mostly due to the holiday and customers I'm sure getting back into the rush of a new quarter and a new year.  But we have a lot more people joining, and I"m hoping more questions will get asked, so I can help answer them!

I believe I've answered every question asked of me here, to the best of my ability, with respect to data residency.  If I've missed something or didn't' answer something fully, please let me know so I can answer what I've missed. 

Again, for this thread, I can only really speak to Data Residency questions, so let me know if I've missed something I can help answer, that's what I'm here for!

And @Thomas Dörfler good to see you again :) I want to say, I definitely hear the frustration from both of you.  I know change is difficult, I really don't enjoy it too much myself to be honest, especially when it's change that feels out of my control.  Your expression and response is always worth the time, so never hesitate to let me know how you're feeling and where I can help as much as I'm able to.  Unfortunately, the reality will be, we won't be able to solve 100% of the problems for 100% of the customers.  I know that specifically for Data Residency, we have customers asking us for things like Data Residency in Russia, which I know right now I can't solve for.  Maybe in the future, I'll be able to, but I have to prioritize which items affect the highest number of our customers with the time and resources we have available to do so.  I can 100% guarantee you that none of my personal roadmap decisions about Data Residency have anything to do with not caring about some of our customers.  

I didn't see any questions to respond to, so if you have anything related to Data Residency, or any other security/compliance concerns, please post them here or in the other threads - so we can help answer them.  That's why these forums exist, to provide direct contact with the product managers for these areas.  There are other closed forums too on things like change management, reliability & performance, and extensibility if you have questions around those topics.  

I may not have all the answers, but I'll do my best to let you know what I know, or help get an answer. And again, thank you for coming here to talk.

Hi @RJ Gazarek , thank you again for your fast response.

You are right I did not ask specific questions in this thread and I did not address our specific concerns regarding a move to the cloud. So let me try to phrase them.

Our current state is: we have Jira up and running on our tiny local server, 20 metres away from my office. We have 15 users. Quite simple. Two years ago we decided to do our complete project management using Jira. And we are developing customer specific embedded HW/SW solutions for various markets (consumer, automotive, industrial, aerospace, others).

Up to know we have under control:

- when our server operates

- how it is secured against external frouds

- how it is backed up

- who has access to the (sensitive) data

- when we will upgrade

BTW: No problem accessing our Jira instance from home office, using our VPN tunnels.

The server is up, running, needs regular maintenance, everything under control.

Moving to cloud would change things.

1.) Jurisdiction:

- Atlassian+Amazon can/will update their terms of use. And we have to check whether they still fit our need. And we have a 45 day period to either accept or reject. If we reject, we are out, we can't operate or access our cloud Jira server any more.

 @RJ Gazarek am I right here?

- data residency: if data is stored OR PROCESSED abroad, foreign state authorities may enforce access not only to our data, but also to data relevant for our customers. As far as I have seen this happened around 40 times in 2019.

 @RJ Gazarek am I right here?

2.) Data safety:

- Atlassian+Amazon will be responsible to backup the cloud instance. If data is lost, Atlassian will most likely NOT compensate us for all the financial loss.

 @RJ Gazarek am I right here?

On the other side, I don't see benefits using cloud for our company.

The big problem for me is to pass control to a company, that has created a great tool for us, but is changing the tool not according to our requirements.

Like Bernhard Breit likes this
RJ Gazarek Atlassian Team Feb 03, 2021

Hi @Thomas Dörfler 

Great questions!! I don't have all the answers off the top of my head, and since these are so important, i want to make sure I get the right information and give you the accurate response.  Give me a bit to gather the answers, and see what I can bring back for you.  Hang tight!

Thanks for the responsiveness. In the general discussion on regulations & compliance, I stated that one way to meet legal requirements related to protection of classified data would be to introduce a DC edition that is accessible also for SMEs. So let me phrase that as a question: Is Atlassian considering introducing a DC edition that is accessible/affordable also for SMEs (with around 50 users in this case)?

Like Marcel Ringler likes this

Hi @office - probably a better question for some of the server specific threads, as I'm mostly responsible for data management in the cloud. 

We really do believe that the cloud is a great option for most of our customers, especially at that size. So definitely check out our roadmap and continue to make sure that our cloud does meet your needs. And make sure to let us know if you don't see what you need to feel confident in moving to our cloud, either through forums like this, or on our contact form:

And as always, we will continue to evaluate our packaging to ensure that it meets the needs of our customers.  I know that doesn't give you a definitive yes or no, as that's not really my call to make.  But anything related to data management needs in our cloud, I'm here all day to try and help answer!

We also know that some customers will have requirements that we can't satisfy today, which isn't to say we don't want to, or can't because we don't care - I promise you, we really do.  Just like in Data Residency, I'm not going to be able to satisfy 100% of the customer needs, it's not a question of compassion as much as it's a question of time, resources, company strategy, and customer demand.   

I know you still have time to watch our roadmap for cloud, ask questions, and make sure that it will fit your needs.  Here's a quick excerpt about our support timeline for server as a reminder.

Between February 2, 2021 PT and February 2, 2022 PT, we will continue to provide support (i.e. database, browser, Java) and bug fixes on server products. After February 2, 2022 PT, we will only provide security bug-fixes for critical vulnerabilities until the end of support.

On February 2, 2024 PT, your products will reach end of support. After that date, we will not release any further product updates. Regular security updates help protect your business from threats and vulnerabilities, so we strongly recommend moving to cloud or upgrading to Data Center before the end of support date.

RJ Gazarek Atlassian Team Feb 03, 2021

@office one more quick follow up for you. what I would love to hear more about what are the concerns you have with moving to our cloud, because that will help ensure folks like me, are working to address those needs so you can move to our cloud.  If you're willing to jump on a call with me and 1 or 2 of my fellow PMs, would you be open to that? If so, email me at and we can setup some time. 

RJ Gazarek Atlassian Team Feb 03, 2021

Hi @Thomas Dörfler !

Okay so I talked with our legal and privacy team, because I wanted to make sure I was responding correctly.  Some of this is a bit outside of my scope of responsibility but still wanted to try and help where I could, if possible. 

On your question:

Atlassian+Amazon can/will update their terms of use. And we have to check whether they still fit our need. And we have a 45 day period to either accept or reject. If we reject, we are out, we can't operate or access our cloud Jira server anymore.

When talking to our team, they weren't quite sure where the 45-day number was from, but in general, the response from our team was this:

As set forth in Section 24.4 "Paid Subscriptions" of the Atlassian Cloud Terms of Service (provided that the customer has purchased a Cloud Product), modifications to the Terms will take effect at the start of the customer's next purchase or renewal. If the customer does not agree with Atlassian's modifications to the Terms, then the customer may elect to not place new orders or renew. In limited circumstances, such as in response to changing Laws, as specified in Sections 24.4, Atlassian may need to implement modifications to the Terms mid-Subscription Term. In such a case, then Atlassian will provide a notice and objection period, during which the customer may assess the modifications. If the customer objects, then the customer may terminate their Subscription Term, with a pro-rata refund of any prepaid fees.

Typically modifications to these terms only happen for a customer at renewal, except for in some cases where we're absolutely obligated to, like when we had to support GDPR.  These changes in terms are also not much different between our cloud, another vendor's cloud, or even our on-prem solutions that have to be agreed to with each renewal as well.  So I think these are generally in-line with standard practice, but I hear where your concern comes from.  The good news is, you always do have the ability to get access to your data through our Site Backups. So I hope there isn't a fear that you would lose your data. 


On your question:

- data residency: if data is stored OR PROCESSED abroad, foreign state authorities may enforce access not only to our data, but also to data relevant for our customers. As far as I have seen this happened around 40 times in 2019.

This is an area more under my area of expertise but also wanted to make sure I was getting the right answer since this is more on the side of legal/privacy. The response from our team is this:

Atlassian responds to government requests in accordance with our Guidelines for Law Enforcement, Privacy Policy, customer agreements, Acceptable Use Policy, and any applicable Product-Specific Terms. Your trust is important to us, and we provide Customer Information in response to law enforcement requests only when we reasonably believe that we are legally required to do so. To protect our customers’ rights, we carefully review requests to ensure that they comply with the law.

To obtain Customer Information from Atlassian, law enforcement officials must provide legal process appropriate for the type of information sought, such as a subpoena, court order, or a warrant. For example, Atlassian will not provide non-public customer content unless served with a valid search warrant, issued on a showing of probable cause by a federal or state court authorized to issue search warrants, which requires Atlassian to disclose the content. We publish an annual Transparency Report with information about government requests for users' data as well as government requests to remove content or suspend accounts.

For more information around how we encrypt and protect your data in transit and at rest, see here.


And finally, on your question:

Atlassian+Amazon will be responsible for backup the cloud instance. If data is lost, Atlassian will most likely NOT compensate us for all the financial loss.

This one I'm not very familiar with when it comes to our terms and services, so I asked the legal team if they could help me provide a clear answer, and here that is:

Because Sensitive Personal Data is expressly prohibited from being used in the Cloud Products, per Section 5.3 of the Cloud Terms of Service, Atlassian believes that its limitation of liability is commensurate with the nature of the Customer Data likely to be processed in the Cloud Products. As with any Cloud provider, Atlassian is not able to accommodate unlimited liability associated with processing data, and Atlassian is continually investing in its Security Practices, noted in Section 4.1 of the Cloud Terms of Service, designed to provide industry leading security controls that most customers would not be in a position to implement and maintain for themselves. These Security Practices are outlined in our Trust Center, and are independently audited as set forth in our industry standard certifications and attestations.


My main takeaway from these, and I encourage you to check out the links, is in how seriously we take our commitment to protecting our customers' data and meeting our obligations to you as our customer, as well as meeting the requirements laid out by the law.  I'm not sure I'll be able to provide much further clarity on any of the legal sides of these in this forum.


Hi @RJ Gazarek ,

I appreciate your response to the questions you were asked. Unfortunately, I am still having a hard time understanding how the answers you provided are able to give cloud customers the information they need to know that their data will be safe even if they pay the premium for data residency.

There are two important things you touched on. The first was the policy regarding ToS changes:

As set forth in Section 24.4 "Paid Subscriptions" of the Atlassian Cloud Terms of Service (provided that the customer has purchased a Cloud Product), modifications to the Terms will take effect at the start of the customer's next purchase or renewal.

The first is this policy, which could result in a company having a range of either 1 day at the absolute minimum, to 30 days at the maximum for monthly customers, to up to a year potentially for your annual customers. What guarantee do customers have that this review period will not be as short as a single day?

The second important point is this:

Atlassian responds to government requests in accordance with our Guidelines for Law Enforcement, Privacy Policy, customer agreements, Acceptable Use Policy, and any applicable Product-Specific Terms. Your trust is important to us, and we provide Customer Information in response to law enforcement requests only when we reasonably believe that we are legally required to do so.

This is all fine for information on government requests, but the government isn't necessarily who customers should be worried about. Your guarantees here end up muted by the actual details of your Acceptable Use Policy.

Specifically, these two sections, when taken together:
The first says that you may not post, upload, share, submit, or otherwise provide in any manner content which:

Is deceptive, fraudulent, illegal, obscene, defamatory, libelous, threatening, harmful to minors, pornographic (including child pornography, which we will remove and report to law enforcement, including the National Center for Missing and Exploited Children), indecent, harassing, hateful

The second section states that:

Without affecting any other remedies available to us, Atlassian may permanently or temporarily terminate or suspend a user’s account or access to the services without notice or liability if Atlassian (in its sole discretion) determines that a user has violated this Acceptable Use Policy.

Which legal authority, if any, defines if the content uploaded violates any of those policies? For example, the Obscenity Law in the United States is much different than the Obscenity Law in Canada and even varies state by state.
From the second statement, it seems that Atlassian is the one who acts as the sole judge, jury, and executioner on such matters, and it has been previously stated that Atlassian employees very much do have access to our data, and there is no way to prevent this.

What good are guarantees against the local government if our data is still subject to the whims of Atlassian's corporate convictions?
Under these terms, Atlassian could completely legally, immediately and without notice, delete the sensitive data of a foreign government simply because they felt like even a single piece of that government's data violated its policies.

NIST asks organizations to "formally addresses the risks associated with using 3rd party vendors", but how can we formally address the risk presented to us while using Atlassian's cloud products if the risk is, at it's core, entirely down to Atlassian's sole subjective discretion?
Atlassian knows the benefits of implementing a proper Zero Trust policy, but how can customers do the same if you are asking them to trust that you will not arbitrarily delete their data as soon as it becomes too 'inconvenient' for you?

Thank you, and I look forward to hearing your response to these concerns.

Hi @Scion thanks for your questions and feedback.  What you're touching on has to do with our cloud policy in general as well as comfort level with using any SaaS vendor,  and doesn't really touch much on data residency specifically, which this thread is meant to collect feedback for.  I won't be able to answer these, I'll see if I can find someone who can, or point you in a better place to raise these concerns.  

Tianyi Peng Atlassian Team Dec 14, 2020

Hi everyone, we at Atlassian are thinking about pushing out a data residency related feature to help address our customers’ requests. Please let us know if you or someone on your team is interested in connecting with us in the next few weeks. We would love to seek some feedback after we share some further details about this initiative.

Yes, please contact us. We need a swiss datacenter option.

RJ Gazarek Atlassian Team Feb 10, 2021

Hi @Marcel Ringler - just to provide some clarity, I'll add your feedback looking for a Swiss datacenter. Right now, we are limited to where AWS has a presence first and foremost, followed by where the majority of our customer demand is.  Right now AWS does not have a swiss presence, although I believe it's on their plan to open one.  Once it does, we will assess demand for customers wanting their data stored in Switzerland. 

Hi Mr. Gazarek

Thanks, but Amazon, Google and Microsoft are all American companies. Why not add a non-American alternative? There are Swiss companies, which offer AWS like services, e.g. and 



Like RJ Gazarek likes this

After having read the above discussion, I like to add a few comments:

- we write software for tax declaration. Tickets in Jira and documentation in Atlassian Tools potentially contain sensitive data from customers.

- we have signed legal contracts with the  tax offices to not disclose tax data to third party. In fact, we may face prison, if tax data is stolen.

- in the past, Germany has paid millions for and even initiated illegal theft of tax data:

- Germany and US can demand data from companies like AWS, even if the data is stored abroad. They can do according to: and they will do, because they did in the past. The problem here is simply, that with 'law' each country seems to mean something different.

- we integrate our CI/CD pipeline with Jira.

Our privacy concern:

If we choose a cloud or DC solution, it needs to be secure, and it needs to be stored in Switzerland by a company not under direct or indirect control of any foreign government. The company must sign a contract ensuring privacy.

Like Tommy likes this


sitting in Germany (and not really being unhappy of some tax information holes in the past): regarding your concerns I completely agree. I assume MANY companies store sensitive data in Jira (hey, we are not all toy companies, are we?).

Having control over data access to our core company/customer information is vital for many of us.

Since Jira seems to drop that control when moving to cloud, it's loosing a vital feature. And Atlassian may loose several customers.

Like # people like this
RJ Gazarek Atlassian Team Feb 15, 2021

Hi @Marcel Ringler 

Because of your commitment to your clients, you may have to consider altering how you leverage Jira/Confluence and ensure your employees aren't storing overly sensitive data in Jira/Confluence.  Making sure that Jira is used just to track the progress of work, and Confluence is used for collaboration.  Then you can keep all sensitive data on your local storage/network, and use a link in your Jira/Confluence pages that can be accessed only while people are on your network.  That way you're not storing the actual sensitive data in the cloud.  Our terms and service also direct people not to store sensitive personal data in the cloud. 

With respect to adding a non-US based company.  Adding an additional provider, whether it's US-based or non-US based is not an easy/simple task.  Our product is built with reliance on AWS services, so to do so, would require us to re-architect our product for nearly every company in order to adopt to a local provider in each country.  Just as you raise a question about having data stored with a US provider, another country would have questions about data stored with a Swiss provider.   While it's not completely out of the question of course, it's a pretty massive level of effort.  

@RJ Gazarek:

"Our product is built with reliance on AWS services, so to do so, would require us to re-architect our product for nearly every company in order to adopt to a local provider in each country. "

From a distance, I think that's the burden Atlassian has taken on its shoulders: Instead of allowing each customer to select/create the crucial operating environment for Jira that matches this customer's needs, Atlassian needs to provide a "one size fits for all" environment that more or less fulfills the needs of ALL customers. Doing so and making customers happy with it is ...tricky.

Like # people like this
RJ Gazarek Atlassian Team Feb 15, 2021

@Thomas Dörfler oh yeah for sure! I'm also not sure I'd call it a burden really.  A lot of AWS allows us to move quickly and build really amazing products in the cloud for our customers.  If we had to rearchitect this across multiple cloud providers (again not saying that's out of the question) we would be nowhere near satisfying our customers today, we would have to have slowed our roadmap down by several years.  The good news is, there are still answers for folks who aren't ready for our cloud yet.  We still have our Datacenter offering of course, and for those that want to move to cloud, there are ways to change workflows to ensure the overly sensitive data stays locally on your network.

These discussions are always helpful, and I hope some of the questions I've asked get answered because they help us build a product that meets the needs for as many customers as possible.  I hope you can understand that is what we are trying to do with our cloud offering.  It wouldn't make much sense for us to only make it work for a small part of our customer base, so we take these decisions very seriously. And as for Data Residency, with a lot of the feedback, we're seeing what we can do to accelerate some of this work, and seeing how much more we can do so our customers feel comfortable.  

I appreciate you being active in the thread, if there are other specific questions I can help answer, let me know.  

Hi, I follow this discussion with high interest. I think the most of “out of US” companies have the same challenges with Atlassian as soon as they will shoot down the local server solution.

For my perspective (GxP validation) it would be very helpful to have evidence and agreements from Atlassian and AWS, how they work together. I think, if we know how the relationship is and were the data hosted, we can asset the risk better.

AWS provided a with paper in 2016. In chapter “3.1.5 Product Assessment” is a great overview (, were the challenge is. Atlassian should define the responsibility of requirements for each box. AWS talking about “Costumer Responsibility and AWS Responsibility”. From my point of view, we as “End User” will have a SLA with Atlassian based on GxP requirements (similar to other requirements and regulations like GDPR and DSVGO). The GxP Applications requirements will be defined and agreed together with Atlassian, but all other technical requirements (Server, Database etc.) must be agreed with AWS and Atlassian responding to the regulation. Atlassian should provide and show that agreement to us costumers.

I think this would be a practicable and helpful way to bring up a solution soon.

Or Atlassian promise to support the Server version till 2050 😉

RJ Gazarek Atlassian Team Feb 16, 2021

Hi @Torsten Klaus ! We can tell you where the data is stored, that's relatively easy for us.  As far as the agreement between AWS and Atlassian.  Let me take this feedback/ask back to the privacy/legal team and see if we have something around this already.  

Thank you very much @RJ Gazarek ! It would be a great help, if you can show me this part in the privacy as soon as it is done from your team. Please send a link were the data are stored at AWS in the EU/CH.

I know the personal data are managed from Atlassian in US. This is for me an other topic to see, how it will be solved.

RJ Gazarek Atlassian Team Feb 17, 2021

Hi @Torsten Klaus

I'm so sorry, I meant to link our data residency documentation page in my last reply:

this page tells you which products and types of data we store in which region depending on the region you choose in your product.  Right now, it's limited to EU & US. With EU datacenters being in Dublin and Frankfurt.  

On our roadmap, you can see we are also going to be introducing UK, Canada, Australia, and Japan in the next 12-18 months. 

Like Torsten Klaus likes this

Thanks a lot @RJ Gazarek for help. I haven't seen this page before, sorry.

I like your last sentence: Providing the server version till 2050 would just about cover it.

Kesha Thill Atlassian Team Mar 08, 2021

Hi all! Just an update to this thread - we recently announced that data residency will be included in our Standard and Premium cloud plans later this year, which includes the option to host your data in the US or EU, with additional geographies coming soon. To learn more and sign up for updates, visit our page here

To see what else we're working (like additional geographies and functionality) related to data residency, visit our cloud roadmap here.

Hello all!

I am a bit late to the discussion, but nevertheless want my view documented. I am operating a small confluence server in my basement to document my home IT setup and some other things I find noteworthy. I am very fond of confluence as a tool and have so far gladly paid the 10$ per year for my minimum licence.

Now I do not care about regulations and GDPR and whatnot and I am not a company. Unfortunately I do not qualify as a non-profit or charitable organisation for the community licence, either.


So what can I do? Quit using confluence, port all my content onto some other tool and say goodbye to years of gained ability to use the tool. Why? Because Atlassian like so many other companies wants to have more control over their customers and force them onto their cloud environment and give them no other viable alternative.

Oh, and just on the by and by: My small mini-PC (intel NUC with an i5 CPU) in my LAN performs in orders of magnitude better than the free confluence cloud version I have tested. Which comes as no surprise, my PC is in the LAN with 2ms roundtrip time, the server in the cloud has at least some 30ms roundtrip ... do the math or go stick your head in a pig!

I am quite frustrated. Feel free to comment.



Log in or Sign up to comment

Atlassian Community Events