Non-cluster upgrade

Single node deployments cannot be performed without downtime. To upgrade a single instance deployment, follow the instructions below:

  1. Stop your instance

  2. Replace your XP7 runtime image with the new XP7 image

  3. Start the instance.

Rolling Cluster upgrade

All fix upgrades (i.e. from 7.4.1 to 7.4.8), and most feature upgrades (i.e. from 7.5.x to 7.6.x) support rolling upgrades - with zero downtime.

To safely perform a rolling upgrade, perform the following steps.

WARN: Before you perform a rolling upgrade, verify that all feature version in your upgrade path (from version → to version) support rolling upgrade

  1. Upgrade only one node at a time. Wait for the node to start and join the cluster before you move on

  2. Stop, upgrade image and start your master nodes first (We always recommend using dedicated master nodes)

  3. Stop, upgrade image and start data nodes

  4. Stop, upgrade image and start remaining nodes

Full restart Cluster upgrade

Selected feature versions (i.e. from 7.6.x to 7.7.x) may require a full restart in order to guarantee no loss of data and/or state. Releases that require full restart are explicitly listed below.

This strategy may safely be applied to upgrading any xp cluster and/or version

Follow the steps below to complete a restart upgrade:

  1. Stop all cluster nodes

  2. Replace the xp runtime image with the new for all nodes

  3. Start all nodes in parallell

It is important to start the nodes at the same time to avoid timeouts, should any upgrade scripts be supplied with the new version.


When upgrading to new feature versions of Enonic XP, new versions of standard apps may also be available.

After upgrading XP, check for new versions of your installed applications from Enonic market. We generally always recommend updating your apps to the latest version!

v7.7 notes

FULL RESTART REQUIRED - For security reasons, XP’s clustering engine (Hazelcast) has been updated in this release. A full restart is required in order to prevent loss of data or state.
  • Session cookie specifies SameSite=Lax by default. It is similar to modern browsers default value except for "Lax + POST mitigation". You can revert to previous behavior by setting session.cookieSameSite = in Configuration Files / Jetty

  • Native Java primitive arrays are now converted to JavaScript arrays. You may have to adapt your application to the new behaviour if your code was using workarounds.

  • Image Service now limits maximum image size and number of filters applied. You can configure thresholds in Configuration Files / Image

  • Image Service has more eager validation of scale, filters, background and quality parameter values. Make sure the requests to Image Service use only correct/supported values.

  • Built-in Embed Macro now requires body part to be HTML escaped. In general, it should not cause issues because ContentStudio HTML editor always escapes macro body.

  • Content attachment file names can no longer contain suspicious characters. You can revert to previous behavior by setting attachments.allowUnsafeNames = true in Configuration Files / Content

  • Assets Service URL fingerprint part now uses application’s "build time" instead of application’s startup time. Make sure "build time" always changes for new versions of an application (this happens automatically if you use the standard xp build system)

  • Default Cache-Control headers for Assets Service and Portal Media Attachments have been changed. You can change default settings in Configuration Files / Portal

  • ResourceService no longer considers directories in jar as existing resources. If application code relies on checking directory existence in jar, consider checking existence of a file inside that directory instead.

  • Content integrity is verified during move operation, as it was done on create for page-template, template-folder and site built-in content types.

  • page-template content now accepts child content, but only fragment and media:*. Attachments are no longer redirected to the nearest template’s site.

  • input-type’s allow-content-type, x-data allow-content-types and newest content-type’s allow-child-content-type share the same pattern matching, that is stricter than before. You can switch back to legacy mode by setting contentTypePatternMode = LEGACY in Configuration Files / Admin for allow-content-type and allow-content-types, but it won’t affect allow-child-content-type pattern matching.

v7.6 notes

  • Named tasks do not necessarily execute on the node they were submitted on anymore. Instead, a random node capable to run a task is selected and task gets executed there. Make sure your named tasks do not require a specific node to be run on. Follow the Tasks / Distributable for more information.

  • XP does not proxy market.enonic.com requests anymore, meaning that browser should have access to https://market.enonic.com. URL can be changed in Configuration Files / Market.

v7.5 notes

v7.5 is backward compatible with earlier versions

v7.4 notes

v7.4 is backward compatible with earlier versions, but if you run XP on a cluster, several configurations need to change for the nodes to get in touch with each other after the upgrade. Please do the following:

  • Create the configuration files com.enonic.xp.hazelcast.cfg and com.enonic.xp.web.sessionstore.cfg and consider the values in them as described in Configuration Files / Hazelcast and Configuration Files / SessionStore.

  • Open port 5701 between the nodes in the network. This port is used by Hazelcast for internal communication in the cluster. An alternate port may be chosen by setting network.port. If using Docker, the port needs to be opened both in the network and in the docker-compose.yml container definition.

  • Evaluate the minimum required number of nodes in a cluster. system.hazelcast.initial.min.cluster.size is by default set to 2. During start-up, events, tasks and sessions will not be communicated between nodes in the cluster until the minimum number of nodes have signed in. For large clusters, this is an important setting. We recommend setting it to nodes/2 + 1, so for instance, in a cluster of six nodes, the value should be 4.

  • Distributed Sessions are off by default. Enable them by setting storeMode to replicated in the sessionStore config, if desired.

v7.3 notes

v7.3 is backward compatible with earlier versions, but includes fixes that may affect your existing deployments.

Changed GIF handling

