Technical updates to the tile.openstreetmap.org service (OpenStreetMap.org Standard Layer)

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 92 billion tile requests, averaging around 36,770 requests per second. Each tile response was approximately 18 KB, resulting in a total monthly bandwidth usage of 1.26 Petabytes (that’s 1,260,000 Gigabytes).

Despite this heavy load, the service maintained 100% uptime throughout the month.

1. Map Change Updates - OpenStreetMap.org preference (Caching)

We’ve updated our Content Delivery Network (CDN) configuration so that tile expiry is now only honoured for requests coming directly from the OpenStreetMap.org website. For all other websites and apps, the CDN will prefer to serve older, cached tiles rather than attempting to fetch freshly rendered tiles from our backend servers.

This change means that tile requests from OpenStreetMap.org are no longer competing with third-party websites and apps for the most up-to-date tiles. As a result, the CDN can now respond more quickly to those external requests, while ensuring users on the OpenStreetMap website always see the freshest map.

Graph showing the large reduction in the backend request rate. (Change went live: Friday 2025-07-25).

We are happy to grant other mapper focused apps or websites which use the tile.openstreetmap.org service similar priority access to fresh tiles.

2. Further Enforcement of Tile Usage Policy

The tile.openstreetmap.org service is governed by a straightforward Usage Policy, which all users are expected to follow. This policy exists to ensure fair access for everyone and to prevent misuse of the service.

Unfortunately, some users ignore the policy and disrupt the service for others. When this happens, we take action to block the offending requests to protect overall service quality.

We have recently stepped up enforcement against applications that do not correctly identify themselves via the HTTP User-Agent header. See next section.

3. Image based Error Responses for Policy Violations

The tile.openstreetmap.org service previously returned HTTP error status codes (such as 403 Forbidden) in response to usage policy violations. We’ve now updated the service to instead return an image-based error tile.

To ensure these error tiles are displayed correctly in browsers and apps, the service now responds with an HTTP 200 OK status, rather than an error status. Additional technical information is provided in the x-blocked HTTP response header. We welcome feedback on how we can further improve this approach while ensuring the error messages are visible to end users.

The error tiles include a link to osm.wiki/Blocked, which explains the likely reason for the block and how developers can resolve the issue.

You can see an example of the error tiles in action on this demo page for a website missing OpenStreetMap attribution.

Examples of the new error images:

4. Additional Render Server in North America, Kindly Hosted by Pixeldeck.net

We’re pleased to announce that Pixeldeck.net (AS40536) is now providing and hosting an additional tile render server, giving us much-needed rendering capacity in North America.

This helps improve performance and reliability for users in the region. We’re very grateful to Pixeldeck.net for their generous support of the OpenStreetMap project.

5. AWS Render Server Upgrade (Pending - Done)

AWS kindly provides us with service credits to support a tile rendering EC2 instance in North America. During the next weekend maintenance window, we will be upgrading this server from an EC2 m6gd.16xlarge to a newer-generation EC2 m7gd.16xlarge instance.

The new instance type offers approximately 25% better performance, which will help improve rendering capacity and responsiveness for users in the region.

6. Improved Management of the Content Delivery Network (CDN) with Infrastructure as Code

The Content Delivery Network (CDN) used by tile.openstreetmap.org is very generously provided by Fastly. Their support is critical - it’s unlikely we would still be able to offer this service at this scale without their help.

We now manage the CDN entirely using OpenTofu (a fork of Terraform), together with the Fastly provider. All aspects of the service - including configuration and data dictionaries - are defined in Infrastructure as Code (IaC).

Changes are automatically deployed to a staging environment, allowing us to safely test updates before promoting the changes to production (“live”).

Using IaC provides greater transparency, as all changes are version-controlled and visible to the wider team. It also enables safer, automated deployments through a continuous integration (CI) approach, reducing the risk of manual errors and making it easier to review and collaborate on improvements.

