• Products
  • Documentation
  • Resources

How many instances of a product does my organization need?

An Atlassian organization gives you the opportunity to manage all your company’s products from one central location, whether you have a single product or multiple instances of each product.

Many cloud customers want to know whether they should have one or multiple instances of a product, but it’s not a one-size-fits-all model. Your company’s business structure, security policies, and product customization needs influence the number of product instances within your organization.

Single-instance model

Many companies find that one instance of each product works well for their organization.

Diagram of an organization where users have a single site URL for all Atlassian products, with one instance of each product.

In this model, users at your company have a single site URL for all Jira projects, Confluence spaces, and the rest of the products associated with the site. As an admin, you have a single set of configuration settings for each product.

As your company grows, your product instances can grow with it. You can give up to 20,000 users access to each instance of Jira Software, Jira Work Management, and Confluence and up to 5,000 agents access to each instance of Jira Service Management.

Multiple-instance model

Multiple instances offer the flexibility to support more complex scenarios at your company. This way you can manage your organization efficiently as the number of users and products grow. At the same time, individual teams can manage their own instances, giving them the opportunity to work more effectively.


Common drivers for multiple instances

With a multiple-instance model, instances of a product can support separate teams or business requirements. For example, if one team needs a product configuration or a Marketplace app, you can create one instance of a product for the users on that team.

The table lists some of the most common reasons customers set up multiple instances.



Separate departments and teams

An organization may have separate product instances for different lines of the business to provide autonomy for departments or teams.


An organization may have separate instances for users that deal with company sensitive and proprietary information.

Data isolation

An organization may have security and compliance needs that require data to never leave a region.

Mergers and acquisitions

After a merger or acquisition, an organization may want to preserve the autonomy of the new team and keep their instances separate.


An organization may want separate instances for an office site or geographical region.

User-created instances

It’s possible that your users create their own instances to use with their team. When that happens, you may not be aware those instances exist because they’re not centrally managed from your Atlassian organization.

Diagram of an organization where users create their own instances.

You may choose to do nothing and allow users to continue managing their instances separately, which keeps those products separate from your Altassian organization.

Alternatively, you may want to manage all products centrally. This gives you insight into the product usage and security posture across your company and control over user count for billing purposes. In this situation, we recommend having a discussion with the individuals who created those instances. After that discussion, you can decide how you want to consolidate those instances into your organization.

One option for consolidation is to transfer these products to your company’s Atlassian organization. When a transfer happens, users who are managing a product can keep their admin permissions for the product. Learn about how to transfer products

Atlassian’s use of a multiple-instance model

At Atlassian, we’ve found that a multiple-instance model suits our company best. When it comes to Jira, we have one main instance of Jira Software that teams throughout our organization can use. We also allow individual teams to create their own Jira instances within our Atlassian organization:

  • The Jira development team has their own customized instance.

  • The finance and security teams have their own instances to keep sensitive data separate.

  • The support team has a highly-customized instance to keep up with and track incoming support tickets.

This illustration demonstrates a snapshot of the types of Jira Software instances that teams use here at Atlassian.

Diagram of an Atlassian's multi-instance model, where each team has its own instance.

Multiple instances with Enterprise plans

In a multiple-instance organization, you may subscribe to any combination of four product plan types (Free, Standard, Premium, or Enterprise).

With an Enterprise plan, you get an additional benefit with a multiple-instance product model that you don’t get with other plans. You pay for a single user only once as part of your payment plan, and that user can access multiple instances of the same Enterprise product.

The table includes more details about the differences between Enterprise plans and the other plans.


Enterprise plans

Standard / Premium plans

Free plans

Number of product instances associated with a plan

As many as you need

(e.g. all Jira Software Enterprise instances in one plan)


(e.g. one instance of Jira Software Standard per plan)


(e.g. one instance of Jira Software Free per plan)

How that impacts your payments

Pay per user to access many instances of the product

Pay per user to access only one instance of a product

No payment for Free plans

Why this matters

With an Enterprise plan, you don’t have to pay for the same user multiple times. Learn more about Enterprise plan billing

The illustration demonstrates these differences with the example of a Jira Software Enterprise plan and a Jira Software Standard plan.

Diagram of an organization wit a Jira Software Enterprise plan and a Jira Software Standard plan.

Additional Help