I feel like this would do well to compare it to a more traditional CDN delivery method. Other than the obvious edge benefits of a CDN, this would seem to open

I feel like this would do well to compare it to a more traditional CDN delivery method. Other than the obvious edge benefits of a CDN, this would seem to open up issues around asset versioning. EG it's pretty standard to include asset/build hashes as part of urls, to ensure that the base app page and JS requests all get the correct build. You want JS to be cached between normal refreshes, but that to be busted on a new build. If you were to deploy a new docker container with this pattern, you'd lose the old hashes, so potentially getting weird intermittent failures if someone's operating the old app in their browser, but the accompanying assets are no longer available due to a new build having gone out? If you don't do hashes, how do you ensure a new page load doesn't use a cached asset? ETAGS? I think the article is a decent presentation of "docker 101" but left me with more questions than answers on what it actually means to try and do an dockerized ngnix static asset server rather than a CDN.