Hoistbay：開源 S3 桌面客戶端，上傳規則與清快取收進同一視窗

Facebook Line Messenger Telegram

網站檔案放在 Amazon S3、前面掛 CloudFront 的人，每次更新內容都在重複同一段流程：把新檔案傳上去，回頭檢查 Cache-Control 和 Content-Type 有沒有設對，真的著急看到新版本時，還得再開 AWS Console 找到 distribution 清一次快取。幾個動作散在兩三個視窗裡，做久了自然會想找個把它們收攏的東西。

Hoistbay 就是衝著這段流程來的：一個 MIT 授權的開源桌面應用，目前支援 macOS 和 Windows，把 S3 檔案管理、上傳時自動套用的 Header 規則、CloudFront 快取清除放在同一個視窗裡。它免費、不需要註冊帳號，官方定位是沒有自家後端、沒有遙測。

不過在把 AWS 金鑰交給任何桌面工具之前，有幾個問題比功能清單更值得先問：金鑰會被存成什麼樣子？安裝包沒有簽章代表什麼？它的能力邊界在哪？這篇把 Hoistbay v1.1.2 的原始碼、更新紀錄和安裝包實際翻過一輪，用查到的東西逐條回答。

AWS 金鑰交給它，會被怎麼對待

官網首頁寫得很直白：金鑰存在作業系統鑰匙圈，應用只跟 AWS 說話。這句承諾在 2026 年 10 月 21 日之後才是完整的事實。

v1.1.2 的更新說明自己講清楚了來龍去脈：這一版把 AWS 金鑰從應用偏好檔裡的明文，改成存進 macOS 鑰匙圈，Windows 上改用綁定使用者帳號的 DPAPI 加密，同時移除了一條可能在鑰匙圈不可用時把憑證存回明文的回退路徑。換句話說，在這個版本之前，金鑰確實以明文形式存在應用的偏好檔裡。

程式碼可以對上這個說法。credential_store.dart 的類別註解明寫「刻意不留明文回退：鑰匙圈寫入失敗時，錯誤直接回報給使用者，金鑰不落盤」；profile_service.dart 則負責處理舊版遺留，第一次開啟設定檔時，把偏好檔裡的舊金鑰搬進鑰匙圈，確認寫入成功後才把明文從原處刪除。官方也提醒了一件容易被忽略的事：偏好檔如果曾經被手動備份，舊備份裡可能還留著明文金鑰，建議直接換一組新的存取金鑰。

原始碼裡還有一個看得出用心的細節：所有 profile 的金鑰共用同一個鑰匙圈項目，而不是一個 profile 一個項目。這麼做的目的在註解裡寫明白了，應用未簽章的狀態下，每次更新程式碼簽章都會變，macOS 會重新詢問存取權，共用一個項目至少把詢問次數壓到每次更新一次，而不是每個帳號問一次。它也刻意用登入鑰匙圈而非資料保護鑰匙圈，因為後者需要正式的團隊簽章才能取得對應的 entitlement，這又回到同一個根源：安裝包沒有簽章。

對外連線方面，我把 v1.1.2 的 lib 目錄整個掃過一輪：全部原始碼裡只有兩個對外連結，是作者的 X 和 LinkedIn 個人頁，出現在關於頁、交給系統瀏覽器打開；依賴清單裡找不到任何分析或遙測相關的套件，S3 走官方 SDK 的區域端點，CloudFront 則走它固定的全域 API 端點。附帶說明，金鑰儲存這段的依據是公開原始碼與官方文件，Windows 版 DPAPI 的實際行為我沒有對應環境可以親驗，這部分以官方說明為準。

金鑰怎麼存是一回事，你給它多大的權限是另一回事。專案 README 提供了一組最小權限參考：只是瀏覽的話，s3:ListAllMyBuckets、s3:GetBucketLocation、s3:ListBucket、s3:GetObject 就夠用；要上傳和刪除再補 s3:PutObject 和 s3:DeleteObject；要清 CloudFront 快取，則是 cloudfront:ListDistributions、cloudfront:CreateInvalidation、cloudfront:GetInvalidation 這一組。替它單獨建一組權限受限的 IAM 使用者、把可存取的範圍限縮到真正要管理的 bucket，是比研究介面漂亮與否更值得花時間的設定。起步順序照 README 的建議做就很穩：先拿一個測試用的 bucket，配一組只有必要權限的金鑰，完整跑一輪再考慮正式環境。對簽章這件事仍不放心的人，專案也提供從原始碼自行編譯的路徑，官方說明只要幾分鐘，機器上有 Flutter 環境就能出一份自己盯著產生的安裝包。

安裝包沒有簽章，第一次打開會遇到什麼

