Introduction

Editing a ConfigMap at runtime is easy. Getting a running Spring Boot application to pick up that new value is the part that usually goes wrong. Kubernetes and Spring Boot solve different parts of the problem: Kubernetes can update mounted ConfigMap files inside a pod, but Spring Boot does not automatically rebind every configuration property just because a file changed.

So the real question has two layers. First, how do you change the ConfigMap object? Second, how does the running application notice and apply the change? If you separate those two concerns, the correct design becomes much clearer.

Update the ConfigMap Object

The operational part is straightforward. You can edit the ConfigMap directly:

kubectl edit configmap my-app-config -n prod

Or apply a new manifest:

1apiVersion: v1
2kind: ConfigMap
3metadata:
4  name: my-app-config
5  namespace: prod
6data:
7  application.yaml: |
8    feature:
9      enabled: true
10    greeting:
11      message: Hello from ConfigMap

Then apply it:

kubectl apply -f configmap.yaml

That updates the Kubernetes resource, but it does not guarantee your Spring Boot process will instantly refresh its already-bound beans.

Mount the ConfigMap as Files, Not Environment Variables

If you need runtime updates, mount the ConfigMap as a volume. Environment variables are fixed at container start and do not change in the running process.

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: my-app
5spec:
6  replicas: 1
7  selector:
8    matchLabels:
9      app: my-app
10  template:
11    metadata:
12      labels:
13        app: my-app
14    spec:
15      containers:
16        - name: app
17          image: my-app:latest
18          volumeMounts:
19            - name: config
20              mountPath: /etc/config
21      volumes:
22        - name: config
23          configMap:
24            name: my-app-config

In Kubernetes, mounted ConfigMap data is eventually updated inside the volume when the ConfigMap changes. One important caveat is that subPath mounts do not receive those live file updates the same way, so avoid subPath if live refresh is a goal.

Make Spring Boot Read From the Mounted Config

Spring Boot still needs to know where the external configuration lives. One option is to import the mounted directory as a config tree.

spring:
  config:
    import: optional:configtree:/etc/config/

Or you can mount a whole application.yaml file into a location Boot already reads. The key point is that Boot must treat the mounted files as an external config source.

A simple properties class might look like this:

1import org.springframework.boot.context.properties.ConfigurationProperties;
2
3@ConfigurationProperties(prefix = "greeting")
4public record GreetingProperties(String message) {}

Binding the property is only half the story, though. If the file changes later, the bean still needs a refresh strategy.

Refreshing the Running Application

A running Boot app will not automatically rebind every property just because a mounted file changed. Common approaches are:

• perform a rollout restart after editing the ConfigMap
• use a refresh mechanism such as Spring Cloud Kubernetes configuration watching
• implement your own file-watching or reloading logic for a narrow set of settings

A rollout restart is often the simplest and most predictable production answer:

kubectl rollout restart deployment/my-app -n prod

If you need near-live refresh without restarting the pod, use an actual refresh architecture. In the Spring ecosystem, that usually means Spring Cloud Kubernetes support plus refresh-aware beans rather than assuming plain Spring Boot property binding will handle it alone.

Choose the Simplest Reliable Model

In many systems, dynamic config sounds attractive but restart-based reload is operationally safer. A restart gives you one clean, auditable transition from old config to new config.

Use true runtime refresh only when the business requirement really demands it. Otherwise, mounted ConfigMap plus controlled rollout is often the better tradeoff.

Common Pitfalls

The biggest mistake is expecting ConfigMap-backed environment variables to change in a running container. They do not.

Another issue is mounting the ConfigMap with subPath and then wondering why updates are not appearing in the mounted file.

A third problem is assuming Spring Boot will automatically refresh already-bound beans when the file changes. Plain property binding does not guarantee that behavior.

Summary

• Editing the ConfigMap object and refreshing a running Spring Boot app are two separate concerns.
• Use volume mounts, not environment variables, if you want the pod filesystem to see ConfigMap updates.
• Avoid subPath for live-updating ConfigMap mounts.
• Spring Boot needs an explicit refresh strategy if configuration should change without a restart.
• In many production systems, a controlled rollout restart is the simplest and safest way to apply new ConfigMap values.