Appearance

Running with Docker ​

If Docker is available on your system, the easiest way to run openrouteservice is starting a prebuilt image. You don't need to clone the openrouteservice repository, the source code is not needed to run a prebuilt image. Also, java and maven don't have to be installed.

If you have special requirements, you can also build your customized docker image.

WARNING

The docker documentation is only valid for openrouteservice since v8.0.0!

Prerequisites ​

  • Docker has to be installed on your system.
  • An OSM extract, e.g. from Geofabrik or for small areas directly export from osm.org.

No java or maven required unless you want to build a customized docker image 😃

Running prebuilt images ​

The openrouteservice team provides a docker compose file that pulls and starts the prebuilt openrouteservice docker image for a specific version in one simple command. Starting with openrouteservice v8.0.0, you can (and should) download the compose file from the "assets" section on the releases page, in the browser or e.g. with

shell
wget https://github.com/GIScience/openrouteservice/releases/download/v8.0.0/docker-compose.yml

Now start openrouteservice in the background:

shell
docker compose up -d

This will pull the openrouteservice of the selected version and start it up using an example setup and the provided test OSM file for Heidelberg/Germany and surrounding area.

To see the container's logs, run

shell
docker compose logs

or

shell
docker compose logs -tf

to follow the log.

To stop the container again, execute

shell
docker compose stop

or

shell
docker compose down

to stop and remove the container.

The file docker-compose.yml contains plenty of commented options with descriptions. You can un-comment those options and set your custom option values.

Running without docker compose

It is easier to modify the Docker compose file, but to test a specific setup, you can also run a command similar to what docker compose would run directly on the command line. Here is a basic example:

shell
# create directories for volumes to mount as local user
mkdir -p ors-docker/config ors-docker/elevation_cache ors-docker/graphs ors-docker/files ors-docker/logs 
docker run -dt --name ors-app \
  -p 8080:8082 \
  -v $PWD/ors-docker/config:/home/ors/config \
  -v $PWD/ors-docker/elevation_cache:/home/ors/elevation_cache \
  -v $PWD/ors-docker/graphs:/home/ors/graphs \
  -v $PWD/ors-docker/files:/home/ors/files \
  -v $PWD/ors-docker/logs:/home/ors/logs \
  -e "XMS=1g" \
  -e "XMX=2g" \
  local/openrouteservice:latest

Add -e "ors.engine.profile_default.build.source_file=files/your.osm.pbf" \ to point to your own OSM file that lies in the mounted $PWD/ors-docker/files folder. Add -e "BUILD_GRAPHS=True" \ to trigger a graph rebuild.

What you get ​

After some time, your openrouteservice should be running:

shell
curl http://localhost:8080/ors/v2/health
{"status":"ready"}

When you have started the container as described, a directory ors-docker with some sub directories and files are created by docker:

shell
.
├── docker-compose.yml
└── ors-docker
    ├── config
    │   ├── example-ors-config.env      
    │   ├── example-ors-config.yml     
    │   └── ors-config.yml
    ├── elevation_cache
    │   ├── srtm_38_03.gh
    │   └── srtm_38_03.zip
    ├── files
    │   └── example-heidelberg.test.pbf
    ├── graphs
    │   └── driving-car
    │       ├── edges
    │       ├── ...
    │       ├── ...
    │       └── turn_costs
    └── logs
        └── ors.log

