Does ModX Page Caching Support Seamless Zero-Downtime Migration?

Direct Answer

No. MODX page caching is a performance optimization, not a migration or high-availability mechanism. It does not natively support zero-downtime cutover, and it does not invalidate cache entries in response to DNS changes or load-balancer switchover.

Confirmed Behavior vs. Likely Misconception

Confirmed across MODX Revolution (and generally Evolution) is that cached page output is written to a local storage location—commonly core/cache/—or to an external backend if cache_handler is configured. Cache invalidation is tied to resource-saving events, manager Clear Cache actions, or expiry timers. There is no documented DNS-aware invalidation hook.

The likely misconception is that a parallel deployment will inherit a pre-warmed cache or that MODX will coordinate cache state between old and new nodes. It will not. Unless cache storage is explicitly shared, the new environment starts with a cold cache. Conversely, if storage is shared during cutover, simultaneous writes from both nodes can poison entries or serve stale HTML.

Steps for This Migration

1. Record the source environment's cache settings in System Settings: cache_handler, cache_expires, cache_default, and cache_disabled. Exact names and defaults are version-sensitive; verify against your installed MODX version.
2. Inspect the cache path on both servers. If it is local disk (the default), do not copy core/cache/ between environments. Those files can contain absolute paths, session data, or environment-specific placeholders.
3. On the target node, either leave caching disabled until cutover or clear the cache immediately before traffic shifts. After DNS or load-balancer switchover, manually clear the cache or wait for expiry to ensure fresh pages are generated.
4. Validate in staging: clear the cache, request a page, confirm a new cache entry is created, then simulate a switchover and verify the new node serves fresh content rather than stale HTML.

Missing Diagnostic That Changes the Recommendation

Is your cache storage local file-based or shared/external? If local, the safe path is a cold cache on the new node followed by a post-cutover clear. If shared (for example, memcached or a network path), you must isolate the new node's cache backend before cutover to avoid cache poisoning.