Thymeleaf & Spring MVC: Can live template edits propagate across rolling instances during zero‑downtime migration?

Answer to the Core Question

In a production Spring Boot application, Thymeleaf’s default behaviour is to cache parsed templates indefinitely. Changing a template file will not be reflected in any running JVM until the cache is evicted or the process restarts. Therefore, a purely “live” propagation across all instances during a rolling deployment is not supported out‑of‑the‑box. The practical workaround is to reduce the cache TTL so that a change is picked up automatically after a short period, and to ensure that all instances share the same template repository and dialect configuration.

Why a Full Cache Invalidation Is Not Feasible

• Thymeleaf’s cache is per‑JVM; there is no built‑in broadcast or JMX operation that clears the cache on every node in a cluster.
• Rolling restarts will inevitably leave a subset of pods with the old template version until their local cache expires.
• Mixing StandardDialect and SpringStandardDialect across instances can cause ClassCastException or missing variable resolution, as the dialects expose different variable resolvers.

Recommended Configuration for Zero‑Downtime Migration

1. Use a shared filesystem (NFS, cloud block storage, or a mounted volume) for your templates/ directory so that all pods read the same file set.
2. Set a low cache TTL in application.yml:

   spring:
     thymeleaf:
       cache: true
       cacheTTLSeconds: 5  # or 0 for no caching
   

   This forces a cache miss on the next request after a file change, making the new markup visible within seconds.
3. Keep dialects consistent across the cluster. If you need a custom dialect, deploy the same JAR to every instance and configure spring.thymeleaf.dialect identically.
4. Use a feature‑flag or versioned template if you must avoid a brief window of mixed rendering. Render the old template until all pods have refreshed, then switch the flag.
5. Verify the change by sending a request to each pod after modifying the template and ensuring the response contains the updated markup. Optionally, expose the TemplateEngine statistics via Actuator to confirm cache misses.

What You Cannot Do in Production

• Enable Spring Boot devtools in a containerised, production environment – it is intended for local development and may expose the hot‑reload endpoint.
• Trigger a global cache eviction via a single API call – you would need a custom JMX or messaging solution to notify every node.

Missing Diagnostic Detail

To fine‑tune the strategy, I need to know whether your application’s template files are stored on a shared volume or each pod has its own local copy. This determines whether a low TTL guarantees that all instances see the edit within the same timeframe.