tilegroxy docs
GitHub Issues Get tilegroxy
Edit this page Report an issue

Run in Production

A checklist of things to consider before deploying tilegroxy to production.

Checklist

Tilegroxy puts a lot of trust and responsibility in its operator to deploy it securely, in accordance to the operator’s use case. It is heavily recommended you fully read through the documentation before deploying this in a production (i.e. internet facing) deployment. The following is a non-exhaustive checklist of things to consider:

Production checklist

  • Deploy tilegroxy in a high-availability manner (that is to say N+1 Load Balanced)

  • Ensure server.production is true to disable X-Powered-By header, developer documentation, and the layer preview page

  • Configure Server.CORS with the origins your maps are served from and ensure wildcardorigin is false

  • Configure server.headers with any other static headers you want returned. A good reference of headers to consider is available here

  • Configure client.useragent with an agent that reflects your organization rather than tilegroxy itself

  • Configure logging to output at warning or error levels to avoid a bad signal to noise ratio

  • Consume logs into your aggregator or observability solution with a tool such as fluentbit/filebeat and/or rotate them with a tool such as logrotate

  • Ensure you have authentication configured either inside tilegroxy or upstream

  • Consider rate limits backed by a shared store with eviction disabled, set server.forwarded.trusted to exactly your proxies if limiting by IP, and alert on tilegroxy.ratelimit.error

  • Set server.tilejson.baseurls if TileJSON is enabled

  • Ensure you have monitoring of the health endpoints and the endpoints are not exposed to the internet

  • Ensure caching is configured against a distributed, high availability datastore

  • Consume telemetry data into an observability solution with trace sampling set at a level that won’t overwhelm you

  • Configure the analytics dials and monitor the metrics to ensure usage data isn’t dropped

  • Review the compatibility policy and check logs for deprecation warnings after each upgrade

  • Verify tilegroxy will be restarted on the unfortunate event it crashes such as via Docker’s restart: unless-stopped, Kubernetes' restart policy, or systemd’s Restart=on-failure

Edit this page Report an issue