Is the presence of wget in the image part of gluetun's supported surface, or an internal detail?

[csmarshall]

Short question, hopefully a one-line answer.

The image installs GNU wget in its final stage (RUN apk add --no-cache --update -l wget), and a fair amount of downstream tooling relies on it — most visibly the widely-copied healthcheck override:

healthcheck:
  test: ["CMD","wget","--no-verbose","--tries=1","--spider","http://www.google.com/"]

…plus monitors and scripts that docker exec gluetun wget --spider <url> to verify egress actually traverses the tunnel. (Disclosure: I maintain one such downstream monitor, so I have a direct stake — though this affects the healthcheck override above far more broadly than it affects me.)

The question: do you consider wget's presence part of gluetun's supported surface (safe for downstreams to depend on), or an internal implementation detail you'd feel free to drop or replace (slimming the image, going Go-native, etc.)?

Either answer is genuinely useful — I just want to design correctly against it:

• "Supported" → downstreams can exec wget with confidence.
• "Internal detail" → we stop assuming it and degrade gracefully when it's absent (which I'm doing regardless).

I notice the image already ships a proper self-contained HEALTHCHECK (/gluetun-entrypoint healthcheck) — which is the right contract for "am I healthy" and needs no exec at all. So I suspect the answer may be "use that, don't exec into my container." If so, that's worth a line in the docs, because the wget healthcheck override above is very common in the wild.

If the answer is "supported," I'm happy to send the docs PR myself — just say the word.

(Adjacent, optional: have you considered publishing an SBOM attestation on the image? It'd give downstreams a machine-readable, per-release answer to "what's inside" instead of guessing. Happy to raise separately if it's of interest.)