WURFL Microservice for Docker

Using WURFL Microservice for Docker will allow you to run your own WURFL-based device detection service in your hosting infrastructure by deploying familiar Docker images as containers through a ScientiaMobile Docker repository. If you are not familiar with Docker and the possibilities of Docker containers, here is a good place to get started.

WURFL Microservice Architecture

WURFL Microservice is a service which exposes its functions through a REST interface. Communication with the service happens through local APIs (AKA Client APIs) that speak HTTP to the HTTP Server.

Note: The REST interface is used for communication between the Client API and the HTTP Server and is totally transparent to users of WURFL Microservice. Users with a very specific use case(s) may contact ScientiaMobile about enabling the ability to utilize the REST Interface directly (this approach is normally discouraged). Among other things, local APIs will provide a caching layer which delivers greater performance in actual usage.

The following diagram explains the overall architecture of WURFL Microservice as deployed through the ScientiaMobile Docker Private Registry. The Image will start an instance of the HTTP Server as a container. In addition to supporting the REST interface for API clients, the service will periodically query ScientiaMobile for updates to the WURFL Device Description Repository in order to include the profiles of newly released devices.

Deploying the Docker Container and Setting up the Local APIs

1. (***Only for first-time WURFL Microservice users***) Obtain a license for the Product from ScientiaMobile. This will let you use your ScientiaMobile credentials to login into the ScientiaMobile private registry and enable deployment of the product.

2. Login to the ScientiaMobile Docker Registry.

docker login docker.scientiamobile.com -u <username>

Details on the Docker login command can be found here.

Docker Images are currently available based on the set of Capabilities (Device Properties) and API Programming Language licensed from ScientiaMobile.

3. Use Docker to download, deploy, and start the WURFL Microservice HTTP server in an environment which makes sense for you (i.e. development, test, production, etc).

docker run --name wm-server --rm -p 8080:80 \
  -v /tmp/wm-server-logs:/var/log/wm-server \
  -e WM_CACHE_SIZE="200000" \
  -e WM_MAX_CORES=7 \
  -e WM_ERROR_LOG_TO_FILE=true docker.scientiamobile.com/<license_id>/wurfl-microservice.server
  • WM_ACCESS_LOG_TO_FILE=true will log HTTP access /var/log/wm-server/access.log
  • WM_ERROR_LOG_TO_FILE=true will log errors in /var/log/wm-server/error.log
  • Use WM_MAX_CORES to limit the number of threads used by the server (with no option server will use all necessary threads to keep serving requests).
  • To reduce server load it is suggested to use a big server side cache: WM_CACHE_SIZE=”200000” will do for a medium server, “300000” for a large one.

Important Note for Users of the Old DOUBLE LRU Cache Provider (pre for backwards compatibility, older configurations are still supported and will not generate errors or warnings, but internally the new SINGLE LRU Cache is adopted for better performance.

4. Verify that the HTTP Server is running:

The following command (assuming 'curl' is installed) will return information about the WM installation. You should replace 'localhost' and port number with the corresponding information in your deployment:

curl http://localhost:8080/v2/status/json

Sample output:

    "lookup_request": 0,
    "lookup_useragent": 2,
    "lookup_device_id": 0,
    "make_model_requests": 0,
    "server_info_requests": 3,
    "not_found_404": 0,
    "server_uptime": 23171

5. (Only for first-time WURFL Microservice users) Run the Instance and point your web browser to the Instance IP address:


The key component of WURFL Microservice is a daemon that exposes a REST API to other modules in your microservice architecture. APIs are provided to offer a traditional programming interface in multiple languages and hide the complexity of the REST end-points under the hood. WURFL Microservice conveniently utilizes the availability of an HTTP server to distribute the required Client Libraries (i.e. the local APIs) to integrate Device Detection within your application in Java, PHP, .NET, etc.

If multiple languages for the API are acquired, you will see the list of packages at the /download endpoint:

Note: The URL to the actual packages are available in the following format:


You may use curl, wget, or similar methods, to download directly to the desired directory (you may want to add the library to your own Git repository for future use without the need to replicate this step).

This step will confirm that the AMI is up and running.

6. (Only for first-time WURFL Microservice users) Install the Client API package and import the API in your project to start using it in your application.

You can find the documentation for each API here:

7. (Optional) Open a shell terminal and confirm that the WURFL Microservice is running as expected:

  $ curl
    "lookup_request": 0,
    "lookup_useragent": 0,
    "lookup_device_id": 0,
    "make_model_requests": 0,
    "server_info_requests": 8,
    "v1_capabilities_requests": 0,
    "not_found_404": 0,
    "server_uptime": 1172

© 2019 ScientiaMobile Inc.
All Rights Reserved.

NOTICE: All information contained herein is, and remains the property of ScientiaMobile Incorporated and its suppliers, if any. The intellectual and technical concepts contained herein are proprietary to ScientiaMobile Incorporated and its suppliers and may be covered by U.S. and Foreign Patents, patents in process, and are protected by trade secret or copyright law. Dissemination of this information or reproduction of this material is strictly forbidden unless prior written permission is obtained from ScientiaMobile Incorporated.