The image service has been partly broken when processing GIF files. As of 7.3, GIFs are always returned as original files (unprocessed, similar to how SVGs are handled). This means GIFs will no longer be cropped, and always work as expected if they contain animations/videos. Animated GIFs are the most common usage of GIF files today.

Ignite removed

Ignite (grid memory component) has been part of the XP core for testing purposes, disabled by default. It has now been removed from the XP core. Unless you have enabled Ignite for testing purposes, this will not affect your deployment. Also, all Ignite configuration files and options can now safely be removed.

Content projects

XP 7.3 introduces the ability to create isolated content repositories. If you have many sites in your current deployment, consider moving your sites into separate projects.

New docker image

A new, improved and properly documented version of our XP7 Docker image is now available. The documentation also describes how to upgrade from the old image.

v7.2 notes

v7.2 is fully backward compatible with v7.1 and v7.0.

This version includes new "Audit logger" feature that requires a new repository. The repository will be created automatically during the upgrade process.

v7.1 notes

v7.1 is fully backward compatible with v7.0.

Upgrading to v7.0


This guide focuses on completing an upgrade with zero downtime, and requires you to set up production environment on XP7 in parallel with existing 6.15 environment. Carefully follow the below steps to upgrade your instance:

For scenarios where downtime cannot be avoided, additional steps, such as setting up a temporary "we are upgrading page", will be required:

Before starting the upgrade process, ensure the following requirements are in place

XP Version

You need to be running at least Enonic XP 6.15.x (if you are running an older version, upgrade to 6.15.x first)

QA environment

Ensure you have a QA environment where you can perform a test upgrade first (highly recommended)


Ensure you have 6.15 Toolbox available

Enonic CLI

Make sure you have Enonic CLI installed

Disk space

Verify you have enough disk space to facilitate a complete dump of all existing data

3rd party apps

Verify that all (if any) 3rd party applications in use are upgraded to support XP 7.

Custom apps

Make sure all custom built applications have been upgraded to support XP 7, as described in Upgrading Applications

1. Install XP 7

We recommend setting up a new production environment for XP 7, running in parallel with your XP 6 environment. This will virtually eliminate downtime, and also be a safety net, should the upgrade fail somehow.

Follow the XP installation instructions to set up an instance matching your requirements

File deployments

If you have one or more applications deployed as files, replace them with their respective XP 7 versions

Vhost config

Vhost configuration has changed:

  • /app has been renamed to /webapp

  • /portal has been renamed to /site

  • Repository name is added before the branch in site URL, ie /site/default/draft

  • userStore has been renamed to idProvider

  • idProvider config format is new

Update your vhost config file as follows:

mapping.intranet.host = example.com
mapping.intranet.source = /
mapping.intranet.target = /portal/master/mysite
mapping.intranet.userStore = myProvider

mapping.myapp.host = myapp.example.com
mapping.myapp.source = /
mapping.myapp.target = /app/com.example.myapp
mapping.myapp.userStore = system
mapping.intranet.host = example.com
mapping.intranet.source = /
mapping.intranet.target = /site/default/master/mysite
mapping.intranet.idProvider.myProvider = default

mapping.myapp.host = myapp.example.com
mapping.myapp.source = /
mapping.myapp.target = /webapp/com.example.myapp
mapping.admin.idProvider.system = default

Port mappings

In XP 7 /status and /api have been moved to separate dedicated ports: 2609 and 4848 respectively.

Consider how this affects your monitoring and how to expose management API internally.

In com.enonic.xp.web.jetty.cfg http.port is replaced with http.xp.port, http.management.port and http.monitor.port.

Elastic Search discovery

If specifying discovery.unicast.sockets in ES configuration: "ip[port]" is now "ip:port"

discovery.unicast.sockets =[9300]

discovery.unicast.sockets =

Other configuration

Migrate other configuration files from 6.15, including custom configurations (app config etc.).

Start servers

Start your new servers and verify everything is working properly

2. Dump data

We are now ready to dump data from our existing 6.15 instance. Do with the 6.15 toolbox:

toolbox.sh dump -t mydump -a user:password --skip-versions

We highly recommend dumping data without versions. This will dramatically speed up the upgrade while also preparing your dataset for the new vacuuming features in XP 7.

3. Upgrade and Load

Move dump

Transfer dump files from previous step to the new instance. For clustered environments, any server will do.


Toolbox has been removed from XP 7 and replaced by Enonic CLI.

Upgrade dump

Before we can load the dump, we need to upgrade the data to support XP 7:

enonic dump upgrade
Load dump

Now, load the dump into your XP 7 environment i.e.

enonic dump load
Don’t worry about the command losing connection, this is only related to the system repo (and user) being removed during the operation. Watch the log for progress.

4. Install Content studio

Content Studio is no longer part of the XP core distribution. Content Studio is now available as an application on Enonic Market. Documentation for Content Studio can be found here.

5. Update apps

All installed applications must be updated to latest versions compatible with XP 7.

Market apps

For market apps, go to the Applications tool, click "Install" in the menu and click "Upgrade" button for all applications where upgrade is available.

Custom apps

Install XP 7 compatible versions of your custom applications either through the "Install App" UI or by using CLI.

6. Validate

Validate that your new installation is working as expected. We recommend checking logs, and performing live tests on services.

7. Go live

With all lights green, simply redirect all traffic from your old XP 6 servers to the upgraded XP 7 environment.

Welcome to the XP 7 club!