8 directories, 35 files
  • example-ors-config.env: env file template. A customized copy of this file can be used in combination with the docker-compose.yml, see Set properties in an environment file. Do not edit this file directly since it will be overridden by docker!
  • example-ors-config.yml: YAML file template. A customized copy of this file can be used as ors-config.yml, see Use customized config file. Do not edit this file directly since it can be overridden by docker: If e.g. a newer docker image tag is used in the docker-compose.yml, the example-ors-config.yml might be updated if in the newer version of openrouteservice there are changes in the configuration properties or their default values. The updated file can be compared with the customized ors-config.yml.
  • ors-config.yml: The default config used by the openrouteservice inside the container. This file will not be overridden by docker. Initially, the file is identical to example-ors-config.yml. See Use customized config file
  • elevation_cache: Directory, where openrouteservice stores downloaded elevation data to avoid repeated downloads.
  • example-heidelberg.test.pbf: The initial sample OSM data used to run the container in its initial setup. Normally, you will remove this file or add another OSM file to the same directory and adapt your config to use your file.
  • graphs: Directory for the generated graphs. Initially, there is only driving-car because this is the only enabled routing profile in the default ors-config.yml
  • logs: Here, the openrouteservice logs are stored. ⚠️ Logs of several runs will be accumulated here. In contrast, the logs you get with docker compose logs are only logs of the current run, but on the other hand they contain very helpful logging from docker or the entrypoint script, which is not visible in the files in logs.

Avoid files owned by root ​

With the default docker-compose.yml, the generated files are owned by root. If you don't have root permissions (sudo) or you just don't want root owned files in your bind-mounts from the container, e.g. cannot edit or add files in ors-docker/config, the container provides the possibility to be run with UID 1000 and GID 1000. To be able to access these files, you need to have either the UID 1000 or be part of the group 1000 on your docker host machine. Of course, you can configure openrouteservice with the help of the docker-compose.yml (see here) or a referenced environment file (see there), which needs not to be located in the config folder because the openrouteservice running inside docker don't need to 'see' the environment file.

But if you for example want to save a new pbf file to ors-docker/files, then you need sudo rights.

To avoid root ownership of the generated folders and files,

  1. uncomment the 'user' line in your docker-compose.yml:
    yaml
        #user: "1000:1000"
    user: "1000:1000"
  2. create the folders with your user, so your user should be owner of the folders:
    shell
    mkdir -p ors-docker/config ors-docker/elevation_cache ors-docker/files ors-docker/graphs ors-docker/logs
    If the folders already exist (owned by root) and you don't want to delete them, you can change their ownership (again root permissions required).
  3. When you now run docker compose down && docker compose up -d, the files and folders should be editable for your user.

As you can see in the docker-compose.yml snippet above, this works for the user with user-id 1000 and group-id 1000, which is the default for the first normal user on a linux host. But if you have different user- and group-id, the formula does not work for you.

You can check your own user-id (uid) and group-id (gid) with the command

shell
id

If you have different uid/gid, then what you still can do is building your own docker image after specifying your uid and gid in your docker compose file. Let's say, you have uid=1003 and gid=1003:

  1. Edit your docker-compose.yml:
    yaml
        #user: "1000:1000"
    user: "1003:1003"
  2. Build your docker image locally as described in build your customized docker image
  3. Now you should be able to do steps 2. and 3. as described above.

Directories inside the Container and on the Host ​

The docker container is a kind of minimalistic linux system with a specific openrouteservice setup. Internally, the correct java version is installed which is used to run the openrouteservice fat jar.

The internal working directory, where openrouteservice is started, is /home/ors. The internal openrouteservice is configured to use the sub folders of this working directory as locations where specific input files are expected or where generated data are written to:

  • /home/ors/config
  • /home/ors/graphs
  • /home/ors/files
  • /home/ors/logs
  • /home/ors/elevation_cache

Absolute paths in the yml like

yaml
     source_file: /home/ors/files/example-heidelberg.test.pbf

are interpreted as absolute inside the container.

Relative paths like

yaml
       cache_path: ./elevation_cache

are intepreted as relative to the work directory /home/ors inside the container.

Use different directories as your bind mounts ​

If you want to mount existing folders of your host file system, that are not sub folders of your openrouteservice docker working directory ors-docker, you can change the volumes section in your docker-compose.yml.

