先に結論
self-hosted Supabase で Logs Explorer を使っているなら、6月上旬の compose 更新前に docker-compose.logs.yml を足す運用へ変えたほうが安全です。
Supabase は 2026-06-03 週の self-hosted release から、analytics と vector を default の docker-compose.yml から外します。これ以後は通常の docker compose up -d だけだと logs 系 service が起動せず、Studio の Logs メニューも出ません。
逆に、Logs Explorer を使っていないなら慌てる必要はありません。更新後の stack は軽くなり、そのまま動かしてよい変更です。
誰が対象か
対象はかなり絞られます。
Supabase が明示しているのは、./docker 配下の self-hosted 構成を使い、upstream の compose 更新を取り込み、Studio の Logs Explorer を実際に使っているチームです。
managed platform は対象外です。supabase start を使うローカル開発も別の配布経路なので、今回の overlay 追加をそのまま受けるわけではありません。
すでに自前の compose override を持っているなら、単純な no-op では済まない場合があります。logs 系 service を残したいなら、その override が新しい docker-compose.logs.yml とどう重なるかを先に見ておくほうが安全です。
何が変わるのか
今回の主題は service の削除ではなく、default から opt-in へ移ることです。
upstream diff では analytics と vector が base の docker-compose.yml から外れ、新しく docker-compose.logs.yml に移りました。Logs Explorer を残したい環境だけが、この overlay を重ねて起動する形になります。
同時に Studio 側の base 設定では ENABLED_FEATURES_LOGS_ALL が false になります。つまり logs overlay を足さない限り、UI 側でも Logs メニューは隠れます。
狙いは明快です。Logflare と Vector は self-hosted の default stack としては重く、Studio、Auth、Storage、PostgREST、Realtime はそれなしでも動くため、既定を軽量化したいわけです。
Logs Explorer を使うなら何を変えるか
やることは大きく 2 つです。
まず docker-compose.logs.yml を overlay して起動します。
docker compose -f docker-compose.yml -f docker-compose.logs.yml up -dこれで analytics と vector が起動し、Studio 側でも Logs Explorer が戻ります。
もう1つ大事なのは、up だけ合わせて終わらないことです。down、logs、ps でも同じ compose set を使わないと、運用中に「見えている service」と「管理している service」がズレます。
毎回 -f を書きたくないなら、.env に次を入れる方法があります。
COMPOSE_FILE=docker-compose.yml:docker-compose.logs.ymlこの形なら compose 実行のたびに overlay を書き直さずに済みます。
Logs Explorer を使わないなら何もしなくてよい
Logs Explorer を使っていない self-hosted 環境は、今回かなり楽です。
compose を更新して通常どおり docker compose up -d を実行すれば、logs 系 service が外れた軽い stack へ移るだけです。Studio、Auth、Storage、PostgREST、Realtime はそのまま動きます。
止まった analytics と vector の container や volume は、stack が安定していると確認してから整理できます。ここは急いで削除するより、更新後の監視と障害調査の導線に問題がないかを見てからで十分です。
更新前に見ておきたいチェックリスト
更新前に見る順番は、次の 5 点で足ります。
- 本番が
./docker構成の self-hosted か - Studio の Logs Explorer を本当に使っているか
- compose の実行を wrapper script や Makefile で隠していないか
- logs overlay を
upだけでなくdownlogspsにも反映できるか - Logs Explorer をやめるなら、代わりの監視導線があるか
ここが見えていれば、6月上旬の更新で「Studio の Logs が消えた」「analytics が勝手に落ちた」と慌てにくくなります。
既存の self-hosted 変更と一緒に見たい記事
self-hosted Supabase を追っているなら、PG 17 default 化の記事 も続けて見ておくと楽です。6月中旬には DB image 側の変更も来るため、compose 更新をまとめて棚卸しできます。
Studio 側の権限変更まで追うなら、Studio role migration の記事 もつながります。Logs overlay と role migration は別件ですが、どちらも ./docker 構成の更新で踏みやすい差分です。
Supabase 自体を継続利用するかまで含めて見たいなら、backend 比較記事 もあります。ただ、今回すぐ見るべきなのは比較ではなく Logs Explorer を残すかどうかです。
まとめ
今回の変更で先に決めるべきなのは、Logs Explorer を残すか、軽い default stack に寄せるかです。
Logs Explorer を使うなら docker-compose.logs.yml を運用へ入れてください。使わないなら no-op でよく、更新後はむしろ stack が軽くなります。
self-hosted の Supabase は 6 月に compose まわりの変更が続きます。docker compose の呼び出し方を今のうちに整理しておくと、次の更新でも詰まりにくくなります。