Host platform tools using Docker for Windows

Component: ServiceControl
This sample is not production ready as ports are remotely accessible and it is targeted to developers.

This sample shows how to host the ServicePulse and ServiceControl platform tools using Docker Windows Containers for Server and Desktops . It makes use of docker-compose to easily setup all platform tool components.


  • Ensure that Docker has been installed either for Windows 10 or Windows Server.
  • Valid license file available at C:\ProgramData\ParticularSoftware\license.xml.
  • Azure Service Bus connection string set in environment variable AZURESERVICEBUS_CONNECTIONSTRING

Windows vs Linux

Currently Linux is unsupported as ServiceControl has a technical dependancy on ESENT storage which is only available on Windows.

A compose file cannot setup both Windows and Linux containers at this writing. ServicePulse supports both Windows and Linux containerization.


As the platform tools are licensed software the sofware needs a license file. The license file in the sample assumes the default path C:\ProgramData\ParticularSoftware\license.xml.


ServiceControl requires storage. Data stored by ServiceControl must be persistent and not stored in the container itself as containers often need to be rebuild. ServiceControl Data is stored via docker volumes which is resilient to container rebuilds so that data is not lost. This sample writes logs to a docker volume too to ensure logs are not lost.


The Azure Service Bus Transport is used but docker works well with all supported broker based transports.

Set the Azure Service Bus connection string in the environment.env file (value Endpoint=sb://;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=xxx).

Init and Runtime containers

ServiceControl has a setup and a run-time stage. During the setup stage queues are created but no messages are ingested and processed while during the run-time stage no setup is performed and messages are ingested. In a production environment often the setup stage is run with administrative access to resouces and the runtime stage is run least priviledge.

The same stages are applied to docker. The docker-compose.init.yml docker compose file executes the ServiceControl init containers.

The init and runtime compose files would be using different connection strings (administrative vs least priviledge) in a non-developer environment.

Running the sample

The init containers need to be run before the runtime containers.


Runs compose and wait until all init containers completed. This should automatically exist after all setup logic completed.

This is ommitting the -d, --detach argument to ensure issues are writting to the console. Alternatively, any issues are visible in the container logs.
docker-compose --file docker-compose.init.yml up


Runs compose and launch ServicePulse via the configured default browser. This uses the default docker compose file docker-compose.yml.

docker-compose up --detach
start http://localhost:9090


Gracefully stops and removes the containers and the configured volumes.


The docker images are following semver. Meaning, breaking changes are only introduced in new majors. Releases are pushed as major.minor.patch and it is safe to follow a major tag to ensure updates.

Following latest is only recommended for developers in combination with recreating docker volumes via docker compose up -d -V.

In order to update all containers to their latest versions:

docker pull particular/servicecontrol.azureservicebus.init-windows:4
docker pull particular/servicecontrol.azureservicebus-windows:4
docker pull particular/servicecontrol.azureservicebus.monitoring.init-windows:4
docker pull particular/servicecontrol.azureservicebus.monitoring-windows:4
docker pull particular/servicecontrol.azureservicebus.audit.init-windows:4
docker pull particular/servicecontrol.azureservicebus.audit-windows:4
docker pull particular/servicepulse-windows:1
docker-compose -f docker-compose.runtime.yml up --detach


Last modified