OpenFreeMap turns open map hosting into a filesystem problem

A real 2007 photograph from State of the Map in Manchester. OpenFreeMap sits downstream of this community lineage: volunteer OpenStreetMap data, open tooling, and the practical question of how maps get delivered to real applications.

OpenFreeMap is easy to misread if you approach it as a cheaper Mapbox substitute. The more useful way to read the project is narrower and more technical: it asks whether a modern web map can be served as mostly static infrastructure, with OpenStreetMap-derived vector tiles prepared ahead of time, mounted as Btrfs images, and delivered by nginx instead of a tile server that has to stay awake for every request.[1][2]

That framing matters because map hosting usually combines several jobs into one opaque service: data processing, tile generation, style hosting, usage metering, attribution, CDN behavior, search, routing, and product billing. OpenFreeMap deliberately cuts that surface down. Its README says the project is not providing geocoding, routing, raster tiles, satellite imagery, elevation lookup, custom datasets, or static image generation.[1] That refusal is not a missing roadmap. It is the shape of the product.

Image context: the cover photograph shows State of the Map 2007 participants in Manchester. It fits this piece because OpenFreeMap depends on the older OpenStreetMap community bargain: people gather, survey, edit, license, and maintain a shared geographic commons, then later infrastructure projects decide how to make that commons usable at application scale.[5][8]

What the project actually offers

OpenFreeMap gives developers a public vector-tile endpoint and a self-hosting path for the same production stack. The public instance is meant to be usable without accounts or API keys, while the repository exposes the deployment machinery rather than keeping the operational side behind a commercial control plane.[1][2][6]

The key technical promise is not novelty in cartography. The project uses existing pieces: OpenStreetMap data, OpenMapTiles-style schema work, Planetiler for generation, MapLibre-compatible client rendering, Natural Earth and Wikidata where needed, plus OpenFreeMap's own deployment scripts and styles.[1][3][4] In other words, OpenFreeMap is a packaging and operations project. It turns a stack of open geospatial components into a service shape a small team can reason about.

That is why the project introduction should start with boundaries. If you need a map canvas under markers, polygons, dashboards, civic visualizations, or small web products, OpenFreeMap belongs in the evaluation set. If you need address search, turn-by-turn directions, satellite basemaps, proprietary point-of-interest enrichment, SLA-backed enterprise support, or per-customer custom tile generation, the project itself tells you to look elsewhere.[1]

The filesystem bet

The unusual part is the serving model. OpenFreeMap's README says there is no tile server running in the public stack, only Btrfs partition images with about 300 million hard-linked files served through nginx on Ubuntu.[1] The self-hosting docs make the same operational point from another angle: most self-hosters need only the http-host module because tile generation is expensive and OpenFreeMap publishes processed full-planet files weekly.[2]

This is an opinionated move. Most tile-hosting discussions eventually turn into server software, databases, caches, object storage, and scaling layers. OpenFreeMap pushes the hot path down into the filesystem and web server. The tiles have already been generated. The request path should be boring: a client asks for a vector tile, nginx serves a small file, Linux file caching does much of the work, and style/application logic remains in the browser or app client.[1][4]

There are tradeoffs. A filesystem-heavy stack needs disk planning, mount discipline, update sequencing, inode-aware thinking, and comfort with scripts that modify nginx and require sudo on a clean server.[2] This is not a local npm install. The self-hosting guide says a hosting-only node wants about 300 GB of disk, while tile generation wants roughly 500 GB of SSD and at least 64 GB of RAM.[2] That is still dramatically simpler than operating a full planet tile-generation pipeline by hand, but it is real infrastructure.

Why Planetiler matters here

Planetiler is the quiet enabler behind this shape. Its README describes a tool that generates vector tiles from OpenStreetMap and other geographic data sources, aiming to build a world map in a few hours on one machine without external tools or a database.[3] It can package output into MBTiles or PMTiles, and its vector tiles can be rendered by clients such as MapLibre.[3]

OpenFreeMap uses that generation lane to separate two concerns. Tile production can be heavy, periodic, and resource-hungry. Tile serving can be static, cheap, and repeatable.[1][2][3] That separation is the engineering idea. Teams evaluating OpenFreeMap should not ask only whether the public endpoint is free. They should ask whether their workload fits a precomputed basemap model, where weekly planet refreshes and standard styles are acceptable, and where application-specific data lives in a separate overlay rather than in the basemap itself.

