The container reads the config from the tag, not from a copy

Rate limits live in a private repo, ops-config, tagged per release. Sixty containers need the current file. The usual answer is a deploy step that copies it, and sixty copies that drift.

The files service has a fetch for exactly this: GET /limits.json?type=git&url=https://github.com/acme/ops-config.git&ref=v2026.09.01&pass=<base64 PAT>. The response is the raw file at that ref, streamed from GitHub. No git in the container. No checkout. No .git directory holding a whole history for one JSON file.

A cron line curls that URL into /etc/limits.json every hour, ref bumped when a release is cut. Roll back a config by changing ref. Pin a customer container to last month's limits by giving it last month's tag. Works for GitLab and Bitbucket as well.

The source of truth stayed in the repo; the container just learned to read it.