Is your feature request related to a problem? Please describe.
The cup Docker image does not ship with a HEALTHCHECK instruction, which means containers or tools that use depends_on: condition: service_healthy cannot properly wait for cup to be ready.
Monitoring tools that rely on container health state show it as unknown.
The image does not include curl, wget, or a shell, so there is nothing to probe with out of the box.
Describe the solution you'd like
A built-in /health HTTP endpoint in cup's web server, paired with a HEALTHCHECK instruction in the Dockerfile using a small health subcommand. Since cup already runs an HTTP server, a simple loopback request would be near-zero overhead and the image would stay minimal.
Describe alternatives you've considered
Bundling a static tool like wget alongside the binary would also work. A basic TCP check (nc -z localhost 8000) would be a simpler option, though it requires nc to be present in the image. Of the three, the built-in /health endpoint feels like the most natural fit for a Rust HTTP service.
Additional context
Issue #135 mentioned this previously, sharing here again with concrete suggestions in case it helps move it forward.
Is your feature request related to a problem? Please describe.
The cup Docker image does not ship with a HEALTHCHECK instruction, which means containers or tools that use
depends_on: condition: service_healthycannot properly wait for cup to be ready.Monitoring tools that rely on container health state show it as unknown.
The image does not include
curl,wget, or a shell, so there is nothing to probe with out of the box.Describe the solution you'd like
A built-in
/healthHTTP endpoint in cup's web server, paired with a HEALTHCHECK instruction in the Dockerfile using a smallhealthsubcommand. Since cup already runs an HTTP server, a simple loopback request would be near-zero overhead and the image would stay minimal.Describe alternatives you've considered
Bundling a static tool like
wgetalongside the binary would also work. A basic TCP check (nc -z localhost 8000) would be a simpler option, though it requiresncto be present in the image. Of the three, the built-in/healthendpoint feels like the most natural fit for a Rust HTTP service.Additional context
Issue #135 mentioned this previously, sharing here again with concrete suggestions in case it helps move it forward.