先に結論
Supabase を Node.js ランタイムで使っているなら、6月30日までに Node 22 以上へ上げる前提で棚卸しを始めたほうが安全です。
Supabase は 2026-06-30 で Node.js 20 のサポートを終えます。対象は @supabase/supabase-js だけではありません。auth、realtime、functions、storage、postgrest も含まれます。
一番先に見るべきなのは、依存更新より runtime 設定です。package.json だけ直しても、CI や Dockerfile や hosting が Node 20 のままだと詰まります。
何が変わるのか
Supabase は 2026-05-08 の changelog で、supabase-js monorepo 配下ライブラリの Node.js 20 サポートを 2026-06-30 で終えると告知しました。
対象は次の 6 パッケージです。
@supabase/supabase-js@supabase/auth-js@supabase/realtime-js@supabase/functions-js@supabase/storage-js@supabase/postgrest-js
推奨は Node.js 22 以上です。背景は単純で、Node.js 20 自体が 2026-04-30 に EOL へ到達し、セキュリティ更新を受けなくなったためです。
誰が急いで確認すべきか
まず確認したいのは、Supabase を browser SDK ではなく server runtime でも触っているチームです。
Next.js の SSR や Route Handler、background job、cron、queue worker、社内 CLI で Supabase を呼んでいるなら対象になりやすいです。見落としやすいのは、Web アプリ本体は新しい Node でも、CI や batch だけ Node 20 に残っているパターンです。
逆に、完全にブラウザ側だけで使っている小さな構成なら、今回の緊急度は少し下がります。ただし将来のライブラリ更新を続けるなら、どのみち Node 20 を外す準備は要ります。
先に洗うべき 4 か所
1. package.json の engines と lockfile
アプリ本体が Node 22 で動くつもりでも、engines や周辺 package が古い前提だと CI で落ちます。workspace 構成なら root だけでなく各 app と package も見直したほうが安全です。
2. CI の setup-node
GitHub Actions などで setup-node: 20 のまま残っているケースは多いです。ここが古いと test と build だけ Node 20 に固定されます。
3. Dockerfile と base image
SSR や worker をコンテナで回しているなら、node:20 系の base image が残っていないか確認してください。node:22 に上げるだけで済むことも多いですが、native addon を使うなら build stage まで一緒に見直す必要があります。
4. Hosting runtime の指定
Vercel や self-hosted 環境では、アプリコードと別に runtime 指定を持っていることがあります。Node version を repo 内で上げても、実行環境だけ古いまま残ると本番でだけ失敗します。
いま取るべき順番
先に build を通し、そのあと依存更新を広げるほうが安全です。
- Node 20 固定箇所を洗い出す
- Node 22 以上で CI と build を通す
- SSR、cron、worker の Supabase 呼び出しを確認する
- native addon や image 処理など、Node 更新で揺れやすい依存を洗う
- 本番 runtime を切り替える
この順なら、Supabase ライブラリ更新と runtime 更新を一気に混ぜずに進められます。
Supabase の他の期限対応も近い
Supabase まわりは今月、Node 20 以外の期限も続いています。
managed project なら、Postgres 14 サポート終了の記事 が次に効きます。self-hosted を使っているなら、PG 17 既定化の記事 も一緒に見たほうが安全です。
アクセス権限の運用を見直したいなら、一時 DB アクセス preview の記事 もつながります。Supabase 自体を比較から考え直したい人は、backend 比較記事 を見ると判断しやすいです。
まとめ
今回の変更は、Supabase が Node 20 を嫌ったという話ではありません。Node 20 がもう安全な前提ではないので、Supabase も追従してサポートを切るという話です。
だから先にやるべきことも明快です。ライブラリ一覧を眺めるより、まず runtime の棚卸しです。package.json、CI、Dockerfile、hosting runtime の 4 か所を見れば、かなりの事故を先回りできます。
6月30日はまだ少し先ですが、月末にまとめてやるには微妙に重い作業です。今のうちに Node 22 以上で build を通し、Supabase を使う server 側の経路を一度洗っておくのがいちばん現実的です。