The OpenStreetMap.org Operations Team has recently made improvements to the tile.openstreetmap.org raster map tile service.
Over the month of July 2025, the tile.openstreetmap.org service handled an enormous amount of traffic - responding to 121 billion tile requests with a weekday daily peak of about 70 000 requests per second and peak bandwith of 6-7 Gbps. The total monthly bandwidth usage was 1.4 Petabytes (that’s 1 400 000 Gigabytes)
Cleanups to blocks
The code in our configuration that handles blocking requests has been rewritten, cleaning up what grew over several years of small changes. Our blocks consist of matching headers against dictionaries, matching parts of headers to dictionaries, and arbitrary hard-coded VCL. An example of the second is the tile attribution rules. We extract the data from headers to match up with the list from the repository.
At the same time we were able to eliminate some hard-coded VCL rules that became obselete when we switched to HTTPS only in September. There were a number of edge cases around twenty year old browsers that vanished.
Excessive usage clients blocked
We had to block an app that was overusing the service. They were complying with the usage policy and followed the recommendation of publishing a contact email on the app store listing. This let us contact them to let them know and give them time to switch to a different service. Unfortunately the email address didn’t go to a human and instead we got a message that directed us to only report issues through the app. Even if we had wanted to download the app, it was region locked so we weren’t able to download it.
If you’re developing an app we recommend you have a way to switch the tile source without hard-coding a URL that requires a software update to go through the app store.
Improved tools for monitoring requests
Fastly has improved the tools we have to monitor unusual requests. They turned on their next gen WAF for us, which lets us better understand malicious actors. We also added several things to what we log in order to let us better see how the service is being used.
This let us identify a number of fake clients which we blocked.
Rate-limiting non-osm sites
We’ve applied by-IP rate-limiting to users other than osm.org. This only applies on higher zooms which are not all pre-rendered. The goal is not to reduce the speed of legitimate users but to let us better manage scrapers. The limits should be high enough that a user quickly looking around the map on a large screen will not hit them. When the limit is hit we throttle the speed tiles are delivered at.[1]
We’re still figuring out appropriate limits so you can expect them to change as we look at how well they’re working.
Enforcing referrer-policy
We’ve always required referers from websites but some sites have set policies that prevented them from being sent. We now have the tools to enforce this properly and expect to start soon.
Upcoming changes
I’m going to look at improving the way we distribute load within a region in order to reduce duplicated work while maintaining redundancy in the tile storage. This will probably be tested in the US first as is the worst off with work duplication.
Fastly’s WAF is something we’re still investigating. I’m sure it will enable new or easier stuff but we don’t know what yet.
Known issues
We publish daily tile logs but they’ve been failing some days. The cause of the issue is known but a fix still needs implementing. Even before fixing the failures are likely to be less frequent with some of the other changes we’ve made.
How to help
If you have a background in bot detection we are looking at with both the standard tile layer and the website. Please send the OWG an email. If you or your company want to host a tile rendering node have a look at the minimum required specifications and contact us if you can help.
Our email is operations (at) osmfoundation.org
Previously: Updates from September
For technical reasons we only throttle some tiles but those tiles are more likely to be hit by a scraper. ↩︎
