External use of Jira


We have Jira + GH + confluence + tempo on premise installation.

We use Jira internally for tracking bugs, managing tasks (requirements, stories, etc.), knowledge base and managing releases (to QA, integration and customer).

We're thinking of opening our Jira for external use by our customers and partners.

What would be the best way of doing it?

How do you do it?

What is the relation between the external content and the internal content (i.e. when a customer reports a bug, how it interface with the internal system?).


Janiv Ratson.

2 answers

Hi janiv,

There are a couple ways you could do this. One is to grab an unlimited-user license for JIRA and then open-up JIRA to public signups:


Then your customers and partners could sign up for their own account, submit bugs, etc.

You can also partition JIRA so that user groups do not see projects or issues not related to them:


Alternatively, if you don't want to purchase an unlimited-user license, you could open up your JIRA instance to anonymous access:


You can restrict which issues/projects these users can see, just like any other user group.

At Atlassian, we have public projects for each of our products and internal private projects also. When a user reports a bug in the public project and we verify it, we clone it to the development project and track it there. Both issues are resolved when we release a new version.


Thanks for the great answer.

The only relevant option for me is partitioning.

Currently we have about 5-10 operative customers.

I also have another option: establish another instance of jira (up to 10 users) on external server.

I'll manager the accounts. My customer will then report issues via this external jira.

Our customer support people will "listen" on this jira instance, and whatever is relevant, they will "move" to our internal jira instance.

Which of the two options is better?



Two JIRA's is twice the admin, cost ongoing etc. Flipside, one JIRA is 'ok' for data partitioning, but you have to manage your security carefully, for example making 'jira-users' an 'access' role rather than having anything to do with project security. Do that and #2 wins IMO. If you are not so much concerned about cost and more concerned about isolation, #1 would win.

The main concern is that the only jira instance resides on the DMZ with all our company crucial information.

Having two jira instances, I leave only the external instance, with only the customers information some exposed to the public, whereas our internal instance resides behind our great firewalls.

What do you think?



Hi Janiv,

As I said, if you're more concerned about data safety/integrity that cost, in your instance another JIRA would work well. It's nice to be able to give users direct JIRA access where possible, failing that you could use an email only approach, allow create/comment by email, it really depends on what your support model is.

Hi there, so if we do not want to install twice (internal and external) the only way would be to let clients access the internal area via secure SSL tunnel. Even in case we use the anonymous way we have to let external  users access the internal installation? Right?

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,711 views 17 21
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you