For many products, that is a good split. The basemap changes slowly relative to the product's own markers, boundaries, events, or assets. If your application already treats the map as a background canvas, OpenFreeMap's static vector-tile model can remove a surprising amount of account, key, quota, and billing friction. If your application needs the basemap itself to encode live private data, OpenFreeMap is the wrong abstraction.

The client boundary is MapLibre

OpenFreeMap is also a sign that the MapLibre ecosystem has matured into a practical default for many web-map use cases. Simon Willison's 2024 note captured the developer experience cleanly: OpenFreeMap serves static vector tiles that work with MapLibre GL, and getting a map on a page can be as direct as pointing a MapLibre style URL at the public endpoint.[6] The MapLibre documentation surface matters because rendering, interactions, labels, style loading, and migration paths belong on the client side rather than in OpenFreeMap's server scope.[4]

That split is healthy. OpenFreeMap should not have to become a JavaScript mapping framework. MapLibre should not have to become a tile-hosting business. OpenStreetMap should not have to provide unlimited third-party tile infrastructure just because its data is open. OpenStreetMap's own copyright page is explicit that the data is open, with attribution and ODbL requirements, but the project cannot provide a free map API or free tiles for third parties.[5] OpenFreeMap sits in the gap between open data and usable tiles.

The practical consequence is that adoption has two contracts. First, the data contract: keep OpenStreetMap attribution visible and respect the Open Database License boundary.[5] Second, the runtime contract: understand that OpenFreeMap is tiles and styles, not search, routing, or a universal map platform.[1][4]

The stress test was revealing

The 2025 traffic spike made the architecture easier to evaluate. In Zsolt Ero's postmortem, OpenFreeMap saw roughly 3 billion requests and 215 TB of traffic in 24 hours after Wplace used it heavily, with a reported burst around 100,000 requests per second.[7] The public service did not pass that event cleanly; some tiles failed, Cloudflare rules had to be introduced, and the project identified server-configuration work for follow-up.[7]

Still, the incident is useful evidence. The interesting part is not that a free service absorbed an absurd load forever. It did not. The interesting part is that the static-tile architecture had enough mechanical sympathy to bend before it broke. Ero reported a 99.4 percent CDN cache rate and said his own servers were still handling the uncached remainder at about 1,000 requests per second.[7] For a small open-source map-hosting project, that is a serious proof point.

It also clarifies the adoption boundary. If your application can produce sudden global traffic, you should not treat the public OpenFreeMap endpoint as an invisible subsidy. Self-host, sponsor, cache responsibly, identify your app, and keep a fallback story. OpenFreeMap's own model is strongest when heavy consumers move from "free endpoint" thinking to "reproducible stack" thinking.[2][7]

Where it fits

OpenFreeMap is strongest for teams that want a credible default basemap without entering the commercial map-metering loop on day one. Civic projects, internal tools, open-data dashboards, indie web products, prototypes that might become real, and self-hosted applications can all benefit from a map layer that is open enough to inspect and simple enough to operate.[1][2][6]

It is weaker where the map provider is expected to be an end-to-end geospatial platform. Address search, routing, traffic, satellite, business listings, analytics, compliance support, and contractual uptime all sit outside the project. That is not a criticism. It is the reason OpenFreeMap can exist as a small project in the first place.[1]

The adoption pattern should be staged:

Start with the public endpoint for prototypes and low-risk internal tools.
Confirm attribution, style behavior, and MapLibre integration early.[4][5]
Move production or high-traffic workloads toward self-hosting or an explicit support/sponsorship relationship.[2][7]
Keep search, routing, and proprietary overlays as separate architectural decisions rather than assuming the basemap provider should absorb them.[1]

The main failure mode is mistaking "free map tiles" for "free map platform." OpenFreeMap is more interesting than that. It is a disciplined infrastructure wager: if you precompute the expensive geospatial work, keep the serving path static, and refuse adjacent product scope, open map hosting becomes small enough to understand again.

cronfeed.work