VPSにDockerでChatwootをセルフホストする方法

構築するもの

VPS で Chatwoot をセルフホストするには、4 つのコンテナを実行します。Rails の Web プロセス、Sidekiq のバックグラウンドワーカー、pgvector 拡張機能を有効にした PostgreSQL、Redis です。Chatwoot はオープンソースのカスタマーサポートデスクです。そのため、自分で管理するサーバー上に、チームで共有する受信トレイと Web サイト用のチャットウィジェットを用意できます。インストールには約 20 分かかります。その後のメール配信、バックアップ、アップグレード、リソースのサイジングが、1 年後も稼働し続けるかどうかを左右します。

各コンテナには 1 つの役割があります。Rails はエージェント用ダッシュボードとウィジェット API（application programming interface）を提供します。Sidekiq は、メール送信、接続済みチャネルのポーリング、自動化ルールの実行、レポートの生成など、時間のかかる処理を実行します。Postgres は、会話、連絡先、エージェントアカウント、ダッシュボードで変更したすべての設定を保持します。Redis は Sidekiq のキューと、開いているダッシュボードにページを再読み込みせず新しいメッセージを配信する ActionCable の pub/sub チャネルを保持します。ここで Redis は一時的なキャッシュではありません。Redis を失うと、キュー内のジョブも失われるためです。

upstream の compose ファイルで使用されている Postgres イメージは、標準の postgres イメージではなく pgvector/pgvector:pg16 です。Chatwoot のスキーマが AI 機能用に vector 拡張機能を有効にするためです。標準の Postgres に置き換えると、拡張機能の control file がそのイメージに存在しないため、最初のデータベース起動が ERROR: extension "vector" is not available で停止します。upstream がリリースしているイメージを使用してください。

このガイドでは、Docker とリバースプロキシがすでにサーバー上で動作していることを前提にします。動作していない場合は、まず VPS 上の Docker Compose を参照してから戻ってきてください。

自己ホスト型 Chatwoot に必要な VPS の容量

2026 年 8 月時点で、上流の要件ページでは最小構成として 4 GB の RAM と 4 CPU コアを求めており、1 日あたり最大 10,000 件の会話に対応するとしています。8 GB と 8 コアの構成は、1 日あたり最大 20,000 件です。また、少なくとも 1 GB の swap も必要です。理由も明記されており、アップグレード中にマシンのメモリが枯渇しないようにするためです。ファイルアップロードを除き、Postgres 用に 5 GB から 10 GB のディスク容量を見込んでください。

ここからは率直に説明します。2 GB の VPS でも Chatwoot は起動し、エージェントが 2 人で受信トレイの利用が少なければ問題なく動作します。しかし、2 つの場面で停止します。1 つ目は Sidekiq です。上流の測定では、負荷の高いサーバーで 1 GB を超えるメモリを使用します。そのため、メールの集中やレポート処理が発生すると、Rails、Postgres、Redis が必要なメモリを確保する前に、サーバーのメモリ容量を超えます。2 つ目はアップグレードです。db:chatwoot_prepare はマイグレーションを適用するために新しい Rails プロセスを起動します。このイメージでは、実際の処理を始める前の Rails 起動だけで数百 MB のメモリを使用します。

事前に丁寧な警告が表示されることはありません。カーネルの OOM Killer が最大のプロセスに SIGKILL を送信し、Docker がコンテナの終了を検知して、restart: always が再起動します。docker compose ps には、コンテナが Exited (137) に戻り続ける状態が表示されます。137 は signal 9 による強制終了を示します。sudo dmesg -T | grep -i "killed process" を実行すると、カーネルが終了させたプロセスを確認できます。

4 GB が予算を超える場合は、2 GB のサーバーに 2 GB の swap を設定してください。負荷時の応答時間が悪化しても、サービスが完全に停止するよりはよいと判断する構成です。どちらの場合も、サービスごとにハードメモリ上限を設定する価値があります。これにより、worker がデータベースまで停止させる事態を防げます。Docker Compose のメモリ制限を参照してください。

ファイルアップロードは、設定した上限なしに増え続ける部分です。顧客が添付したスクリーンショットはすべてストレージボリュームに保存され、そのまま残ります。そのため、ディスクを使い切った原因がデータベースだと決めつけず、docker system df -v を監視してください。

