【保存版】Difyのバージョンアップに備える!VPS上のDockerコンテナ運用・バックアップ術【2026年版】

Difyのバージョンアップに備える!VPS上のDockerコンテナ運用・バックアップ術


【結論】バックアップの仕組みを先に作る。アップデートはその後。

はっきり書いておきます。

Difyをセルフホストで使い続けるなら、バックアップの自動化は「いつかやろう」じゃなくて初日にやることです。

アップデートで詰んだ、という話はDifyコミュニティでも定期的に出てきます。自分もDify以外のDocker運用で「git pullしたら設定が吹っ飛んだ」という経験があるので、まったく他人事じゃない。

この記事で伝えたいのはたった一つで、「cron1行仕込んでおくだけで毎日自動バックアップができる」ということです。難しくないので、Difyを立ち上げたその日にやってしまってください。


なぜバックアップが重要なのか

Difyをセルフホストしていると、アップデートやサーバートラブルでデータを失うリスクがあります。特に以下のデータは失うと復旧が困難です:

  • チャットボットの設定・プロンプト
  • RAGに登録したドキュメント
  • ユーザーアカウント情報
  • 会話履歴

正直に言うと、チャットボットの設定やRAGのドキュメントは「もう一度作ればいい」ではすまない量になってきます。試行錯誤して育てたプロンプトを全ロストするのはかなりきつい。

「まぁ最悪作り直せばいいか」と思えるうちはまだいいんですが、RAGにドキュメントを積み上げて使い込んでくると、それが段々通用しなくなってくる。だから定期バックアップの仕組みを先に作る、これが鉄則です。


バックアップ手順

データベースのバックアップ

まずデータベース(PostgreSQL)のダンプ。これが一番大事なデータの塊です。

cd dify/docker
docker compose exec db pg_dump -U postgres dify > backup_$(date +%Y%m%d).sql

日付入りのファイル名で出力されるので、バックアップが溜まっていっても「どれが最新か」が一目でわかります。

ボリュームの一括バックアップ

DBダンプだけでは足りないケースもあります。RAGに登録した生ファイルなどはボリュームに入っているので、こちらも一緒に取っておくと安心です。

docker run --rm -v dify_data:/data -v $(pwd):/backup alpine \
  tar czf /backup/dify_volumes_$(date +%Y%m%d).tar.gz /data

自動バックアップ(cron設定)──ここが本命

正直、手動バックアップは絶対に忘れます。自分の経験上、「アップデートしようとした瞬間にバックアップを取ってなかったことに気づく」というパターンが一番多い。気づいたときには手遅れ、というのがいちばんまずい。

cron1行で毎日深夜3時に自動実行するようにしてしまいましょう。

crontab -e
# 毎日3時にバックアップ実行
0 3 * * * cd /root/dify/docker && docker compose exec -T db pg_dump -U postgres dify > /root/backups/dify_$(date +\%Y\%m\%d).sql

VPSで動かす最大のメリットがここで活きます。VPSはサーバーが24時間稼働しているので、cronがちゃんと動く

自分のPCでDifyを動かしている場合、深夜3時にPCが起きていないのでcronは実行されません。「VPSは必要か?」という話になったとき、「自動バックアップが確実に動く」という点だけでも十分な理由になると思っています。PCを立ち上げっぱなしにしておくというのも、精神的に気になるし、何かあったときにリモートで入らないといけなくて全然手放しにならない。それならVPSのほうがずっとラクです。


アップデート手順

cd dify/docker
docker compose down          # 停止
git pull origin main         # 最新コードを取得
docker compose up -d         # 再起動

手順自体はシンプルです。ただしアップデート前に必ずバックアップを取ること。これだけは絶対に守ってください。

自分の場合、アップデート作業の前には必ず手動でDBダンプを1回走らせます。cronが昨日動いていたとしても、「今日アップデートする直前」の状態が手元にない、というのは怖い。30秒でできるので、面倒がらずにやっておいて損はないです。


おすすめVPS

ここで少し選択の話をしておきます。

Dify用のVPSを選ぶとき、GPUは不要です。はっきり言っておきます。

DifyはAPIで外部のLLMを呼び出す構成なので、VPS側にGPUがある必要はまったくありません。「Dify用にGPU VPS」を推している記事があったら、正直アフィリエイト報酬目的で単価の高いプランに誘導しているだけだと思っていいです。GPU VPSは月数万かかるものもあって、Difyの用途では完全にオーバースペックです。

CPU・メモリのスペックが足りていれば十分で、月額の安さを重視して選んで問題ありません。

金額感で言うと、KAGOYAは月770円〜、XServerは月990円固定。Difyをずっと動かしておくなら固定料金のほうが「毎月いくらか計算しなくていい」ので精神的にラクという面はあります。一方でKAGOYAは時間課金なので、使い方によってはXServerより安く収まります。

損益分岐点の目安は月76時間以上使うならXServer、未満ならKAGOYA。Difyを常時稼働で使うなら76時間は余裕で超えるので、その場合はXServerの固定料金のほうが結果的に安くなります。

XServer VPS(月990円〜)→

KAGOYA CLOUD VPS(月770円〜)→


まとめ:あなたの使い方で選ぶ判断テーブル

状況判断
Difyを立ち上げたばかりまず今日中にcron設定。バックアップの仕組みを先に作る
アップデートしようとしている手動でDBダンプを1回走らせてから作業する。30秒でできる
自分のPCでDifyを動かしている深夜にcronが動かないので自動バックアップが機能しない。VPS移行を検討
GPUありのVPSを検討しているDify用途ではGPU不要。CPU・メモリで十分。GPU推しの記事は単価目的と思っていい
常時稼働で月76時間以上使うXServer(月990円固定)のほうがトータルで安くなる
使う時間が月76時間未満 or 試したいKAGOYA(月770円〜、時間課金)が安い。14日無料お試しもある

よくある質問(FAQ)

`cat backup.sql | docker compose exec -T db psql -U postgres dify` でデータベースを復元できます。ボリュームは `tar xzf` で展開後、Dockerを再起動します。

バックアップの設定、今日やってしまってください。

「ちゃんとファイルが生成されているか」を翌朝確認するだけで、かなり安心感が変わります。これが最終回答じゃないので、まず仕組みを作って動かしてみるのが一番です。設定してみて「なんか違うな」と思ったら直せばいい。やってみてから考えるほうが絶対に早いです。