Estimated reading time: 8 minutes

Lightstreamer is a real-time messaging server optimized for the Internet.

GitHub repo:

Library reference

This content is imported from the official Docker Library docs, and is provided by the original uploader. You can view the Docker Hub page for this image at

Supported tags and respective Dockerfile links

Quick reference

What is Lightstreamer Server?

Lightstreamer is a real-time messaging server optimized for the Internet. Blending WebSockets, HTTP, and push notifications, it streams data to/from mobile, tablet, browser-based, desktop, and IoT applications.

For more information and related downloads for Lightstreamer Server and other Lightstreamer products, please visit


How to use this image

Up and Running

Launch the container with the default configuration:

$ docker run --name ls-server -d -p 80:8080 lightstreamer

This will map port 8080 inside the container to port 80 on local host. Then point your browser to http://localhost and watch the Welcome page showing real-time data flowing in from the locally deployed demo application, which is a first overview of the unique features offered by the Lightstreamer technology. More examples are available online at the demo site.

Custom settings

It is possible to customize each aspect of the Lightstreamer instance running into the container. For example, a specific configuration file may be supplied as follows:

$ docker run --name ls-server -v /path/to/my-lightstreamer_conf.xml:/lightstreamer/conf/lightstreamer_conf.xml -d -p 80:8080 lightstreamer

In the same way, you could provide a custom logging configuration, maybe in this case also specifying a dedicated volume to ensure both the persistence of log files and better performance of the container:

$ docker run --name ls-server -v /path/to/my-lightstreamer_log_conf.xml:/lightstreamer/conf/lightstreamer_log_conf.xml -v /path/to/logs:/lightstreamer/logs -d -p 80:8080 lightstreamer

If you also change in your my-lightstreamer_log_conf.xml file the default logging path from ../logs to /path/to/dest/logs:

$ docker run --name ls-server -v /path/to/my-lightstreamer_log_conf.xml:/lightstreamer/conf/lightstreamer_log_conf.xml -v /path/to/hosted/logs:/path/to/dest/logs -d -p 80:8080 lightstreamer

Alternatively, the above tasks can be executed by deriving a new image through a Dockerfile as the following:

FROM lightstreamer

# Please specify a COPY command only for the the required custom configuration file
COPY my-lightstreamer_conf.xml /lightstreamer/conf/lightstreamer_conf.xml
COPY my-lightstreamer_log_conf.xml /lightstreamer/conf/lightstreamer_log_conf.xml

where my-lightstreamer_conf.xml and my-lightstreamer_log_conf.xml are your custom configuration files, placed in the same directory as the Dockerfile. By simply running the command:

$ docker build -t my-lightstreamer .

the new image will be built along with the provided files. After that, launch the container:

$ docker run --name ls-server -d -p 80:8080 my-lightstreamer

To get more detailed information on how to configure the Lightstreamer server, please see the inline documentation in the lightstreamer_conf.xml and lightstreamer_log_conf.xml files you can find under the conf folder of the installation directory.

Deployment of Adapter Sets

You might want to use this image even with any Adapter Set, either developed by yourself or provided by third parties.

To accomplish such goal, you may use similar strategies to those illustrated above:

Deployment of a single Adapter Set

To deploy a single custom Adapter Set, the simplest way is to attach its files into the factory adapters folder, as follows:

$ docker run --name ls-server -v /path/to/my-adapter-set:/lightstreamer/adapters/my-adapter-set -d -p 80:8080 lightstreamer

Full replacement of the “adapters” folder

In the case you have many custom Adapter Sets to deploy, a more appropriate strategy is to replace the factory adapters folder with the one located in your host machine:

$ docker run --name ls-server -v /path/to/my-adapters:/lightstreamer/adapters -d -p 80:8080 lightstreamer

In this case, the /path/to/my-adapters folder has to be structured with the required layout for an adapters folder:


Building a new image

Once again, a linear and clean approach is to make a new image including all needed files.

In this case, you could write a simple Docker file in which the list of all your Adapter Sets configuration files is provided:

FROM lightstreamer

# Will copy the contents of N Adapter Sets into the factory adapters folder
COPY my-adapter-set-1 /lightstreamer/adapters/my-adapter-set-1
COPY my-adapter-set-2 /lightstreamer/adapters/my-adapter-set-2
COPY my-adapter-set-3 /lightstreamer/adapters/my-adapter-set-3

Then, just build and start the container as already explained.

Deployment of web server pages

There might be some circumstances where you would like to provide custom pages for the internal web server of the Lightstreamer Server. Even in this case, it is possible to customize the container by employing the same techniques as above.

For example, with the following command you will be able to fully replace the factory pages folder:

$ docker run --name ls-server -v /path/to/custom/pages:/lightstreamer/pages -d -p 80:8080 lightstreamer

where /path/to/custom/pages is the path in your host machine containing the replacing web content files.

Image Variants

The lightstreamer images come in many flavors, each designed for a specific use case.


This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of.


This image is based on the popular Alpine Linux project, available in the alpine official image. Alpine Linux is much smaller than most distribution base images (~5MB), and thus leads to much slimmer images in general.

This variant is highly recommended when final image size being as small as possible is desired. The main caveat to note is that it does use musl libc instead of glibc and friends, so certain software might run into issues depending on the depth of their libc requirements. However, most software doesn’t have an issue with this, so this variant is usually a very safe choice. See this Hacker News comment thread for more discussion of the issues that might arise and some pro/con comparisons of using Alpine-based images.

To minimize image size, it’s uncommon for additional related tools (such as git or bash) to be included in Alpine-based images. Using this image as a base, add the things you need in your own Dockerfile (see the alpine image description for examples of how to install packages if you are unfamiliar).


View license information for the software contained in this image.

As with all Docker images, these likely also contain other software which may be under other licenses (such as Bash, etc from the base distribution, along with any direct or indirect dependencies of the primary software being contained).

Some additional license information which was able to be auto-detected might be found in the repo-info repository’s lightstreamer/ directory.

As for any pre-built image usage, it is the image user’s responsibility to ensure that any use of this image complies with any relevant licenses for all software contained within.

library, sample, lightstreamer