Data Center architecture and infrastructure options
This guide outlines the architecture and infrastructure options available when deploying Jira Software, Jira Service Management, Confluence, and Bitbucket Data Center.
Architecture options
You can deploy Data Center in two ways:
| Option | Description | Recommended use cases |
|---|---|---|
| Non-clustered (single node) | Your application (Jira, Confluence, or Bitbucket) runs on a single server or node. |
|
| Clustered | Your application (Jira, Confluence, or Bitbucket) runs on multiple application nodes configured in a cluster. This architecture requires specialized components, such as a load balancer. |
|
Server products only support non-clustered architecture. Data Center supports both non-clustered and clustered options.
Non-clustered (single node)
In this setup, your Data Center application runs on a single server—just like a Server installation.
Diagram: example non-clustered Data Center architecture
As you can see, Data Center deployed on a single node looks just as a Server installation and consists of:
- Jira, Confluence, or Bitbucket running on a single node
- A database that Jira, Confluence, or Bitbucket reads and writes to
Benefits
If you’re deploying new infrastructure with your Data Center product, you can use the same architecture as for Server installations.
Is a non-clustered architecture right for you?
In general, we recommend considering a non-clustered Data Center deployment if:
- you only need Data Center features that don't rely on clustering
- you’re happy with your current infrastructure and want to migrate to Data Center without provisioning new infrastructure
- high availability isn’t a strict requirement
- you don’t immediately need the performance and scale benefits of clustered architecture
Considerations
Non-clustered Data Center is the simplest setup, but it has some limitations. You’ll still have the application server as a single point of failure, so it can’t support high availability or disaster recovery strategies.
Some deployments start to experience performance or stability issues once their size profile hits Large or XLarge. Most clustered deployments provide you the flexibility to scale up your infrastructure to address heavy loads (or even scale down to save costs during light loads). On AWS or Azure, you can also quickly address most stability issues by replacing misbehaving nodes with fresh ones.
Switch to clustering when you need it
If you choose non-clustered Data Center, you still have the flexibility to change your architecture later. You can configure clustering at any time with the same license—no reinstallation required.
Clustered
Data Center allows you to run your application in a cluster with multiple nodes and a load balancer to direct traffic. This is important for organizations where high availability and performance at scale are essential for every team to be productive.
Diagram: example clustered Data Center architecture
A clustered setup includes:
- Multiple identical application nodes
- A load balancer to distribute traffic to all of your application nodes
- A shared file system
- A shared database that all nodes read and write to
- For Bitbucket, you’ll also need a dedicated node for ElasticSearch that all nodes read and write to.
Benefits
Clustering has a number of benefits:
- High availability and failover: If one node in your application cluster goes down, the others take on the load, ensuring your users have uninterrupted access to the application.
- Performance at scale: each node added to your cluster increases concurrent user capacity, and improves response time as user activity grows. You can also deploy nodes dedicated to specific functions.
- Instant scalability: add new nodes to your cluster without downtime or additional licensing fees. Indexes and apps are automatically synced.
- Disaster recovery: deploy an offsite Disaster Recovery system for business continuity, even in the event of a complete system outage. Shared application indexes get you back up and running quickly.
Considerations
Compared to non-clustered Data Center, clustering requires additional infrastructure and a more complex deployment topology, which can take more time and resources to manage. You can help mitigate this complexity by deploying on public cloud infrastructure such as AWS (Amazon Web Services) or Azure.
Infrastructure options
You can choose to deploy Atlassian Data Center applications on the infrastructure of your choice:
- your own physical hardware (on premises) or virtual machines
- a Kubernetes cluster using Data Center Helm charts
- a public cloud provider like AWS (Amazon Web Services) and Azure. This is also known as infrastructure as a service (IaaS).
Which infrastructure option is right for you?
We leave it up to you to choose which infrastructure option best suits your organization’s requirements and existing investments.
More and more customers are choosing to deploy Atlassian Data Center products using a cloud provider like AWS because it can be more cost effective and flexible than physical hardware.
Install on a Kubernetes cluster
Kubernetes allows you to drive greater agility amongst your teams and enjoy a simplified administrative experience at scale without compromising your organization’s regulatory requirements.
To help you deploy our products, we’ve created Data Center Helm charts—customizable templates that can be configured to meet the unique needs of your business. You can even choose how to run them: either on your own hardware or on a cloud provider’s infrastructure. Learn more about running your products on a Kubernetes cluster
Deploy using a public cloud provider
The Azure Resource Manager template and the AWS Quick Start template are no longer supported by Atlassian. You can still use these templates, but we won't maintain or update them.
We recommend deploying your Data Center products on a Kubernetes cluster using our Helm charts for a more efficient and robust infrastructure and operational setup. Learn more about deploying on Kubernetes.
AWS now recommends switching launch configurations, which our AWS Quick Start template uses, to launch templates. We won’t do this switch, however, as we've ended our support for the AWS Quick Start template. This means you're no longer able to create launch configurations using this template.
To help you design and deploy Data Center infrastructure, we provide the AWS Quick Start template. Though still usable, this deployment method is no longer supported or maintained by Atlassian and we recommend deploying your Data Center products on a Kubernetes cluster using our Helm charts due to the many advantages offered by Kubernetes.
The AWS Quick Start tool uses sensible defaults and settings for a wide variety of customer deployments. It also applies many of our infrastructure recommendations automatically. It's designed to deploy cluster-ready architecture, starting with a single node that you can scale up as you need.
Head to our product guides to find out what’s involved with this option.
AWS
These resources (published and hosted on AWS Quick Starts) use AWS CloudFormation templates to deploy Atlassian Data Center applications on AWS, following AWS best practices: