Possible Confluence and Synchrony Configurations
Synchrony is the engine that powers collaborative editing in Confluence.
There are a few different options for running Synchrony, and it is worth taking some time to determine which option will best meet the needs of your organisation.
On this page:
Possible configurations for Confluence Server
If you have a Confluence Server license, Synchrony is managed by Confluence.
The diagrams below show examples of a common implementation where Confluence is running under the /confluence context path (e.g. www.mysite.com/confluence). The concepts are the same if you use Confluence without a context path (e.g. www.myconfluence.com).
No reverse proxy
If you don't run Confluence behind a reverse proxy, you'll connect to Synchrony via Confluence's internal Synchrony proxy. SSL, if used, is terminated at Tomcat. This is the default configuration, and you shouldn't need to make any additional changes to use collaborative editing.
With a reverse proxy
If you run Confluence behind a reverse proxy, you will connect to Synchrony via Confluence's internal Synchrony proxy. This is the default configuration with a reverse proxy, and a good choice if you do not want to open port 8091. SSL should be terminated at your reverse proxy.
You do not need to make any additional changes to your reverse proxy configuration for Synchrony, but for best results your reverse proxy must support WebSocket connections (you may need to manually enable this in your proxy).
To tell Confluence that you want to use the internal proxy, set the
synchrony.proxy.enabled system property to
true. (This is optional, but will prevent Confluence from trying to reach Synchrony via /synchrony first, before retrying via the internal proxy).
If Synchrony can't be reached via /synchrony-proxy we'll automatically try /confluence/synchrony-proxy (where /confluence is your Confluence context path).
Direct to Synchrony with a reverse proxy
If you run Confluence behind a reverse proxy, and experience latency or other issues connecting to Synchrony via Confluence's internal Synchrony proxy, you can choose to connect direct to Synchrony. This is the optimal setup, but does require some changes to your environment. You will need to open port 8091 and add /synchrony to your reverse proxy configuration. SSL will still be terminated at your reverse proxy, as Synchrony does not accept direct HTTPS connections.
If Synchrony can't be reached via /synchrony we'll automatically try the internal Synchrony proxy via /confluence/synchrony-proxy (where /confluence is your Confluence context path).
See the following guides for example reverse proxy configurations. The order of directives is important, so check our examples.
- Using Apache with mod_proxy
- Running Confluence behind NGINX with SSL
- Proxying Atlassian server applications with Apache HTTP Server (mod_proxy_http)
- Proxying Atlassian server applications with Microsoft Internet Information Services (IIS)
- How to configure Amazon Web Service Elastic Load Balancer with Confluence
Possible configurations for Confluence Data Center
If you have a Confluence Data Center license, two methods are available for running Synchrony:
- managed by Confluence (recommended)
Confluence will automatically launch a Synchrony process on the same node, and manage it for you. No manual setup is required.
- Standalone Synchrony cluster (managed by you)
You deploy and manage Synchrony standalone in its own cluster with as many nodes as you need. Significant setup is required. During a rolling upgrade, you'll need to upgrade the Synchrony separately from the Confluence cluster.
If you want simple setup and maintenance, we recommend allowing Confluence to manage Synchrony for you. If you want full control, or if making sure the editor is highly available is essential, then managing Synchrony in its own cluster may be the right solution for your organisation.
Managed by Confluence
Here's a simplified view of the architecture when Synchrony is managed by Confluence. This is the recommended approach, as no manual set up, or ongoing upgrades are required - it works right out of the box.
If you choose this approach, the guidance provided for Confluence Server above, also applies to your load balancer and any proxies.
This option is only available in Confluence 6.12 and later.
Standalone Synchrony cluster
If you choose to manage Synchrony yourself, the architecture looks more like this. Again the diagram has been simplified, and doesn't show communication between nodes.
If you choose this approach you will need to:
- Set up and manage multiple Synchrony cluster nodes.
- Always start Confluence with the
synchrony.service.urlsystem property (this tells Confluence where to find your Synchrony cluster, instead of launching a Synchrony process on the current node).
- Open the Synchrony port (8091), as the Synchrony proxy is never used when you manage Synchrony yourself.
- Terminate SSL at your load balancer. Synchrony cannot accept HTTPS connections.
- Upgrade Synchrony manually, each time you upgrade Confluence.
In most cases, two Synchrony nodes will be adequate for multiple Confluence nodes.
For a step-by-step guide to setting up your Synchrony cluster, see Set up a Synchrony cluster for Confluence Data Center.
If you enabled collaborative editing prior to Confluence Data Center 6.12, standalone Synchrony will be your default setup.
If you would prefer a less complex setup, see Migrate from a standalone Synchrony cluster to managed Synchrony to find out how to allow Confluence to manage Synchrony for you.