Compose ファイルを取得し、バージョンタグを固定する

mkdir -p ~/chatwoot && cd ~/chatwoot
wget -O .env https://raw.githubusercontent.com/chatwoot/chatwoot/develop/.env.example
wget -O docker-compose.yaml https://raw.githubusercontent.com/chatwoot/chatwoot/develop/docker-compose.production.yaml
chmod 600 .env

ダウンロードしたファイルには image: chatwoot/chatwoot:latest と記載されています。ほかの作業を行う前に、この値を変更してください。

services:
  base: &base
    image: chatwoot/chatwoot:v4.16.2
    env_file: .env
    volumes:
      - storage_data:/app/storage

latest は、次の docker compose pull の実行時に、その朝公開されたバージョンを取得します。そのバージョンには、確認していないマイナーバージョンやメジャーバージョンへの変更と、それに伴うマイグレーションが含まれる場合があります。Chatwoot のマイグレーションは、実際の運用上、元に戻せません。そのため、意図しないバージョン更新が発生した場合は、取り消しではなくバックアップからの復元が必要です。タグを固定し、意図的に変更してください。v4.16.2 は 2026 年 8 月時点の現行リリースです。現在固定すべきタグは、リリースページで確認してください。

base サービスは YAML アンカーです。rails と sidekiq がこのアンカーをマージしているため、1 か所でタグを変更すると両方に反映されます。ファイルを開いたついでに、先頭にある version: '3' の行を削除してください。最新の Compose はこの行を無視し、コマンドを実行するたびに the attribute 'version' is obsolete, it will be ignored と表示します。

.env ファイルを入力する

まず Secret を生成します。Upstream は英数字の値を求めています。値が shell や YAML パーサーを通る際に、特殊文字が正しく処理されないためです。

head /dev/urandom | tr -dc A-Za-z0-9 | head -c 63 ; echo ''

次に、.env で次のキーを設定します。

SECRET_KEY_BASE=<the 63 characters you just generated>
FRONTEND_URL=https://support.example.com
FORCE_SSL=true
DEFAULT_LOCALE=en
ENABLE_ACCOUNT_SIGNUP=true

POSTGRES_HOST=postgres
POSTGRES_USERNAME=postgres
POSTGRES_PASSWORD=<long random string>
POSTGRES_DATABASE=chatwoot

REDIS_URL=redis://redis:6379
REDIS_PASSWORD=<a different long random string>

RAILS_ENV=production
INSTALLATION_ENV=docker
ACTIVE_STORAGE_SERVICE=local

POSTGRES_HOST=postgres と redis://redis:6379 は Compose のサービス名です。プロジェクトのデフォルトネットワーク上で名前解決されます。FRONTEND_URL は単なる表示用の値ではありません。Chatwoot はこの値からウィジェットのスクリプト URL と、送信メール内のすべてのリンクを生成します。そのため、誤った値を設定すると、応答しないホストを指すパスワードリセットリンクが生成されます。

ここで、Upstream のファイルにある落とし穴を確認します。postgres サービスは .env を読みません。独自の environment ブロックを持ち、POSTGRES_PASSWORD= は空のままです。そのため、.env だけにパスワードを設定すると、データベースにはパスワードが設定されず、アプリケーションにだけパスワードが設定されます。サービスから同じ変数を参照するようにします。

  postgres:
    image: pgvector/pgvector:pg16
    restart: always
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=chatwoot
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}

Compose はプロジェクトディレクトリの .env を読み込み、${...} の置換に使用します。これで両方に同じ文字列が渡されます。ここを誤ると、Rails は PG::ConnectionBad: FATAL: password authentication failed for user "postgres" で停止します。

ほとんどの人が驚く動作が 1 つあります。Postgres イメージが POSTGRES_PASSWORD を適用するのは、空のデータディレクトリを初期化するときだけです。後から値を変更しても効果はありません。initdb は 2 回目には実行されないためです。すでにスタックを 1 回起動している場合は、データベース内で値を変更してください。

docker compose exec postgres psql -U postgres -c "ALTER USER postgres WITH PASSWORD 'the-new-password';"

ENABLE_ACCOUNT_SIGNUP=true は一時的な設定です。最初のアカウントを作成できるように、公開された登録フォームを開きます。アカウントを作成したら、false に設定して、すぐに docker compose up -d を再度実行してください。URL を見つけた人なら誰でも、サポート窓口に登録できてしまいます。以後、エージェントは招待によって追加され、パスワードはこのアプリ内だけで管理されます。これは、サービスが半ダースほどに増え、各サービスで別々のアカウント一覧を管理することに疲れるまでは問題ありません。その段階では、Authentik のような自己ホスト型の ID プロバイダーが、それらを置き換える役割を果たします。

.env には、このスタックが使用するすべての Secret が平文で保存されます。そのため、mode 600 に設定し、git の管理対象外にしてください。Compose が env ファイルを読み込む方法と Secret が漏えいする場所では、env_file と environment の違いを含め、注意すべき点を説明しています。

既存の Traefik の背後に Chatwoot を配置する

1 つのアプリケーションに 2 つ目のリバースプロキシを構築しないでください。このサーバー上の他のコンテナで Traefik がすでに TLS (transport layer security) を終端している場合、Chatwoot はラベルブロックを追加してその構成に参加させます。まだ Traefik を導入していない場合は、複数の Docker Compose アプリケーションの前段に Traefik を配置する の手順で一度設定してから、ここに戻ってください。

上流の docker-compose.yaml は後で新しいコピーとの差分を確認できるよう、できるだけ元の構成に近い状態に保ち、変更内容は override ファイルに記述してください。Compose は docker-compose.override.yaml を自動的にマージします。マージ規則については、Compose を複数のファイルに分割する で説明しています。

services:
  rails:
    networks:
      - default
      - proxy
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.chatwoot.rule=Host(`support.example.com`)"
      - "traefik.http.routers.chatwoot.entrypoints=websecure"
      - "traefik.http.routers.chatwoot.tls.certresolver=letsencrypt"
      - "traefik.http.services.chatwoot.loadbalancer.server.port=3000"

networks:
  proxy:
    external: true

entrypoint と certresolver には独自の名前を使用してください。コンテナは Traefik と同じ Docker ネットワークに接続する必要があります。これを指定するのが proxy の設定です。また、default にも接続したままにしてください。そうしないと Postgres と Redis を利用できなくなります。後者の行は忘れられがちです。

ports: ブロックは変更しないでください。上流の構成ではこれが 127.0.0.1:3000 にバインドされます。これは loopback 専用なので、インターネットから到達できません。また、curl -I http://127.0.0.1:3000 を使えばサーバー内部からテストできるため、そのまま役立ちます。

エージェントダッシュボードは、ライブメッセージ配信のために /cable への websocket 接続を維持します。Traefik は追加設定なしで HTTP upgrade を転送するため、何も追加する必要はありません。後から CDN や別のプロキシを Traefik の前段に配置する場合は、そこで websockets を許可してください。許可しないと、ダッシュボードは正常に読み込まれる一方で、新しいメッセージが手動で更新するまで表示されない症状が発生します。

データベースを初期化してスタックを起動する

最初にデータサービスを起動し、Postgres の初回起動が完了するまで待ちます。

docker compose up -d postgres redis
docker compose logs postgres | tail -n 5

database system is ready to accept connections になるまで待ちます。その後、スキーマを作成します。

docker compose run --rm rails bundle exec rails db:chatwoot_prepare

これにより、データベースが存在しない場合は作成され、その後にスキーマとデフォルトのシードデータが読み込まれます。マイグレーションの行が出力され、正常に終了します。postgres:5432 - no response を出力し続ける場合、エントリポイントはまだ接続を受け付けていないデータベースを待機しています。初回起動では、通常 initdb が処理中であることを意味します。待機して Postgres のログを確認し、その後もう一度実行します。vector 拡張機能の箇所で停止する場合は、pgvector イメージを標準の Postgres に置き換えています。

docker compose up -d
docker compose ps
docker compose logs --tail 30 rails

4 つすべてのコンテナが Up になり、rails のログの末尾が http://0.0.0.0:3000 を待ち受ける Puma の行になっていることを確認します。次に、公開パスを確認します。

curl -sI https://support.example.com | head -n 1

HTTP/2 200 であれば、チェーン全体が正常に動作しています。Traefik から 404 が返る場合は、ルーターのルールが一致していません。通常はホスト名の入力ミスが原因です。502 が返る場合は、Traefik がルーターに一致したものの、コンテナに接続できていません。ほとんどの場合、proxy ネットワークがないか、loadbalancer.server.port が 3000 ではありません。

