You can update a running Go service when a Kubernetes Secret or ConfigMap changes without restarting its pods by watching the Kubernetes API and applying the new configuration in-process. mamori’s Kubernetes provider watches those objects; mamori.Watch validates each changed configuration and atomically replaces the current snapshot only when it is valid. Your application must still handle the change callback to reconfigure dependent resources, such as a database pool or TLS client. This approach requires Kubernetes API access and does not make every library reload its settings automatically.
How mamori hot-reloading works
Instead of reading configuration only once at process startup, mamori’s Kubernetes provider reads Secrets and ConfigMaps through client-go and watches the Kubernetes API for changes. The provider emits updates for Added and Modified events. If the server-side watch ends while its context is still active, the provider re-lists and starts watching again. This is an API watch, not periodic polling; it depends on API connectivity and suitable permissions, and the documentation does not promise a fixed update or recovery time. See the mamori Kubernetes provider documentation.
As an Amazon Associate I earn from qualifying purchases.
On a change, mamori validates the whole configuration and atomically swaps in the new snapshot only if validation succeeds. That protects the application from accepting a partially updated or invalid configuration. It does not, by itself, rotate an existing database connection pool, replace a TLS client, or change any other resource already created from the old configuration. Your callback is responsible for such application-specific work.
When to use an API watch instead of environment variables or mounted files
| Approach | How updates reach the process | What the application must do | Important trade-off |
|---|---|---|---|
| Environment variables | Values are set for the container process at startup; changing the ConfigMap does not update the running process environment. | Restart the pod to make changed ConfigMap environment values available. | Simple startup injection, but not live configuration. Kubernetes documents that environment-variable consumers require a pod restart after a ConfigMap change. |
| Mounted ConfigMap volume | Kubernetes eventually refreshes projected volume data, subject to kubelet sync and cache propagation delay. | Notice the change and reread or reload the file. A mount using subPath does not receive updates. |
Can avoid an API client in the application, but propagation is not instantaneous and file consumers still need reload logic. See Kubernetes ConfigMap update behavior. |
| mamori Kubernetes API watch | The provider watches the Kubernetes API and delivers object changes to the running Go process. | Validate and handle the new configuration, including rebuilding or rotating dependent resources as appropriate. | Supports typed configuration reconciliation without a pod restart, but needs API permissions and application-specific callback behavior. See the provider documentation. |
Choose a rollout instead when a configuration change should be coupled to a new application version, or when a dependent library cannot safely adopt new values in-process. Hot reload changes configuration; it does not replace deployment controls, readiness checks, or a rollback plan.
#1 Best Overall
Install and define configuration sources
The mamori documentation specifies Go 1.26 or newer and installs the Kubernetes provider as a separate module. Confirm the current requirement in the project documentation when setting up a new project, since software requirements can change. The documented module is github.com/xavidop/mamori/providers/k8s; use the mamori core package as well. Blank-import the provider package so its source schemes are registered. The mamori introduction covers installation and provider setup.
Use a source tag to point each field at a Kubernetes object. The URI forms are k8s-secret://<namespace>/<name>[#key] and k8s-cm://<namespace>/<name>[#key]. With a key fragment, the provider resolves that key; without one, it resolves the entire data map as a JSON object. For ConfigMaps, key lookup checks data and then binaryData. The provider reference documents URI resolution.
Rank #2
type Config struct {
DBPassword string `source:"k8s-secret://prod/db-creds#password"`
LogLevel string `source:"k8s-cm://prod/app-config#log_level"`
}For credentials, prefer mamori’s sensitive value type, such as secret.String, rather than an ordinary string when the application design permits it. The package reference classifies Secret provider values as sensitive and ConfigMap values as non-sensitive. This helps with sensitive-value handling inside the application; it does not encrypt Kubernetes storage or change the permissions granted to the service account. See the provider API reference.
Keep the watcher alive and handle changes
Create a context with the lifetime of the service, call mamori.Watch[Config], and register a callback that applies accepted configuration changes. The returned watcher should remain alive for as long as the service needs updates. The following is a schematic example: adapt the callback and types to the API and lifecycle of your application’s clients.
ctx, cancel := context.WithCancel(context.Background())
defer cancel()
watcher, err := mamori.Watch[Config](ctx /* provider and callback options */)
if err != nil {
return err
}
defer watcher.Close()
// In the change callback:
// 1. Receive the validated configuration snapshot.
// 2. Build replacement resources if the relevant settings changed.
// 3. Switch new work to the replacements, then retire old resources safely.Do not assume that assigning a new configuration snapshot makes existing resources adopt it. For a database credential change, for example, application code may need to construct a replacement pool, verify it can connect, switch new requests to it, and drain the old pool. For TLS changes, the correct procedure depends on whether the service is a client or server and on the TLS library’s reload support. Keep the previous working resources available until replacements are usable where the application allows it; define how to surface a failed reconfiguration rather than silently claiming success. mamori documents the watch, validation, atomic swap, and callback flow, not a universal resource-rotation strategy. See the mamori introduction.
Grant only the required Kubernetes access
The workload needs permission to read and watch only the Secrets and ConfigMaps it uses, in the relevant namespace. Configure service-account RBAC narrowly; do not grant broad cluster-wide access as a convenience. Kubernetes recommends least-privilege access for Secrets. Its documentation also warns that base64 encoding is not confidentiality protection and recommends encryption at rest. mamori’s sensitive-value handling is defense in depth, not a substitute for those cluster controls. See Kubernetes guidance on Secret security.
Before enabling a watch in production, verify the workload identity can access the named objects and that the cluster’s API connectivity and policies permit watching them. If permissions are removed or the API is unavailable, the application cannot rely on receiving timely updates.
Shut down the watcher cleanly
Cancel the watcher’s context when the service is shutting down and close the provider as appropriate. The provider documentation describes Close as idempotent and terminal; a provider-created client releases its idle connections when closed. Do not close a watcher that the service still expects to use. See provider lifecycle details.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
