Documentation Center

Upgrade paths for the SDL Web 8 Content Deployer Role

A reorganization of the Content Deployer feature means that you need to make some decisions about how to upgrade your existing Content Deployer setup.

The Content Deployer has, as of SDL Web 8.5, been reworked in three different roles:
Role nameRole folderDescriptionRuns as standalone microservice?Runs as Java/JSP Web application-based microservice?
Content Deployer endpointroles\deployer\deployerThe endpoint that receives published incoming contentyesyes
Content Deployer workerroles\deployer\deployer-workerThe processing engine that handles incoming content and stores ityesno
Content Deployer combinedroles\deployer\deployer-combinedThe previous two Roles combined in one.yesyes
As a result, you can upgrade Content Deployer to one of the following setups:
A Content Deployer endpoint and a Content Deployer worker, each running in a standalone microservice

If you currently run your Content Deployer as a standalone microservice, this scenario separates the endpoint and processing parts of your Content Deployer, and the setup is fully scalable. Alternatively, if you currently run your Content Deployer as a deprecated Java/JSP Web application-based microservice, this is the recommended way of migrating to a non-deprecated, scalable and separable setup.

A single-role Content Deployer running in a standalone microservice

If you currently run your Content Deployer as a standalone microservice, this is the least-effort upgrade of your Content Deployer. But also if you currently run your Content Deployer as a deprecated Java/JSP Web application-based microservice, migrating to a standalone version is strongly recommended. The drawback of using a combined Content Deployer is that you cannot scale out, or separate the parts of, your Content Deployer.

A single-role Content Deployer running in a deprecated Java/JSP Web application-based microservice

If you currently run your Content Deployer as a deprecated Java/JSP Web application-based microservice, this is the least-effort upgrade of your Content Deployer, and it is strongly discouraged. The drawbacks are that this upgrade is not provided with the product deliverable; that your Role runs as a deprecated Web application; and that you cannot scale out, or separate the parts of, your Content Deployer.

A Content Deployer endpoint running in a deprecated Java/JSP Web application-based microservice, and a Content Deployer worker running in a standalone microservice

If you currently run your Content Deployer as a deprecated Java/JSP Web application-based microservice, this scenario is closer to a migration than to an upgrade. You enable the processing part of your Content Deployer (the worker) to be installed on a different machine, but your endpoint still runs in a Web application, which is a deprecated setup, and is strongly discouraged. The drawbacks are that this upgrade is not provided with the product deliverable, and that part of your Role still runs as a deprecated Web application.