URL を開き、/app/auth/signup でアカウントを作成します。その後、ENABLE_ACCOUNT_SIGNUP=false を設定し、docker compose up -d を実行してフォームを閉じます。

パスワードリセットとメールのやり取りが SMTP なしで失敗する理由

SMTP（simple mail transfer protocol）の設定がない Chatwoot は、メールを送信できないサポートデスクです。影響は通知だけにとどまりません。パスワードリセットが機能しなくなるため、管理者がロックアウトされると復旧できません。エージェントへの招待も機能しません。招待はメールで送信されるためです。メールでの顧客とのやり取りに返信できなくなるため、会話が一方向になります。この設定は省略されがちですが、最も困る時期になってから問題に気付くことになります。

仕組みは単純です。SMTP 設定がない場合、ActionMailer はデフォルトの localhost、ポート 25 への配送を続けます。Rails コンテナ内にはメールサーバーがないため、配送ジョブが Errno::ECONNREFUSED: Connection refused - connect(2) for "localhost" port 25 を発生させます。メールはバックグラウンドジョブから送信されるため、この行は Sidekiq のログに記録され、Rails のログには記録されません。一方、「パスワードを忘れた場合」をクリックした人には成功を示すメッセージが表示されますが、メールは届きません。

MAILER_SENDER_EMAIL=Support <support@example.com>
SMTP_DOMAIN=example.com
SMTP_ADDRESS=smtp.example.com
SMTP_PORT=587
SMTP_USERNAME=support@example.com
SMTP_PASSWORD=<the relay password>
SMTP_AUTHENTICATION=plain
SMTP_ENABLE_STARTTLS_AUTO=true

STARTTLS を使用するポート 587 を使います。STARTTLS は平文で接続を開始し、認証前に暗号化へ切り替えます。スパム対策として、多くの VPS プロバイダーは送信ポート 25 をブロックします。そのため、通常はポート 587 のリレーでなければ接続できません。SMTP_DOMAIN は、SMTP の通信中にサーバーが通知するドメインです。値が一致しないと、一部のリレーは接続を拒否します。

設定を適用し、ワーカーを監視します。

docker compose up -d rails sidekiq
docker compose logs -f sidekiq

ログインページからパスワードリセットを実行します。配送が正常に動作すると、Sidekiq のログでメーラージョブが正常終了します。失敗すると例外クラスが表示され、その後 Sidekiq が待機時間を延ばしながら再試行します。そのため、壊れたリレーでは同じエラーが数時間にわたって数分おきに発生します。

よくある拒否は2種類あります。どちらも Chatwoot のバグではありません。535 Authentication failed は、そのリレーに対するユーザー名またはパスワードが正しくないことを示します。多くのプロバイダーでは、アカウントのパスワードではなくアプリケーションパスワードが必要です。550 Sender address rejected は、MAILER_SENDER_EMAIL がリレーから送信を許可されていないアドレスであることを示します。そのため、プロバイダーで確認済みのメールボックスまたはドメインを指定する必要があります。

会話へのメール受信は別の処理です。MAILER_INBOUND_EMAIL_DOMAIN と RAILS_INBOUND_EMAIL_SERVICE に加えて、受信メッセージを Chatwoot に渡すメールサーバーが必要です。最短の方法は、リレーを借りることです。メール経路全体を自分で管理する場合は、Mailcow で独自のメールサーバーを運用する方法で、その運用に必要な作業を確認できます。

バックアップ対象とリストアの検証方法

Chatwoot のバックアップには 4 つの要素があります。どれか 1 つでも省くと、リストアではなく再構築になります。

• 会話、連絡先、エージェントアカウント、すべての設定を保持する Postgres データベース。
• storage_data ボリューム。ACTIVE_STORAGE_SERVICE=local はアップロードファイルをディスクに書き込み、Postgres には参照行だけを保持するためです。
• .env ファイル。SECRET_KEY_BASE と ACTIVE_RECORD_ENCRYPTION_* のキーを保持するためです。
• compose ファイル。データベーススキーマと一致する正確なイメージタグを記録しているためです。

