Dockerコンテナの更新は自動化するか手動にするか：Watchtowerの使いどころと戻し方

先に結論です。自宅サーバーのコンテナ更新は、全部自動か全部手動かではなく、コンテナごとに分ける のが現実的です。壊れても困らない・設定が単純なものだけ Watchtower で自動更新し、データベースや写真・パスワード管理のように「壊れると困る」ものは 通知だけ受けて手動で上げる 形にします。そして、どちらの場合も 前のイメージに戻す手順を先に決めておく ことが一番大事です。

なお、Watchtower の元のリポジトリ（containrrr/watchtower）は 2025 年 12 月にアーカイブされ、更新が止まっています。これから使うなら、コミュニティのフォーク版（nickfedor/watchtower）を使うのが一般的とされています。この記事の設定例もフォーク版のイメージ名で書いています。

Watchtowerは何をするツールか

Watchtower は、動いているコンテナのイメージに新しい版が出ていないかを定期的に確認し、新しい版があれば pull → 停止 → 同じ設定で作り直し までを自動で行うツールです。Docker のソケット（/var/run/docker.sock）をマウントして動きます。

便利な反面、次の点は理解しておく必要があります。

• タグの中身が変わったら更新される：latest のような動くタグを使っていると、メジャーバージョンが上がった版でも入ってきます
• データの移行はしてくれない：アプリ側で設定やデータベースの移行が必要な更新でも、Watchtower はイメージを差し替えるだけです
• Docker ソケットを渡す＝ほぼ root 権限を渡す：Watchtower 自体が乗っ取られると、ホスト全体に影響します。信頼できるイメージを使うことが前提です

また、元の containrrr 版のイメージは、Docker Engine 29 以降で「API バージョンが古すぎる」というエラーで動かなくなった報告が多く出ています。今 containrrr 版を使っていて「最近更新されていない気がする」という人は、ログを確認してみてください。

自動更新してよいコンテナ・手動にすべきコンテナ

私は「壊れたときに何が起きるか」と「戻すのにどれだけ手間がかかるか」で分けるのがよいと考えています。

自動更新に向くもの

• Uptime Kuma、ダッシュボード系（Homepage など）、AdGuard Home のように、設定が少なく、壊れても作り直しが簡単なもの
• 外部に公開していて、セキュリティ修正を早く入れたいもの（ただしバックアップ前提）

手動にしたほうがよいもの

• データベース（PostgreSQL・MariaDB など）：メジャーバージョンをまたぐとデータの移行作業が必要になり、イメージを差し替えるだけでは起動しなくなります
• Immich・Nextcloud・Vaultwarden など、家族のデータが入っているアプリ：更新内容にリリースノートで手順が書かれていることがあり、読んでから上げたいものです。アプリによっては公式ドキュメントで自動更新を推奨しないとしているものもあります
• Home Assistant：統合の仕様変更で、自動化が動かなくなることがあります
• リバースプロキシ（Nginx Proxy Manager など）：止まると全サービスに繋がらなくなります

迷ったら手動側に入れておき、慣れてきたら自動に移すほうが安全です。

Docker Composeでの設定：自動の対象を絞り、残りは通知だけにする

Watchtower は、何も指定しないと すべてのコンテナ を更新対象にします。まず「ラベルを付けたものだけ」に絞ります。

services:
  watchtower:
    image: nickfedor/watchtower
    container_name: watchtower
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - TZ=Asia/Tokyo
      - WATCHTOWER_SCHEDULE=0 0 4 * * *   # 毎日4時（秒から始まる6項目）
      - WATCHTOWER_LABEL_ENABLE=true      # ラベルを付けたコンテナだけ対象
      - WATCHTOWER_CLEANUP=false          # 古いイメージを残す（戻すため）

自動更新したいコンテナには、ラベルを付けます。

  uptime-kuma:
    image: louislam/uptime-kuma:1
    labels:
      - com.centurylinklabs.watchtower.enable=true

手動にしたいコンテナでも「新しい版が出たこと」は知りたいはずです。その場合は、ラベルを付けたうえで 監視だけ にします。

  immich-server:
    labels:
      - com.centurylinklabs.watchtower.enable=true
      - com.centurylinklabs.watchtower.monitor-only=true

通知先は WATCHTOWER_NOTIFICATION_URL に、Discord や Telegram、メールなどの URL 形式（shoutrrr 形式）で指定できるとされています。通知が来たらリリースノートを読み、自分のタイミングで手動更新します。

設定項目の名前はフォーク版でも基本的に同じとされていますが、版によって変わる可能性があるため、使う版のドキュメントで一度確認してください。

更新で壊れたときの戻し方

自動でも手動でも、戻し方を決めていないと更新は怖いままです。やることは 3 つです。

1. タグを固定しておく

latest ではなく、1 や 2.5 のように メジャーバージョンを含むタグ を指定します。こうしておくと、自動更新でもメジャーバージョンアップは入ってきません。

2. 更新前のイメージを分かるようにしておく

WATCHTOWER_CLEANUP=false にしておけば、古いイメージはディスクに残ります。手動で上げる前には、今動いているイメージを控えておきます。

docker inspect --format '{{.Config.Image}} {{.Image}}' immich-server
docker image ls --digests

3. 前の版に戻す

compose ファイルの image: を前のタグ（または控えた @sha256:... のダイジェスト）に書き換えて、作り直します。

docker compose up -d immich-server

ただし、新しい版がデータベースの形式を書き換えた後だと、イメージを戻しても動かない ことがあります。データを持つアプリは、更新前にボリュームのバックアップを取っておくのが前提です。バックアップ先には、NAS か外付けの HDD を用意しておくと手順が単純になります。外付けHDD（バックアップ用）

古いイメージを残し続けるとディスクを圧迫するので、更新が落ち着いたら月 1 回くらい docker image prune で整理します。

手動更新を楽にする小さな工夫

手動にすると「面倒で放置してしまう」のが一番の問題です。次のようにすると続けやすくなります。

• 更新日を決める：月 1 回、通知が溜まったコンテナをまとめて上げる
• コマンドを固定する：docker compose pull <サービス名> → docker compose up -d <サービス名> の 2 行だけにしておく
• 上げた後に確認する場所を決める：Uptime Kuma などで死活監視をしておけば、更新後に落ちたことにすぐ気付けます

まとめ

• 更新はコンテナごとに分ける。設定が単純なものだけ自動、データを持つものは通知だけにして手動で上げる
• Watchtower は元のリポジトリがアーカイブ済み。使うならフォーク版を選び、WATCHTOWER_LABEL_ENABLE で対象を絞る
• タグはメジャーバージョンまで固定し、古いイメージを残して、前のタグに戻せるようにしておく
• データベースを含むアプリは、更新前にボリュームのバックアップを取ってから上げる

運営者が作った Excel テンプレートを BOOTH で配布しています。IT 資産管理台帳（無料 Lite 版あり） / IT 資格の学習管理シート