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.
