2016年才到不久，Docker就推出Docker Engine 1.10 RC版本。而Docker表示，新版本Docker Engine能為映像檔提供更好的安全基礎外，Docker也提供舊映像檔更新的搬遷步驟（migration step），並且提供相關搬遷工具，將遷移時間降到最低。
Docker資深工程主管Arnaud Porterie表示，Docker Engine 1.10版本將完全改變Docker Engine在本機儲存映像檔的方式。過去的映像檔都是隨機指派通用唯一辨識碼（Universally Unique Identifier，UUID）進行命名，而新版本透過則安全雜湊（secure hash）的機制，Docker得以透過映像檔的內容，為映像檔進行ID編號。
著《Docker源碼分析》的孫宏亮解釋，Docker從UUID改由安全雜湊機制命名，其中關鍵差異在於，Docker每一層layer的映像檔ID，全部都必須透過映像檔內部的資料來產生，不再是使用過去的隨機UUID。他表示，藉由此方法，透過docker build建構映像檔時，映像檔內容與映像檔ID，將會形成1對1的對應關係。
由於每一個映像檔僅會產生一組獨特的ID，因此可以減少儲存同樣一份的映像檔，孫宏亮表示，對於減輕Docker Hub的儲存壓力也是大有好處。他也舉例，過去同一個Dockerfile，在10臺不同的機器上build，因為映像檔快取僅僅在本機端有效，因此將會產生10個內容相同，但是ID編號不同的映像檔。另外，由於是透過UUID產生隨機編號，如果這10臺機器，分別把這10份映像檔儲存到同樣的Doocker Registry，則會產生多餘的9份映像檔，因此也會對Docker Registry產生儲存上的壓力。
孫宏亮也解釋了為何新版Docker Engine使用雜湊機制的命名方式，將會比使用UUID命名映像檔來得更加安全。他表示，由於映像檔ID與映像檔內容所形成的1對1對應關係，如果有心人士只有偽造映像檔ID或映像檔其中之一，都無法成功。他解釋，對於單一映像檔，雖然可以同時偽造ID以及映像檔內容。但是映像檔間所形成的父子關係（parent），將會導致原有的子映像檔記錄的ID失效，因此仍然不可使用完整的映像檔，除非有心人士將某映像檔以及其所有子孫映像檔檔全部進行偽造，但是這樣所付出的成本非常高。
針對有升級需求的用戶，Docker也提供了前置作業的指南。Docker表示，如果要讓現有映像檔能符合新的運作方式，必須將現有映像檔的命名方式從UUID，改為由內容產生ID編號。而這也意味使用者必須計算目前檔案的安全總和檢查碼（secure checksum）。
Arnaud Porterie表示，Docker daemon首先會計算使用者目前檔案的安全總和碼，在開啟Docker daemon後，現有的映像檔、標籤以及Containers也會完成遷移，而所有的映像檔及標籤也都會配有新的安全ID。孫宏亮則認為，Docker使用者遲早必須導入這一步措施，而「長痛不如短痛。」他表示，由於新版本並不會改變映像檔內容，因此轉換過程可以透過離線作業完成，而開發人員也可以使用Docker 1.10來製新的映像檔。
不過孫宏亮也表示，新版本也會對於既有的維運團隊、開發團隊帶來衝擊。比如，舊映像檔與轉換後的新映像檔的標籤、儲存庫很有可能一致，進而產生了衝突問題，使用者也必須事先需要規畫相對應的轉換策略。同時他也認為，線上環境映像檔的更新會是一個值得關注的議題。儘管Docker Engine會為使用者帶來陣痛期，「但是不可否認，映像檔的大改，我認為是一個劃時代的功能，我個人非常喜歡。」孫宏亮表示。