從 Git 部署
把 Compose 或 Kubernetes manifest 放在 Git，Portainer 依儲存庫內容部署。這樣「真正的設定」在版本庫裡，而不是只活在瀏覽器編輯器。業界常稱這類做法為 GitOps（以 Git 為真實來源的營運方式）。
官方 Stack 文件裡的 Git 選項：Add a new stack。
基本流程（Docker Stack）
- Stacks → Add stack → Git repository。
- 填儲存庫 URL、分支（reference）、Compose 檔相對路徑（例如
compose.yaml）。 - 私有儲存庫要提供認證。Business Edition 可把 Git 憑證存成共用來源，較少每次重貼個人 token。
- Deploy。Portainer 會 clone 並交給 Docker Compose／stack 引擎。
之後改 Git 裡的 YAML 並 push，若沒開自動更新，Portainer 不會自己重佈——要手動再拉一次。這是和「在 Web editor 改完按 Deploy」最大的差別：來源改成 Git 以後，請改 Git，不要再在 UI 裡改出一份對不上儲存庫的版本。
GitOps 自動更新
開啟 GitOps updates 之後，Portainer 會依設定對齊遠端：
| 機制 | 行為 |
|---|---|
| Polling | 每隔一段時間去問 Git 有沒有新 commit |
| Webhook | 你在 Git 主機（例如 GitHub）設 Webhook，push 立刻通知 Portainer |
常見配套選項：
- Re-pull image：更新時一律拉最新映像，類似
--pull=always。標籤是latest時才明顯；用消化過的版本標籤（digest 或1.2.3）較可預期。 - Force redeployment：即使 Git 沒變也定期重佈，用來強制本機手動改過的狀態回到 Git。
完整自動更新、變更時段（change windows）、相對路徑 Volume 等，以 Business Edition 較完整。CE 仍可從 Git 部署，自動對齊能力較受限。以你畫面上實際出現的開關為準。
環境變數不要進 Git
密碼、API 金鑰放在 Portainer 的 Stack 環境變數（或密鑰機制），YAML 只留 ${POSTGRES_PASSWORD}。這樣儲存庫可以公開或給較多人讀，也不必為了改密碼而 commit。
和 Argo CD、Flux 的關係
Portainer 的 Git 部署對 Docker Compose 與「想少碰 CLI 的叢集」很實用。大型 Kubernetes 平台若已用 Argo CD 或 Flux，不必為了 Portainer 拆掉它們；可以並存，或讓 Portainer 只管 Docker／Edge，叢集 GitOps 仍走專用工具。