configmap-reload watches a mounted ConfigMap and pings your app

The mechanism is a filesystem watch and one HTTP request

The tool is described as a simple binary to trigger a reload when Kubernetes ConfigMaps or Secrets, mounted into pods, are updated. It watches mounted volume directories and notifies the target process that the config map has been changed. There is no Kubernetes API client, no watch on the ConfigMap resource, and no polling of the cluster. The whole thing works at the level of the mounted volume, which is the same level at which the application reads the file. That design is what makes it small: the dependency list in the module manifest is just fsnotify for the filesystem watch and the Prometheus client library for metrics, with the rest being indirect dependencies of the Prometheus client.

Only HTTP today, and the reason is Kubernetes

The limitation is stated directly: it currently only supports sending an HTTP request, but in the future it is expected to support sending OS signals such as SIGHUP once Kubernetes supports pod PID namespaces. That is a precise reason rather than a shrug. A signal has to be delivered to a process in another container, and the natural way to address a process by identifier from a sidecar is a shared PID namespace, which the project notes Kubernetes did not offer at the time. A webhook over HTTP has no such requirement, since it crosses the container boundary over the network. So the constraint is the platform's, and it is the kind that disappears with a platform change rather than with a patch to this program.

The flag set is short and every flag maps to one decision

The usage output is the entire configuration surface, and it fits in a few flags. The directory to watch is given with `-volume-dir`, which may be used multiple times, so a pod can watch several mounted volumes. The webhook target is `-webhook-url`, with `-webhook-method` defaulting to POST and `-webhook-status-code` defaulting to 200, which is the status code the tool treats as a successful trigger. `-webhook-retries` sets how many times the reload request is retried. The last two flags are for observability rather than behaviour: `-web.listen-address` defaults to port 9533 and is where the web interface and telemetry are served, and `-web.telemetry-path` defaults to `/metrics` and is the path under which the metrics are exposed. The separation of the listener from the webhook target is deliberate, since the metrics endpoint is usually scraped by Prometheus on the pod network while the webhook is called locally by the application.

The image is static, non-root and built for many architectures

The Dockerfile shows how carefully the image is kept minimal. The build stage is a Go image pinned by digest, the binary is compiled with CGO disabled and static linking flags that strip the symbol table and the DWARF data, and the runtime stage is a distroless static Debian image also pinned by digest. The build step itself is a single command:

RUN CGO_ENABLED=0 GOARCH=${TARGETARCH} go build --installsuffix cgo -ldflags="-s -w -extldflags '-static'" -a -o /configmap-reload configmap-reload.go

The container runs as user 65534, which is the non-root user in that base, and the entrypoint is the binary itself. The Makefile builds the same static binary for a wide set of targets, with Linux for amd64, arm, arm64, ppc64le and s390x, plus darwin-amd64 and windows-amd64, and there is a checksum target that computes SHA-256 digests with openssl. Since the image has no shell and no package manager, the only thing that runs in your pod is the watcher.

Where the images live changed with version 0.10

The distribution detail matters if you have a deployment pipeline pinning images. Since version v0.10 the Docker image is available from ghcr.io, and previous versions are available from Docker Hub. The Makefile has been updated to match, with the image name defaulting to ghcr.io/jimmidyson/configmap-reload and the tag to latest, and the Dockerfile carries the org.opencontainers.image.source label pointing back at the repository. The latest release tag is v0.15.0 from 2025-04-09, and the last push to the main branch was on 2026-08-24. The copyright header in the Makefile is Red Hat, Inc. 2016, and the licence is Apache 2.0 in a LICENSE.txt file, so if you are adopting this rather than merely using it, the terms are the permissive ones and the file is at the root.

The project is a single file, and that is the point

The repository is unusually small, and the layout is the design. At the top level there is `configmap-reload.go`, the entire program, plus a `go.mod`, a `go.sum`, a `Makefile`, a `Dockerfile` and a `LICENSE.txt`. There is no `internal/` tree, no package split and no test directory in the listing. The module requires Go 1.23.0 with a toolchain directive of go1.24.2, and the Docker build uses a newer Go image, which is a small inconsistency worth noting if you pin the toolchain. The upside of a single file is that you can read the whole thing in one sitting and understand exactly what it does and does not do, and for a sidecar whose entire job is to notice a file change and make one HTTP call, that is an appropriate amount of code. The downside is that there is no extension point, so if you need different behaviour you fork rather than configure.

Editorial conclusion

Adopt configmap-reload when your application reads its configuration from a mounted ConfigMap and you need it to pick up changes without a rollout, since the whole tool is a watcher plus one HTTP request. Do not adopt it if your app expects a signal rather than an HTTP call, because the project states it currently only supports sending an HTTP request and that signal support is expected only once Kubernetes supports pod PID namespaces. Verify first that your application exposes an endpoint you can point the webhook at, that the HTTP method and success status code match what that endpoint returns, and that the sidecar or init container approach works in your cluster's runtime, since the mounted volume behaviour is what the watcher depends on.

Frequently asked questions

Official sources

1. Issues
2. jimmidyson/configmap-reload on GitHub
3. License: Apache-2.0
4. README
5. Releases