データベースだけをリストアすると、すべての会話は戻りますが、添付ファイルは壊れます。行が、ディスク上に存在しなくなったファイルを指すためです。

cd ~/chatwoot
docker compose exec -T postgres pg_dump -U postgres -Fc chatwoot > db-$(date +%F).dump

-T は重要です。これを指定しないと Compose が疑似端末を割り当て、ストリーム内の改行バイトを書き換えます。その結果、pg_restore が拒否するダンプファイルになります。-Fc はカスタム形式です。圧縮でき、pg_restore で選択的に処理できます。

docker run --rm -v chatwoot_storage_data:/data:ro -v "$PWD":/backup alpine \
  tar czf /backup/storage-$(date +%F).tgz -C /data .

ボリューム名は、プロジェクトディレクトリ名に _storage_data を加えたものです。コマンドを信頼する前に docker volume ls | grep storage_data で確認してください。存在しない名前を指定しても、Docker は失敗せず空のボリュームを作成するためです。有効な空のアーカイブが作成され、エラーも発生しません。作成後に ls -lh storage-*.tgz でサイズを確認してください。

これで両方のファイルが、保護対象と同じディスク上に置かれます。これでは何も保護できません。サーバー外へ転送して暗号化してください。データベースダンプには、すべての顧客メッセージが平文で含まれるためです。restic による暗号化したオフサイトバックアップでは、スケジュール設定と保持期間について説明しています。

docker compose up -d postgres
docker compose exec -T postgres pg_restore -U postgres -d chatwoot --clean --if-exists < db-2026-08-10.dump
docker run --rm -v chatwoot_storage_data:/data -v "$PWD":/backup alpine \
  sh -c 'rm -rf /data/* && tar xzf /backup/storage-2026-08-10.tgz -C /data'
docker compose up -d

Chatwoot を新しいタグにアップグレードする方法

コマンドの順序が重要です。

1. 現在のタグから対象のタグまでのリリースノートを読み、手動で必要な作業を確認します。
2. 最新のデータベースダンプとストレージアーカイブを作成し、どちらもファイルサイズが妥当であることを確認します。
3. docker-compose.yaml にある base サービスのイメージタグを編集します。
4. 新しいイメージを取得し、スタックを停止してマイグレーションを実行し、その後もう一度起動します。

docker compose pull
docker compose down
docker compose run --rm rails bundle exec rails db:chatwoot_prepare
docker compose up -d
docker compose images

マイグレーションの前にイメージを取得します。マイグレーションは新しいイメージから実行する必要があるためです。古いイメージには新しいマイグレーションファイルが含まれていません。マイグレーションの前にスタックを停止します。古いコードと新しいスキーマには互換性がないため、古い Rails プロセスを実行したままにするとエラーが発生したり、新しいスキーマで受け付けられない行を書き込んだりする可能性があります。停止するとマイグレーションに必要なメモリも解放されます。これが upstream が swap を要求する理由です。

docker compose images は、各コンテナが実際に実行しているタグを表示します。タグを編集したものの、イメージの取得を忘れた場合も検出できます。

多数のバージョンを一度にまたがって更新しないでください。古いインストール環境について、upstream は中間タグを順に適用するよう案内しています。マイグレーションはベーススキーマに統合されると削除されるため、非常に古いデータベースでは先に進む経路がなくなる可能性があります。1 回につき 1 つのマイナーバージョンだけ進め、各バージョンの後に prepare ステップを実行します。

マイグレーションを実行する前に Rails が起動すると、サービス提供を拒否し、ActiveRecord::PendingMigrationError: Migrations are pending をログに記録します。restart: always が設定されている場合、コンテナは再起動を繰り返すため、docker compose ps では数秒ごとにリセットされる稼働時間が表示されます。prepare ステップを実行すると、この状態は解消されます。

ロールバックするには、古いタグに戻してダンプをリストアします。信頼できる逆方向のマイグレーション経路はありません。そのために手順 2 を実行します。

障害パターンと表示される文字列

Traefik から 502 Bad Gateway が返る。 ルーターは一致しましたが、バックエンドが応答していません。docker compose ps で rails が Up と表示されることを確認し、docker network inspect proxy を実行して、コンテナ一覧に rails コンテナが表示されることを確認します。接続されていないコンテナは Traefik から認識できません。そのため、リクエストはルーターに一致した後、転送先がなくなります。

