Administering Confluence Data Center on Azure

Getting started with Confluence Data Center on Azure

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community

Once you've deployed Confluence Data Center to Azure using the deployment template, administering the application is similar to managing an application on your own hardware, with the exception that you'll need to go via the jumpbox to access your nodes. 

To access your jumpbox and nodes you'll need:

  • the SSH credentials you provided during setup,
  • the Confluence / Synchrony node credentials you provided during setup
  • the public DNS name or IP address of your jumpbox (you can obtain this through the Azure portal via Menu > Resource groups > <your resource group> > confluencenat), and
  • the node IP addresses, listed against the confluencecluster (instance n) row in Connected devices. (You can obtain this through the Azure portal via Menu > Resource groups > <your resource group> > confluencevnet).

Connecting to your Azure jumpbox over SSH

You can SSH into your Confluence cluster nodes, Synchrony nodes and shared home directory to perform configuration or maintenance tasks. Note that you must keep your SSH public key file in a safe place. This is the key to your jumpbox, and therefore all the nodes in your instance. 

Access the jumpbox via a terminal or command line using:


Once you've accessed the jumpbox, we can jump to any of the nodes in the cluster, using:


You'll then be asked for your node password - after providing this, you should be connected to the node.

Accessing your configuration files

For your Azure deployment, you may need to make changes to some configuration files, just as you would for a deployment on your own hardware:

  • your server.xml lives in /opt/atlassian/confluence/conf
  • your lives in /opt/atlassian/confluence/bin
  • your local home confluence.cfg.xml lives in /var/atlassian/application-data/confluence
  • your shared home confluence.cfg.xml lives in /media/atl/confluence/shared

These files are only accessible from the existing nodes. The shared home is mounted (think of it as a network hard disk) on each node under /media/atl/confluence/shared. So from an existing node (when you're logged in through SSH), you can go to /media/atl/confluence/shared

If modifications to these files are made manually, new nodes will not pick up those modifications. You can either repeat the modifications on each node, or change the templates in the /media/atl/confluence/shared directory from which those files are derived. The mappings are:

  • the server.xml file is derived from /media/atl/confluence/shared/server.xml
  • the file is derived from /media/atl/confluence/shared/
  • the local home confluence.cfg.xml is derived from /media/atl/confluence/shared/home-confluence.cfg.xml
  • the shared home confluence.cfg.xml is derived from /media/atl/confluence/shared/shared-confluence.cfg.xml

These template files contain placeholders for values that are injected via the deployment script. Removing or changing them may cause breakages with the deployment. In most cases, these files should not be modified, as a lot of these settings are produced from the Azure Resource Manager templates automatically.

Backing up

We recommend you use the Azure native backup facility, which utilizes snapshots to back up your Confluence Data Center instance.

Migrating your existing content into Azure

To migrate content from an existing site into your Confluence Data Center site on Azure you will need to take a full site export, and then import it into your new Confluence site.

See Manually Backing Up the Site for information on how to export your site, and Restoring a Site for information on how to import it into your new site on Azure. 

Make sure you have the Administrator account credentials for your existing site, as the administrator account you created during Azure deployment process will be overwritten by the export, and you may be locked out of your site. 

Upgrading Confluence in Azure

The process of upgrading Confluence is the same as if you were running the cluster on your own hardware. You will stop Confluence on all nodes, upgrade one node, stop that node then copy the installation directory across to each remaining node in the cluster, before restarting each node, one at a time.    

See Upgrading Confluence Data Center for more details. 

You can't use the confluenceVersion parameter in the deployment template to upgrade an existing Confluence deployment, or to provision new nodes running a different version to the rest of your cluster.

Last modified on Aug 13, 2018

Was this helpful?

Provide feedback about this article
Powered by Confluence and Scroll Viewport.