Hi James,
Zen Server is designed to operate as an “office-local” shared DDC. In other words, you would spin an instance up in your London office and another in your Sophia office and they would be isolated from each other. Zen does not currently support authentication, so putting it on the cloud is not recommended without it being behind a VPN. The overhead of the VPN could affect performance when pulling cached data, of course. Zen does support namespaces, but does not currently enforce access-control, so anyone that can hit the server can access all the data on it.
Cloud DDC, on the other hand, offers authentication via OIDC, enforced namespaces, and has replication. Also, since Cloud DDC is designed to operate on a public-facing network, it can live without the overhead of a VPN, which could make it significantly faster.
In terms of setup, Zen has less screws to tighten, but as of Unreal 5.5, the documentation states that the Linux build is not considered production-ready to use as a shared DDC, and Epic recommends Windows server to install it on. You would need Windows instances to run it on the cloud.
Epic provides helm charts for Cloud DDC and pre-built container images, so deploying it on Kubernetes shouldn’t be too painful. You can also try it out locally with Docker.
If you’re curious to dig into the nuts and bolts of either project, Zen is currently a separate repo on Github, while the Cloud DDC stuff is in the UnrealEngine project (under Engine/Source/Programs/UnrealCloudDDC). The Cloud DDC folder contains the helm charts and docker compose files you might want to take a peek at.
Caches are populated upward the same way they are searched; for example the user’s local DDC, the “office” Zen Server, and then Cloud DDC. The Cloud DDC will then automatically replicate the data to other places. For example, if you had a build farm that was isolated somewhere, it could still populate the Cloud DCC and a user anywhere could pull that cached data down.
I hope this answered your questions!