In the following example, a user has a directory /data/osm with OSM files. The user wants to reference the files from there directly instead of copying the large files somewhere else. And the graph files generated by openrouteservice should also be stored into a different location, where more disk space is available than in the home directory, let's say in /data/ors/graphs.

The directories required by the internal openrouteservice are mounted individually, the paths on the host system are defined before the colon, the (unchanged) directory inside the container behind the colon.

yaml
    volumes:  # Mount relative directories. ONLY for local container runtime. To switch to docker managed volumes see 'Docker Volumes configuration' section below.
      - ./ors-docker:/home/ors
      - /data/ors/graphs:/home/ors/graphs
      - ./ors-docker/elevation_cache:/home/ors/elevation_cache
      - ./ors-docker/config:/home/ors/config
      - ./ors-docker/logs:/home/ors/logs
      - /data/osm:/home/ors/files

With these changes, a source_file configured in ors-config.yml:

yaml
     source_file: ./files/andorra-latest.osm.pbf

now references the file /data/osm/andorra-latest.osm.pbf on the host file system.

Note

When individual host directories are mounted to the internal sub directories of /home/ors, no directory can be mounted directly to the internal /home/ors!

Use Volumes ​

Instead of using bind mounts, you can use volumes. Uncomment and complete the volume definition in the docker-compose.yml (see docker compose documentation):

yaml
# ----------------- Docker Volumes configuration ------------------- #
# Define the Docker managed volumes for the ORS application. For more info on Docker Volumes see https://docs.docker.com/compose/compose-file/07-volumes/
# Volumes are used to persist the data and configuration of the ORS application.
# If you want to use volumes, uncomment the following lines and remove the ./ prefix from the volume paths in 'services.ors-app.volumes'.
#volumes:
#    graphs:
#    elevation_cache:
#    config:
#    logs:
#    files:
volumes: 
    graphs: 
    elevation_cache: 
    config: 
    logs: 
    files:

In the yml section services.ors-app.volumes of your docker-compose.yml you set the volume names instead of host paths on the left side of the colon:

yaml
services:
  ors-app:
    volumes:
      - ./ors-docker:/home/ors  # Mount the ORS application directory (for logs, graphs, elevation_cache, etc.) into its own directory
      #- ./graphs:/home/ors/graphs  # Mount graphs directory individually
      #- ./elevation_cache:/home/ors/elevation_cache  # Mount elevation cache directory individually
      #- ./config:/home/ors/config  # Mount configuration directory individually
      #- ./logs:/home/ors/logs  # Mount logs directory individually
      #- ./files:/home/ors/files  # Mount files directory individually
      #- ./ors-docker:/home/ors  # Mount the ORS application directory (for logs, graphs, elevation_cache, etc.) into its own directory
      - graphs:/home/ors/graphs  # Mount graphs directory individually
      - elevation_cache:/home/ors/elevation_cache  # Mount elevation cache directory individually
      - config:/home/ors/config  # Mount configuration directory individually
      - logs:/home/ors/logs  # Mount logs directory individually
      - files:/home/ors/files  # Mount files directory individually

Configure ​

When using the openrouteservice docker image, you have several configuration options:

  • You can use a configuration file as you would do when running openrouteservice as JAR or WAR. If you are the owner of the files in ors-docker/config, this is straight forward (see above).
  • You can set configuration properties as environment variables in the docker-compose.yml
  • or you can set configuration properties in an environment file. This is good practice for docker containers in general and the preferred way to configure dockered openrouteservice when the files are owned by root.

The following sections explain these options in more detail. For detailed information on the configuration settings you can make, see the chapter on configuration.

TIP

If you want to re-build the graphs, many people just delete the graphs folders and restart openrouteservice. If you are not owner of the graphs files (but root), you cannot delete those files without root permissions. In this case, you can set the environment variable REBUILD_GRAPHS=True in your docker-compose.yml (the option is contained in the file, just un-comment it) or in your ors-config.env. openrouteservice will then re-build all activated graphs on the next startup.