ダッシュボードは読み込まれるが、新しいメッセージの表示に更新が必要になる。 /cable への websocket 接続が通っていないか、FRONTEND_URL がブラウザのアドレスバーに表示されているアドレスと一致していません。不一致があると、ページは別の origin への websocket 接続を開こうとします。ブラウザはこれをブロックします。

FATAL: password authentication failed for user "postgres"。 .env に設定したパスワードと、Postgres のデータボリュームに保存されたパスワードが異なります。実行中のコンテナ内で ALTER USER を実行して修正します。.env を再度編集しても、初期化済みのデータベースは変更されません。

NOAUTH Authentication required. Redis は --requirepass を指定して実行されていますが、アプリケーションはパスワードなしで接続しました。そのため、.env に REDIS_PASSWORD がないか、読み込まれていません。docker compose exec redis redis-cli -a "$REDIS_PASSWORD" ping で直接テストします。PONG が返れば正常です。

コンテナが終了コード 137 で終了する。 これは SIGKILL です。小規模なサーバーでは、kernel の out of memory killer が原因です。swap を追加するか、サービスごとにメモリ制限を設定するか、より大きなプランへ移行します。

FAQ

自己ホスト型 Chatwoot VPS にはどの程度の RAM が必要ですか？

2026 年 8 月時点で、upstream が求めている最小構成は RAM 4 GB、CPU 4 コアで、1 日最大 10,000 件の会話に対応します。最大 20,000 件の場合は RAM 8 GB、CPU 8 コアが必要です。少なくとも 1 GB の swap も追加してください。アップグレード時には、マイグレーションを適用するために Rails プロセスが 2 つ目に起動し、その時点で小規模な VPS はメモリ不足になりやすいためです。RAM 2 GB の VPS でも、エージェント数名であれば起動して動作します。ただし、負荷がかかると Sidekiq だけで 1 GB を超えることがあります。そのため、繁忙時やアップグレード中に、コンテナが終了コード 137 で kill されることを想定してください。

Chatwoot のパスワードリセットメールが届かないのはなぜですか？

SMTP 設定がないためです。ActionMailer は localhost の port 25 に配信しようとしますが、コンテナ内にメールサーバーがありません。ブラウザーには成功メッセージが表示されたまま、ジョブは Sidekiq で Errno::ECONNREFUSED: Connection refused - connect(2) for "localhost" port 25 により失敗します。.env に SMTP_ADDRESS、SMTP_PORT、SMTP_USERNAME、SMTP_PASSWORD、MAILER_SENDER_EMAIL を設定し、rails と sidekiq のサービスを再起動してください。その後、リセットを実行しながら docker compose logs -f sidekiq を監視します。

Chatwoot を復元するには何をバックアップする必要がありますか？

Postgres データベース、storage_data Docker volume、.env file、compose files をバックアップします。データベースだけでは不十分です。アップロードされたファイルは volume に保存され、Postgres にはそれらへの参照だけが保存されるためです。データベースだけを復元すると、添付ファイルが壊れた会話になります。.env も重要です。別の SECRET_KEY_BASE ではすべてのユーザーがサインアウトされ、別の ACTIVE_RECORD_ENCRYPTION_* keys では暗号化されたカラムを読み取れなくなるためです。

データベースを壊さずに Chatwoot をアップグレードするにはどうすればよいですか？

バックアップを取得し、compose file の image tag を変更してから、docker compose pull、docker compose down、docker compose run --rm rails bundle exec rails db:chatwoot_prepare、docker compose up -d を実行します。マイグレーションは新しい image から実行する必要があるため、最初に pull してください。古いコードが新しい schema に対して動作するとエラーになるため、最初に stack を停止してください。古いインストール環境では、minor version を一度に 1 つずつ上げます。マイグレーションは base schema に統合されると削除されるためです。

pgvector の代わりに標準の postgres image を使用できますか？

いいえ。Chatwoot の schema は vector extension を有効にするため、標準の postgres image は db:chatwoot_prepare 中に ERROR: extension "vector" is not available で失敗します。その image に extension の control file が存在しないためです。upstream の compose file にある pgvector/pgvector:pg16 を使用するか、Postgres の major version に対応する pgvector を含む別の image を使用してください。