Run in Production
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:
Checklist
-
Deploy tilegroxy in a high-availability manner (that is to say N+1 Load Balanced)
-
Ensure
server.productionistrueto 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
wildcardoriginisfalse -
Configure
server.headerswith any other static headers you want returned. A good reference of headers to consider is available here -
Configure
client.useragentwith 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
-
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’sRestart=on-failure