Use (customized) config file ​

As described in Configuration > File location, when openrouteservice is started, it looks for a file named ors-config.yml in different directories and uses the file, if it exists. Alternatively, an individually named or located configuration file (YAML or the deprecated JSON config) can be used by setting the environment variable ORS_CONFIG_LOCATION.

In the Docker version, there is an initialization script that is executed on each container start, which is using a slightly different approach:

  • It checks if ORS_CONFIG_LOCATION is set and if the referenced file (YAML or the deprecated JSON config) can be found (the path is evaluated from inside the container). If this is the case, this config will be used.
  • Otherwise, the file /home/ors/config/ors-config.yml or /home/ors/config/ors-config.json is searched (path inside container). If it is there, it will be loaded.
    If not, it will be added as copy of /home/ors/config/example-ors-config.yml and also be loaded!

This means, that in any case, a config file is loaded! Even if you set environment variables as described in the next two sections, you have to take care of the config file that is loaded, and in some cases you have to override single properties, e.g. disable the routing profile driving-car - which is enabled in the default ors-config.yml - if you don't want it to be enabled.

You can configure your openrouteservice by editing the generated ors-config.yml. This file will never been overridden by openrouteservice, if it still exists. But you should never edit example-ors-config.yml example-ors-config.env - these files will be replaced in some cases.

Set openrouteservice properties in docker-compose.yml ​

It is possible to pass openrouteservice configuration properties into a docker container as environment variables. The docker-compose.yml contains many available configuration options as comments, with a short description. The following example snippet of the modified docker-compose.yml shows a setup where the driving-car profile is disabled and wheelchair is enabled:

yaml
    environment:
      # ----------------- Properties configuration ------------------- #
      # Configure your whole container with only property ENVs.
      # These can be set alternatively or additionally to the yml configuration file.
      # Note, that any values set will override the corresponding values from the yml configuration file.
      # See the ors-config.env file for more options.
      # To have a configuration file-less container, uncomment at least the following properties.
      # The values are examples and provide the default configuration.
      ors.engine.profile_default.build.source_file: /home/ors/files/andorra-latest.osm.pbf
      ors.engine.profiles.driving-car.enabled: false
      ors.engine.profiles.wheelchair.enabled: true
      # Here you can also set more advanced spring and tomcat properties, such as proxy settings.
      # See the spring documentation for a complete list of options: https://docs.spring.io/spring-boot/docs/current/reference/html/application-properties.html
      #server.tomcat.remote-ip-header=x-your-remote-ip-header
      #server.tomcat.protocol-header=x-your-protocol-header

Hint

Remember that the container has to be newly created for the changes in docker-compose.yml to take effect! docker compose stop && docker compose start or docker compose restart is not enough, you have to execute

shell
docker compose down && docker compose up

The syntax/name of the configuration properties is not yaml but instead the syntax from java properties files. But it is just a different syntax. The properties are the same as described in Configuration > File Formats.

Set openrouteservice properties in an Environment file ​

Configuring properties in docker-compose.yml is a good way to set a handful of properties. If you want to customize a great number of properties or if you maybe have different configurations in use, it is more convenient to save the properties to a separate file.

The properties that were set in in the docker-compose.yml snippet in the previous section could instead be set in a separete file ors-config.env. The only difference is, that equal signs are used instead of colons:

ors.engine.profile_default.build.source_file=/home/ors/files/andorra-latest.osm.pbf
ors.engine.profiles.driving-car.enabled=false
ors.engine.profiles.wheelchair.enabled=true

The env file has to be referenced in the docker-compose.yml:

yaml
    # ----------------- ENV file configuration ------------------- #
    # Too many variables for your 'environment:' section?
    # Use an env_file with the ENV properties instead and define everything in there:
    # Values will be overwritten if set in the 'environment' section.
