Operational Considerations of running self hosted openrouteservice in Azure


We are deploying a self hosted ors in Azure web app, and manage to get it working with Azure storage’s fileshare and mapping it to /home/ors and docker compose feature in Azure Web App. (We needed another pbf file). Right now, it manage to detect the location of the new pbf via ORS_CONFIG_LOCATION setting in the docker compose script, and rebuilt the graph files which I can see being populated in the Azure File Share.

Moving forward from an operations perspective, I am thinking of various options for updating graph files
Option 1. Stop the ORS instance during maintenance window, change the pbf file and delete graph data, start it up and force rebuild.
<Question 1.1> : once we delete the graph folder, I assume we don’t need to set rebuild graph to true in our Azure docker compose file, and ORS will just automatically rebuild?

Option 2. Use a second server to build graph files and just load it into Azure file share. I have seen that suggested somewhere I believe.
<Question 2.1> Is the graph folder the only thing that needs to change? We don’t have to worry about elevation_cache I assume?

Option 3. Create a new docker image for each data update, and force all the files into the container rather then making it go out to file share.
<Question 3.1> Can anyone comment on the performance difference, if any, of forcing all the files into the docker container itself, versus making ORS go out to Azure file shares? Before I do down the route of investing how to do this in Azure (Am new to all of this…), just want to make sure the effort might be worth it, especially from a performance perspective.
<Question 3.2> Anyone has a guide of some sort of how I would do that in Azure specifically… or is this pretty docker generic?

General question, anyone running self hosted and have any experience to share on which way they are doing it… or new ways that I haven’t thought of above?


Hi @hpl-eagle

yes, if the graph folder is gone, ors will rebuild the graphs.

Normally yes. The elevation data usually doesn’t change that often :slight_smile: so you can use the existing cache.

depending on the region and profile count you are running, this will make your image size quite large. I would advise against it, if you can manage with option 1 or 2. The deployment workflow might be “easier” but i’m pretty sure it’s not worth it. But then again i have no experience with Azure.

Best regards

Thanks Amandus,

Appreciate your inputs.


1 Like