The code repository is currently private, as it includes details of how we implement tile usage policy violation blocks - something we’re not yet comfortable making public. However, we’d be happy to hear from OpenTofu or Fastly experts interested in helping us improve our IaC setup.

66 Likes

If others are interested I am happy to provide further technical detail on how these changes have been implemented and how for example we prevent browser or CDN cache poisoning.

6 Likes

Thanks again for all the work you do to help the community, Grant! This is a great update and the stale tile serving update seems especially useful.

8 Likes

Thank you!

We are happy to grant other mapper focused apps or websites which use the tile.openstreetmap.org service similar priority access to fresh tiles.

Asking as an individual mapper, but is it possible to do this for JOSM (i.e. via User-Agent)? I use Carto in JOSM quite often over regions I map, flushing cache when I need fresh tiles from recent mapping, but based on the changes above and my testing that appears to no longer be possible. Thanks!

9 Likes

To add to this, EveryDoor would likely be impacted by this too, might be worth seeing if we can exclude any other common editors who use OSM tiles.

4 Likes

The EWG should be providing the information.

1 Like

Very good moves !!!

3 Likes

Are there / will there be some instructions somewhere for how to request this? (I run a few tools for OSM mappers at https://osm.mathmos.net/ and it would be good if the slippy maps there could show fresher tiles to mappers.)

5 Likes

That’s amazing progress! A big thank you to everyone who is working on this.

3 Likes

We could set up something similar to the missing attribution repo, where github issues push values into a dictionary on Fastly which is then matched against.

We’d still need to add JOSM and other editor user-agents, but the above would make sites simpler.

8 Likes

Hi there, I would like to ask how we can submit requests to be excluded from this “low priority” tile serving mode, the times to download tiles in my application has worsened by quite a bit:

1 Like

Third party sites have a lower priority for updates, not for serving tiles. In fact, by serving stale content, third party sites might be marginally faster in some cases.

4 Likes

… now this I wasn’t expecting:

that’s the top right-hand corner of a Potlatch 3 Window on startup :slight_smile:

Edit: The problem isn’t immediately reproducable

4 Likes

We finally banned Potlatch? :open_mouth:

14 Likes

Argh. Sneaky way to get me to install Potlatch 3 and double the userbase!

Need to find the request headers used.

13 Likes

Can you get the user-agent, x-requested-with, and referer headers?

If not, requesting tiles in a random area in the middle of the ocean works. If I know the tile numbers and approximate time I can get it from the logs.

It’s odd that only one tile is showing the blocked image. I can’t think of an explanation for that.

The tile render server palulukon.openstreetmap.org has been upgraded. AWS EC2 m6gd.16xlarge to a newer-generation EC2 m7gd.16xlarge instance.

6 Likes

These are some cool and impressive numbers! Thank you to the sysadmin team!

But are you able to give us some more figures for requests per sec? (eg “We served Xk rps at least whatever% the time” where X >> 36)

The mean is around 36,700 requests per second over the 1 month period. The peak hour over the month is around 70,669 requests per second. Peak minute is around 72,300 request per second. Monday and Tuesday are generally the busiest days. Saturday and Sunday are around half the number of requests.

The stats can be inspected via these 2 dashboards:

The recent changes have pushed the cache byte hit ratio at the edge to ~97%. The mean request hit ratio is lower at around ~94% due to many invalid or rejected requests due to policy violation.

The individual raster tile render servers also have local caches, these local hit ratios also exceeds 95%.

We will likely add another generously donated tile render server later this month (August 2025), this time in Asia. Currently all South East Asia and Oceania requests are sent via North America which is not optimal.

9 Likes

Would be nice to update some of those outdated wiki pages, e.g. while Servers/Tile Rendering - OpenStreetMap Wiki was updated recently, this page: Tile disk usage - OpenStreetMap Wiki had the last update five years ago and most of the data there is ten years old… (e.g. in regard to tiles on disk in rendering servers per zoom level and disk size used per zoom level, etc.)