我從官網下載按鈕抓了 macOS 版壓縮包下來檢查。解開後的 Hoistbay.app 是通用包，Intel 和 Apple Silicon 都能跑，版本 1.1.2（build 4）。簽章狀態用 codesign 檢查的結果：簽章形態是 ad-hoc（臨時簽署），沒有開發者團隊身分，TeamIdentifier 未設定，Gatekeeper 的 spctl 檢查直接回覆 rejected。

翻成白話：這個安裝包沒有向 Apple 註冊身分，也沒有公證。macOS 第一次打開會把它攔下來，需要在應用上按右鍵選打開，或到系統設定的隱私與安全性裡放行；Windows 10 和 11 則會跳 SmartScreen 警告，要點開更多資訊、再按仍要執行。這在獨立開發的開源專案裡很常見，不算異狀，但它確實代表：你要把一組 AWS 金鑰放進一個沒有可驗證簽章身分的應用。信任的基礎只能放在原始碼公開、誰都能檢查、也提供從原始碼自行編譯的路徑這幾點上。

沒簽章還有一個比較少人預期的後果，官方更新說明直接寫了：因為沒有 developer ID，每次更新 App 之後，macOS 會再問一次鑰匙圈存取權限，要再按一次永遠允許。不影響功能，但要是哪天更新後它突然不問了，反而值得回頭確認安裝包的來源。

順帶一提官網的一個小落差：版面上的版本標籤還停在 v1.1.0，但下載按鈕實際指向 GitHub 的最新發布，抓下來的是 v1.1.2。確認版本與更新內容時，以 GitHub Releases 頁面為準最保險。

它實際幫你做什麼：上傳規則、快取清除、檔案管理

把 S3 當網站儲存空間的人，對這類桌面客戶端不會陌生，Cyberduck、S3 Browser 都是老名字。Hoistbay 的差異不在功能多，而在它把部署之後那幾個重複動作做得相當集中。

Header 規則是核心。每個 bucket 可以設一組規則，按檔名模式在上傳時自動套用 HTTP 標頭，官網示範的例子是副檔名 .js 和 .css 給一年份的 max-age、.html 給 no-cache。規則設好之後自動生效，不必再逐個物件打開屬性修改。對檔名帶內容 hash 的靜態網站來說，這正好對上主流做法：內容變了檔名就跟著變，長快取不怕舊版流傳；HTML 檔名不變，就用 no-cache 保住即時性。

