HCP Vagrant 分階段停用，三個日期決定遷移期限
HashiCorp Blog · 2026-09-17
HCP Vagrant（即 Vagrant Cloud 上代管 box 與 registry 的服務）要分三階段收掉：先是停止新增，接著停止維護，最後整批砍掉部署。HashiCorp 在 2026-09-17 的公告裡把三個日期都寫死，用這個服務放公司內部 base image 的團隊，時間表已經不能再等官方鬆口。
背景
過去團隊要發佈自訂 Vagrant box，最省事的做法就是丟到 HCP Vagrant（前身 Vagrant Cloud）代管，靠它處理 box 版本、provider 分類與下載端點，Vagrantfile 只要指定 box 名稱就能拉取。這套代管模式現在被官方判定為要退場，公告明確說明官方即將停止維護整條代管路徑，但沒有解釋商業或技術上的原因，只給出時間表與替代方案。
值得注意的是，停用的只是「代管」這一層：Vagrant CLI 本身與 GitHub 上的原始碼倉庫會繼續維護，官方原文寫「The Vagrant CLI and source repository on GitHub will remain available」，代表本機開發跑 vagrant up 不受影響，受衝擊的是「box 從哪裡下載」這件事。
核心改動
公告列出的時間表分三段，每一段代表一種能力被關掉，不是一次性斷線：
| 日期 | 發生什麼事 |
|---|---|
2026-10-01 | 無法再建立新的 Vagrant box 或 registry（原文：users cannot create new Vagrant boxes or registries） |
2026-11-02 | HashiCorp 停止對現有 Vagrant 部署提供支援與維護（原文：HashiCorp will end support and maintenance for existing Vagrant deployments） |
2026-12-31 | HashiCorp 撤除所有剩餘的 Vagrant 部署（原文：HashiCorp will decommission all remaining Vagrant deployments） |
官方同時列了一份盤點清單，要求受影響團隊先確認以下項目是否還在依賴 HCP Vagrant：引用 registry box 的 Vagrantfile、CI/CD 裡下載或發佈 box 的流程、內部文件與 onboarding 指南、自動化腳本、自己維護的公開或私有 box，以及下游相依的專案。這份清單本身就是遷移的起點，因為多數團隊並不清楚 box 被引用的範圍有多廣。
替代方案方面，HashiCorp 的 developer 文件（storage-providers 頁面）列出三種可自管的儲存後端：Amazon S3、Azure Blob Storage、IBM Cloud Object Storage，每一種都會有專屬的遷移指南，內容涵蓋「準備 box」「搬移 box 到目標儲存」「更新 Vagrantfile 指向新位置」三個步驟，但文件目前還沒公布各後端的資料夾結構與具體語法細節。
影響範圍
受影響最直接的是用 HCP box registry 發佈或拉取 base image 的團隊：只要 Vagrantfile 裡的 config.vm.box 指向的是 HCP Vagrant 上的 box，2026-12-31 之後這條路徑就會直接斷掉，CI 流程裡凡是跑 vagrant up 前需要下載 box 的 job 都會失敗。第二類是自己維護公開 box 讓別人下載的專案，遷移的不只是自己的 pipeline，還包括所有下游使用者的 Vagrantfile 都要跟著改指向。
具體要做的事，按時間表反推：2026-10-01 前要決定是否還需要新增 box（之後就建不了新的），2026-11-02 前要完成盤點並選定替代儲存（S3、Azure Blob 或 IBM Cloud Object Storage 三選一），2026-12-31 前必須把既有 box 全數搬完並改好所有引用它的 Vagrantfile，否則開發環境與 CI 會在期限一到就直接斷線。目前無法自行改 Vagrantfile 的下游依賴，也要提前通知對方遷移時程。
需要協助時，官方管道是在 Vagrant GitHub 倉庫開 issue，或寄信到 vagrant@ibm.com；公告未提及是否會延長期限，也沒有列出三種儲存後端各自的完整遷移手冊，這部分官方文件仍在補齊中。