#    env_file: ors-config.env
    env_file: ors-config.env

If you want to use this configuration option and you start creating your environment file, you can use the file ors-docker/config/example-ors-config.env as a template. Copy it next to your docker-compose.yml or rename it. You should never edit the file ors-docker/config/example-ors-config.env because it will be replaced by openrouteservice in some cases!

Troubleshooting ​

If openrouteservice cannot be started or does not operate as expected, it is most important to check the logs. There are two ways to inspect the logs, with some differences: docker compose logs and ors-docker/logs/ors.log

docker compose logsors-docker/logs/ors.log
logs from docker entrypoint and openrouteservicelogs from openrouteservice only
logs from the current container onlylogs from previous containers that were removed with e.g. docker compose down still available

This section will focus on the logs from docker because they contain additional information. To see the container's entrypoint logs, change into your directory with the docker-compose.yml and run

shell
docker compose logs

The first logged lines are written by the entrypoint script inside the container which is executed on each container start before the internal openrouteservice is started. Here you can gain an insight into the internal workings of the container:

shell
ors-app  | 2024-03-12T08:13:19.118290567Z #################
ors-app  | 2024-03-12T08:13:19.118317827Z # Container ENV #
ors-app  | 2024-03-12T08:13:19.118320018Z #################
ors-app  | 2024-03-12T08:13:19.118321664Z ✓ CONTAINER_LOG_LEVEL: INFO. Set CONTAINER_LOG_LEVEL=DEBUG for more details.
ors-app  | 2024-03-12T08:13:19.125163248Z ⓘ Any config file settings can be overwritten by environment variables.
ors-app  | 2024-03-12T08:13:19.125181048Z ⓘ Use 'CONTAINER_LOG_LEVEL=DEBUG' to see the full list of active environment variables for this container.
ors-app  | 2024-03-12T08:13:19.125193428Z ###########################
ors-app  | 2024-03-12T08:13:19.125195433Z # Container sanity checks #
ors-app  | 2024-03-12T08:13:19.125208729Z ###########################
ors-app  | 2024-03-12T08:13:19.127963029Z ⓘ Running container as user root with id 0 and group 0
ors-app  | 2024-03-12T08:13:19.130316750Z ✓ ORS_HOME: /home/ors exists and is writable.
ors-app  | 2024-03-12T08:13:19.134116420Z ✓ The file /home/ors/config/example-ors-config.env is up to date
ors-app  | 2024-03-12T08:13:19.135634341Z ✓ The file /home/ors/config/example-ors-config.yml is up to date
ors-app  | 2024-03-12T08:13:19.135753416Z ✓ Using existing /home/ors/config/ors-config.yml
ors-app  | 2024-03-12T08:13:19.142101283Z ⓘ Default to graphs folder: /home/ors/graphs
ors-app  | 2024-03-12T08:13:19.142118351Z ⓘ Default to example osm source file: "/home/ors/files/example-heidelberg.test.pbf"
ors-app  | 2024-03-12T08:13:19.142119978Z ⓘ Any ENV variables will have precedence over configuration variables from config files.
ors-app  | 2024-03-12T08:13:19.142151919Z ✓ All checks passed. For details set CONTAINER_LOG_LEVEL=DEBUG.
ors-app  | 2024-03-12T08:13:19.142159578Z #####################################
ors-app  | 2024-03-12T08:13:19.142160979Z # Container file system preparation #
ors-app  | 2024-03-12T08:13:19.142162089Z #####################################
ors-app  | 2024-03-12T08:13:19.199741022Z ✓ The file /home/ors/files/example-heidelberg.test.pbf is up to date
ors-app  | 2024-03-12T08:13:19.199762468Z ✓ Container file system preparation complete. For details set CONTAINER_LOG_LEVEL=DEBUG.
ors-app  | 2024-03-12T08:13:19.199764187Z #######################################
ors-app  | 2024-03-12T08:13:19.199765671Z # Prepare CATALINA_OPTS and JAVA_OPTS #
ors-app  | 2024-03-12T08:13:19.199766895Z #######################################
ors-app  | 2024-03-12T08:13:19.200084573Z ✓ CATALINA_OPTS and JAVA_OPTS ready. For details set CONTAINER_LOG_LEVEL=DEBUG.
ors-app  | 2024-03-12T08:13:19.200120626Z #####################
ors-app  | 2024-03-12T08:13:19.200127702Z # ORS startup phase #
ors-app  | 2024-03-12T08:13:19.200129261Z #####################
ors-app  | 2024-03-12T08:13:19.200130392Z ✓ 🙭 Ready to start the ORS application 🙭

