TYPO3 Site Handling and Proxy-Based Traffic Cutover

Answer to the Core Question

To avoid broken assets while shifting traffic between two TYPO3 installations, both instances must share the same cache data and temporary file storage. The recommended pattern is:

• Cache backend – configure Redis, Memcached, or a shared file‑based cache with identical keys and prefixes on both servers.
• typo3temp – mount the same typo3temp directory on both nodes (e.g., via NFS, GlusterFS, or a bind mount) or symlink it to a shared absolute path.
• typo3conf/data – keep this directory on shared storage or replicate it with a short‑interval rsync (e.g., every 5 min) so that configuration, cache dumps, and any runtime data are up‑to‑date before the new instance starts receiving traffic.

Why This Works

TYPO3 generates frontend assets (compressed CSS/JS, image thumbnails, etc.) in typo3temp and stores cache entries in the configured backend. If both installations see the same cache and temp files, a request routed to either instance will receive identical assets, eliminating the risk of a missing image or stale stylesheet during the phased cutover.

Concrete Steps for Your Scenario

1. Set up a shared cache backend – e.g., Redis:

   # /etc/typo3conf/LocalConfiguration.php
   $GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['default'] = [
       'backend' => '\TYPO3\CMS\Core\Cache\Backend\RedisBackend',
       'frontend' => '\TYPO3\CMS\Core\Cache\Frontend\VariableFrontend',
       'options' => [
           'host' => 'redis.example.com',
           'port' => 6379,
           'database' => 0,
           'prefix' => 'typo3_',
       ],
   ];
   

2. Mount typo3temp on a shared filesystem (example using NFS):

   # On both servers
   mkdir -p /mnt/typo3_shared/typo3temp
   mount -t nfs nfs.example.com:/share/typo3temp /mnt/typo3_shared/typo3temp
   # In each TYPO3 root
   ln -s /mnt/typo3_shared/typo3temp typo3temp
   

3. Replicate typo3conf/data:

   # Cron job on the legacy server (runs every 5 minutes)
   */5 * * * * rsync -avz --delete /var/www/legacy/typo3conf/data/ /var/www/new/typo3conf/data/
   

4. Verify the Site Handling configuration uses the same site UUIDs and root page UID in both installations so that cache identifiers match.
5. Perform a parallel load test: send identical requests to both instances through the proxy and confirm that ETag and Cache‑Control headers match.

Alternative – CDN or Object Storage

If a shared filesystem isn’t available, configure TYPO3 to store static assets in an object bucket (S3, MinIO) and point both instances to the same bucket. This guarantees identical URLs and cache headers without the need for a shared typo3temp.

Final Note

Use monitoring scripts to watch for latency on the shared mounts and to ensure that typo3conf/data changes are picked up by the new instance without manual intervention.

Missing Diagnostic Detail

Do you currently use a shared cache backend (Redis/Memcached) or a CDN for static assets? Knowing this will refine the exact configuration steps.