Alternatives

Tilegroxy isn’t just a tile server and it isn’t just a cache. It’s a gateway. It lives between your map and your mapping providers so your frontend only ever talks to one consistent API. Every layer gets the same authentication, rate limits, caching, CORS rules, analytics, and telemetry no matter where it comes from. Your upstream keys stay in the configuration instead of in the browser. Switching vendors, or moving from a vendor to something you host yourself, is a config change your users never notice.

That also means tilegroxy doesn’t do a lot of heavy rendering itself. It can read PMTiles archives and simple PostGIS tables, and it can blend, crop, and tweak tiles from anywhere else. For anything beyond that, utilize a dedicated server and point tilegroxy at it with the proxy or CGI provider. Most of the projects below are as likely to sit behind tilegroxy as to be used instead of it.

Tilegroxy was inspired by TileStache and a lot of the configuration will look familiar if you’ve used it. Unfortunately TileStache hasn’t been maintained in years. The last release was in 2017 and the last commit landed in 2019. It’s not recommended for anything new.

Aside from actually being maintained, tilegroxy runs as its own server instead of inside a WSGI webserver, custom providers are written in Go instead of Python, and authentication, rate limits, analytics, and telemetry come built in.

Still running TileStache? See Migrate from Tilestache.

MapProxy is the go-to for OGC services. It can reproject between coordinate systems, serve sources back out as WMS, WMTS, TMS, or KML, and store caches in formats like MBTiles and GeoPackage.

Tilegroxy can pull from WMS, WMTS, and TMS sources but only serves ZXY tiles in Web Mercator. If your clients need a different projection or an OGC endpoint, use MapProxy. The lack of support for advanced protocols (especially WMS, WCS, and WFS) in tilegroxy is intentional, they can be a dangerous exploit vector and are harder to cache or measure.

MapCache and GeoWebCache are tile caches that come bundled with a bigger map server. MapCache runs as an Apache or nginx module next to MapServer. GeoWebCache is built into GeoServer and shares its security and admin.

If all your layers come out of one MapServer or GeoServer, its bundled cache is probably the easy answer. Tilegroxy makes more sense when that server is just one of several sources, or when you want access control that doesn’t depend on it. MapServer can even run directly under tilegroxy with the CGI provider, no separate webserver needed.

These generate vector tiles from a database, mostly PostGIS. They handle things like SQL functions and multiple tables per tile. Martin also serves sprites, fonts, and styles, and Tegola has its own caching and seeding.

The Postgis Vector provider covers the simple case of one table or view per layer so you don’t need a whole separate server for it. Anything fancier belongs in one of these, with tilegroxy proxying to it. You still get authentication, geographic restrictions, and caching, and you can merge their output with other vector sources using Composite MVT.

TiTiler renders tiles on the fly from Cloud Optimized GeoTIFFs and STAC items, complete with band math, color maps, and mosaics. Tilegroxy doesn’t read GeoTIFFs. Proxy to TiTiler and let tilegroxy cache the results so the same tile doesn’t get rendered twice.

TileServer GL serves vector tiles from local archives and can render them into raster tiles with a MapLibre style. Tilegroxy serves vector tiles from PMTiles but doesn’t render styles. If some of your clients can’t draw vector tiles, proxy to TileServer GL for the raster versions.

A WAF or CDN adds protection and caches tiles at edge locations close to your users, which is hard to beat for latency. However they don’t know anything about tiles. They can’t seed or purge by area, validate content from upstream, fall back to another source past a certain zoom, or keep tiles separate per tenant.

You don’t have to pick one, and honestly you probably shouldn’t. Tilegroxy’s own rate limits are for keeping usage fair, not for fending off an attack; having DDoS protection in front is highly advisable. You can use tilegroxy’s Cache Control configuration to tell the CDN how long to hold each layer, and make sure it isn’t caching layers that vary by user.

Tilegroxy shines when you consume maps from multiple sources, especially ones with different protocols or credentials, and want them all behind one uniform API. It’s also a good fit if you need to keep your keys out of the browser, share a limited upstream quota fairly, restrict layers or regions by user, or see who’s using what.

It isn’t the right tool on its own if your clients need something other than Web Mercator, need a WMS or WMTS endpoint, or you need to render tiles from raw data like GeoTIFFs, shapefiles, or map styles. In those cases reach for one of the servers above, either directly or behind tilegroxy.