As explained in the log, by setting CONTAINER_LOG_LEVEL=DEBUG in the docker-compose.yml you get more information. This setting is only relevant for the entrypoint logging, it does not change the log level of openrouteservice. How you can achieve this is documented in the logging documentation.

Hint

Remember that the container has to be newly created for the changes in docker-compose.yml to take effect! docker compose stop && docker compose start or docker compose restart is not enough, you have to execute

shell
docker compose down && docker compose up
Follow logs

If you want to watch the logs while openrouteservice is running, you can also

shell
docker compose logs -tf

to follow the log. Press Ctrl+C to stop tailing the log, the container will not be stopped.

Important information, that you will find in the entrypoint section of the docker log:

  • The user that is used inside the container, with uid and gid
  • All environment variables inside the container (only with CONTAINER_LOG_LEVEL=DEBUG)
  • Information about resolved paths inside the container
  • Information about generation or replacement of example files
  • Errors concerning the setup

After the entrypoint section, there are the logs from openrouteservice itself. The openrouteservice startup log looks similar to this:

shell
ors-app  | ▢ Startup command: java -Djava.awt.headless=true -server -XX:TargetSurvivorRatio=75 -XX:SurvivorRatio=64 -XX:MaxTenuringThreshold=3 -XX:+UseG1GC -XX:+ScavengeBeforeFullGC -XX:ParallelGCThreads=4 -Xms1g -Xmx2g  -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9001 -Dcom.sun.management.jmxremote.rmi.port=9001 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=localhost  -jar /ors.jar
ors-app  | 
ors-app  |   .   ____          _            __ _ _
ors-app  |  /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
ors-app  | ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
ors-app  |  \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
ors-app  |   '  |____| .__|_| |_|_| |_\__, | / / / /
ors-app  |  =========|_|==============|___/=/_/_/_/
ors-app  |  :: Spring Boot ::                (v3.1.6)
ors-app  | 
ors-app  | 2024-03-12 10:54:45 INFO                                                  main [ o.h.o.a.Application                      ]   Starting Application v8.0-SNAPSHOT using Java 21.0.2 with PID 1 (/ors.jar started by root in /home/ors)
ors-app  | 2024-03-12 10:54:45 INFO                                                  main [ o.h.o.a.Application                      ]   The following 1 profile is active: "default"
ors-app  | 2024-03-12 10:54:45 INFO                                                  main [ o.h.o.a.ORSEnvironmentPostProcessor      ]   
ors-app  | 2024-03-12 10:54:45 INFO                                                  main [ o.h.o.a.ORSEnvironmentPostProcessor      ]   Configuration lookup started.
ors-app  | 2024-03-12 10:54:45 INFO                                                  main [ o.h.o.a.ORSEnvironmentPostProcessor      ]   Configuration file set by environment variable.
ors-app  | 2024-03-12 10:54:45 INFO                                                  main [ o.h.o.a.ORSEnvironmentPostProcessor      ]   Loaded file '/home/ors/config/ors-config.yml'
ors-app  | 2024-03-12 10:54:45 INFO                                                  main [ o.h.o.a.ORSEnvironmentPostProcessor      ]   Configuration lookup finished.
ors-app  | 2024-03-12 10:54:45 INFO                                                  main [ o.h.o.a.ORSEnvironmentPostProcessor      ]   
ors-app  | 2024-03-12 10:54:46 INFO                                              ORS-Init [ o.h.o.a.s.l.ORSInitContextListener       ]   Initializing ORS...
ors-app  | 2024-03-12 10:54:46 INFO                                              ORS-Init [ o.h.o.r.RoutingProfileManager            ]   Total - 1024 MB, Free - 965.93 MB, Max: 2 GB, Used - 58.07 MB
ors-app  | 2024-03-12 10:54:46 INFO                                              ORS-Init [ o.h.o.r.RoutingProfileManager            ]   ====> Initializing profiles from '/home/ors/files/example-heidelberg.test.pbf' (1 threads) ...
ors-app  | 2024-03-12 10:54:46 INFO                                              ORS-Init [ o.h.o.r.RoutingProfileManager            ]   2 profile configurations submitted as tasks.
ors-app  | 2024-03-12 10:54:46 INFO                                     ORS-pl-wheelchair [ o.h.o.r.RoutingProfile                   ]   [1] Profiles: 'wheelchair', location: './graphs/wheelchair'.
ors-app  | 2024-03-12 10:54:47 INFO                                     ORS-pl-wheelchair [ o.h.o.r.g.e.ORSGraphHopper               ]   version v4.9.1|2024-01-17T09:08:46Z (7,20,5,4,5,7)
ors-app  | 2024-03-12 10:54:47 INFO                                     ORS-pl-wheelchair [ o.h.o.r.g.e.ORSGraphHopper               ]   graph wheelchair|RAM_STORE|3D|turn_cost|,,,,, details:edges:0(0MB), nodes:0(0MB), name:(0MB), geo:0(0MB), bounds:1.7976931348623157E308,-1.7976931348623157E308,1.7976931348623157E308,-1.7976931348623157E308,1.7976931348623157E308,-1.7976931348623157E308
ors-app  | 2024-03-12 10:54:47 INFO                                     ORS-pl-wheelchair [ o.h.o.r.g.e.ORSGraphHopper               ]   No custom areas are used, custom_areas.directory not given
ors-app  | 2024-03-12 10:54:47 INFO                                     ORS-pl-wheelchair [ o.h.o.r.g.e.ORSGraphHopper               ]   start creating graph from /home/ors/files/example-heidelberg.test.pbf
ors-app  | 2024-03-12 10:54:47 INFO                                     ORS-pl-wheelchair [ o.h.o.r.g.e.ORSGraphHopper               ]   using wheelchair|RAM_STORE|3D|turn_cost|,,,,, memory:totalMB:1024, usedMB:260
ors-app  | 2024-03-12 10:54:47 INFO                                                  main [ o.h.o.a.Application                      ]   Started Application in 2.442 seconds (process running for 3.066)
ors-app  | 2024-03-12 10:54:47 INFO                                                  main [ o.h.o.a.Application                      ]   openrouteservice {"build_date":"2024-03-08T15:01:47Z","version":"8.0"}

Most important information here:

  • The version of openrouteservice and java: Starting Application v8.0-SNAPSHOT using Java 21.0.2 (you do not have to worry about the Java version in the Docker setup)
  • The evaluated configuration file: Loaded file '/home/ors/config/ors-config.yml' (this is the path inside the container)
  • Memory usage: Total - 1024 MB, Free - 965.93 MB, Max: 2 GB, Used - 58.07 MB
  • The evaluated OSM file: ====> Initializing profiles from '/home/ors/files/example-heidelberg.test.pbf' (also internal path)
  • Potential errors with your setup

And after the startup section you will find information about errors at run time.

Hint

The output The following 1 profile is active: "default" is from spring, it refers to the active spring profile and has nothing to do with routing profiles.