CloudFront 那半是失效請求（invalidation）。換完檔案後，邊緣節點裡的舊快取不會自動消失，Hoistbay 讓你直接看到帳號下的 distribution 清單，對 /* 或指定路徑送出失效請求並追蹤進度，不用再開 Console。計費上，AWS 每個帳號每月前 1,000 個失效路徑免費（所有 distribution 合計），含萬用字元的路徑算一個路徑，偶爾清一次整站的成本負擔不大。不過若是天天都要清的場景，正解仍是版本化檔名讓快取自然過期，把失效請求留給真的需要立刻生效的時刻。還有一個 AWS 文件裡明寫、但容易誤解的點：失效請求清的是 CloudFront 邊緣節點的快取，使用者瀏覽器或公司內部的代理快取不在管轄範圍，那些快取裡的舊版本要等它們自己過期。期待失效請求能讓每一個訪客瞬間看到新版本，是不切實際的。

檔案管理是基本功：整個資料夾拖進上傳、結構保留，資料夾也能整包下載；批次重新命名、搬移、刪除，跨 bucket、跨區域複製，超過 1,000 個物件的目錄照樣分頁瀏覽。物件檢視器能看屬性、HTTP 標頭、x-amz-meta- 開頭的自訂 metadata、標籤與版本，其中一部分可以直接就地修改，Content-Type 設錯的檔案不必重傳。多帳號情境則是多組 profile 切換、支援 session token，bucket 所在區域自動偵測。

Hoistbay 的主視窗官方截圖，左側為帳號、導覽與 bucket 側邊欄，中央為麵包屑導覽、搜尋列與檔案清單 — Hoistbay 官方截圖：主視窗以左側 bucket 側欄與中央檔案清單構成，麵包屑標示目前所在資料夾（GitHub 儲存庫官方圖，2026 年 10 月擷取）

工程細節上，它對 AWS SDK 做了兩處修正，都對應實際會踩到的坑：檔名（物件路徑）帶空格或括號這類特殊字元時，官方 SDK 的簽章計算會把百分號編碼再編一次而出錯，Hoistbay 自己重簽了 Signature V4；批次刪除補上了 AWS 規定要求的 Content-MD5 標頭。列表與 distribution 查詢內建自動重試（上限三次），刪除的結果則逐物件回報成敗，不會整批安靜地失敗。所有上傳、下載、刪除、失效請求的進度與結果，都收在一個活動面板裡，有開始結束時間與成敗狀態。

想先看介面長什麼樣子再決定裝不裝，官網內建了一個瀏覽器版的互動示範：打開資料夾、丟檔案進去、看規則套用、按清除快取，整段流程在瀏覽器裡跑，官方說明是不會碰到真的 AWS。示範裡的 bucket 放了一個小型網站的檔案樹，丟一個 .js 或 .html 檔進去，就能看到 Cache-Control 規則被套上，活動面板也會記下這次操作；示範只到檔案清單為止，實際 App 裡的物件檢視器在這裡沒有對應版本，想看細節還是得裝 App。

Hoistbay 官網的瀏覽器互動示範截圖，左側為示範帳號與 bucket 側邊欄，中央為檔案清單與上傳按鈕，底部提示可上傳 .js 或 .html 檔觀察快取規則套用 — 官網內建的瀏覽器互動示範：不用安裝、不會碰到 AWS，就能走一遍檔案清單與規則套用流程（Hoistbay 官網，2026 年 10 月擷取）

邊界在哪：只認 Amazon S3，還有一份寫死的區域清單

支援範圍是最需要先講清楚的邊界。原始碼裡沒有自訂端點的欄位，Hoistbay 連的是 Amazon S3 與 CloudFront 的官方端點，Cloudflare R2、MinIO、Wasabi 這類 S3 相容儲存連不上。原因是機制性的：相容儲存需要填自訂端點（R2 的端點就包含帳號代碼），而 Hoistbay 的連線設定裡根本沒有這個欄位，SDK 只會按區域組出標準的 AWS 端點。平常主要在管這些儲存的話，Cyberduck 這類明確支援多種後端的工具比較合適；重度 Cloudflare 使用者也可以從我們整理過的 Cloudflare 開源工具清單找方向。

區域選單有個具體限制：profile 的區域下拉選單在原始碼裡寫死了 15 個選項，都是 us、eu、ap、sa、ca 的早期成員，沒有香港 ap-east-1，也沒有中東與非洲的新區域。bucket 本身的區域會自動偵測，但如果你常用的區域不在那份清單裡，初始連線就選不到。

企業環境要注意它不讀 ~/.aws/credentials，也不匯入 AWS CLI 的設定檔：profile 是應用自己保存的，不會把你現有的 CLI 環境帶進來。AWS SSO 與 IAM Identity Center 目前沒有官方支援說明，公司帳號走 SSO 登入的話，先確認再考慮。CloudFront 這部分也只做失效請求，要改 origin、cache behavior、憑證，還是得回 AWS Console。

專案本身的體質也該列入判斷。GitHub 倉庫 2026 年 10 月 8 日才建立，到本文查證時 24 個 commits、13 顆星，三個 issue 全是作者自己合併的 PR，還沒有外部使用者回饋的累積。它在 10 月 20 日上了 Product Hunt，當天排到 Product of the Day 第三名，到本文查證時 15 個推票，早期採用者的數量與討論都還很薄。授權條款是完整的 MIT 授權條款全文，但著作權人欄位還留著模板字樣沒有填，年份寫 2025，對得上它在 2025 年以 AWS S3 Browser 名義發布 1.0.0 的那段前史。名字也改過兩次，從 AWS S3 Browser 到 S3 Scout 再到 Hoistbay，中間還換過一次 bundle identifier，舊版儲存的 profile 會失效、需要重建。早期的修補紀錄也看得出年輕專案的常態，v1.1.0 修過資料夾上傳漏掉頂層檔案的問題，也修過刪除物件時明明被拒絕卻顯示成功的回報錯誤。一個還在找定位的年輕專案，功能判斷可以現在就做，長期穩定性的判斷只能交給時間。

誰該現在裝，誰先觀望

適合的輪廓相當明確：網站放在 Amazon S3、前面掛 CloudFront，更新方式仍靠手動換檔案的開發者與站長。想把上傳標頭、快取清除這些瑣事從 Console 的層層點擊裡拿出來，它確實有價值；喜歡把常用工具收進單一視窗的 Mac 使用者（類似我們日前介紹過的開發者工具箱 DevHub 那類訴求），會懂它的定位。前提是願意按上面的方式，先給它一組最小權限的測試環境。

先觀望的情境：主要用 R2、MinIO、Wasabi 的人，它現在幫不上；公司帳號綁 SSO 的團隊，等官方支援再說；已經把上傳、標頭、失效請求全部寫進 GitHub Actions 或其他 CI 的團隊，GUI 能再給的價值剩不多。自動化流程跑起來不用人盯，GUI 的意義本來就是給還沒自動化、或臨時要手動救火的人，兩者是分工不是替代。另外，如果你的需求其實是監控影像那類持續上傳到雲端儲存的場景，那是另一種工具的領域，可以參考我們介紹過的 CameraFTP 相機照片雲端上傳。

想試的話，先把信任前提處理好：安裝包沒有簽章，就別直接給它日常在用的金鑰，建一組只掛必要權限的 IAM 使用者、接一個測試 bucket，把上傳、Header 規則、失效請求各跑一輪，都符合預期再談正式環境。