Zeabur からの移行：このガイドをあなたの Coding Agent に渡してください
Zeabur の内部構成と、これまで Zeabur が代わりに担ってきたことを、agent 向けのドキュメントにまとめました。あなたの agent が現在のサービスを読み取り、移行先を一緒に決めます。
Zeabur Teamこの記事は次の言語でもお読みいただけます： English、繁體中文、简体中文、Español、Bahasa Indonesia。
TL;DR： Claude Code や Codex などの coding agent を開き、次の一文を貼り付けてください。coding agent をお持ちでない場合は、Zeabur Support からチケットを作成し、サービスと期限日をお知らせください。移行をお手伝いします。
https://zeabur.com/blogs/migrate-from-zeabur.md を読んで、私のサービスを Zeabur から移行するのを手伝ってください。agent はまずサービスを棚卸しし、要件を確認したうえで移行先を提案し、移行を一歩ずつ進めます。何かを変更する手順の前には、必ずあなたに確認します。agent が何を読んでいるかは、ページ下部の AGENT ビューに切り替えると確認できます。
このガイドは、サービス終了の進行状況や皆さまからの報告に応じて随時更新します。移行を始める前に、agent に最新版を読み直させてください。
サービス終了のお知らせ のとおり、専用サーバーは 12 月 1 日以降、それぞれの期限日に順次停止します。共有クラスターは 12 月 1 日からすべてのサービスが一時停止されますが、データのバックアップのために手動で再開できます。12 月 31 日にすべてのサービスが停止します。最終日を待たず、ご自身の期限日に合わせて計画してください。
なぜ agent に任せるのか
プロジェクトも、技術への慣れも、予算も人それぞれです。サイトが動き続ければよい人もいれば、サーバーを完全に管理したい人も、Zeabur のような「push すればデプロイされる」体験を続けたい人もいます。決まった手順書ひとつでは、全員に対応できません。
agent はあなたのコードを読み、サーバーにログインできるため、記事が前提にできる範囲よりはるかに多くを把握できます。そこで、agent が自力では推測できない部分をドキュメントにまとめました。
- Zeabur 上のサービスがどの Kubernetes オブジェクトなのか、データ・イメージ・変数がどこにあるのか
- これまで Zeabur が担い、移行後は誰かが引き継ぐ必要があること
- 移行でよくつまずくポイント
移行先や使うツールは、agent があなたの状況に合わせて提案し、最終的にあなたが決めます。
あなたはどのタイプのユーザーですか？
| タイプ | マシンはどうなるか | agent が現状を読み取る方法 |
|---|---|---|
| Zeabur でレンタルした専用サーバー | Zeabur のクラウドアカウントに属し、期限後に削除されます。ディスクのデータは残りません | サーバーに SSH でログインし、k3s を直接読み取る |
| 自分のサーバー（Zeabur に接続） | 手元に残りますが、Zeabur がインストールしたコンポーネントは動作しなくなります | サーバーに SSH でログインし、k3s を直接読み取る |
| 共有クラスター | サービスは一時停止され、その後停止します | SSH なし。Zeabur CLI とダッシュボードを使う |
専用サーバーの root パスワードは購入時にメールで送られています。忘れた場合はダッシュボードでリセットするか、npx zeabur@latest server ssh でログインできます。
Zeabur は何を代わりに担っていたのか
移行後は、次の各項目に新しい担い手が必要です。agent は計画の際に一つずつ対応を説明します。
| Zeabur が担っていたこと | Zeabur 終了後 |
|---|---|
| Git のソースコードからイメージを自動ビルド | Dockerfile か、新しいプラットフォームのビルド機能が必要 |
| イメージを Zeabur のレジストリに保存 | pull できなくなり、再起動するとサービスが起動しません |
| push での自動デプロイ、デプロイ履歴、ワンクリックロールバック | CI/CD か、これらの機能を持つプラットフォームが必要 |
*.zeabur.app ドメイン | 使えなくなるため、独自ドメインへの切り替えが必要 |
| HTTPS 証明書の自動発行と更新 | リバースプロキシか、プラットフォームの証明書機能が必要 |
.zeabur.internal によるサービス間接続 | 新しい環境の接続方法に置き換える |
| 同じプロジェクト内のサービス間での変数の自動注入 | 実際の値を引き継ぐ |
| データベースの毎日の自動バックアップ | バックアップも消えるため、エクスポートして独自のバックアップを用意する |
| ログ、メトリクス、クラッシュやリソースのアラート | 独自のログ、監視、アラートが必要 |
| チームメンバーと権限 | 新しいプラットフォームで設定し直す |
特に問題になりやすいのはイメージと自動注入された変数です。前者は Zeabur の終了後に初めて表面化し、後者は移行した瞬間にアプリがデータベースへ接続できなくなります。
始める前に
- Claude Code や Codex などの coding agent
- パソコンに Node.js があり、プロジェクトを所有するアカウントで Zeabur CLI にログインしていること：
npx zeabur@latest auth login - 専用サーバーの場合：サーバーに SSH でログインできること
- ドメインの DNS を変更できる権限。Zeabur で購入したドメインは Dashboard から移管できます
- 期限日と、停止を許容できる時間帯
agent には、パソコンでログイン済みの CLI を使わせてください。Zeabur のアクセストークンはアカウント全体の権限を持つため、会話に貼り付けるとアカウントを渡すのと同じことになります。
移行はどのように進むのか
- 棚卸し：agent が各サービスのソース、ドメイン、データ量、イメージをエクスポートできるかを一覧にします。
- 移行先の選定：あなたの慣れ、予算、重視する機能に合わせて、agent が 2〜3 の方向性を比較します。例えば Railway のようなマネージドプラットフォーム、Coolify のようなセルフホスト型プラットフォーム、k3s、Docker Compose などです。
- 計画と試行：新しい環境にサービスを構築し、データを一度移し、主要な機能をテストし、バックアップを実際に一度復元します。
- 本番切り替え：あなたの同意を得てから Zeabur 上のアプリを一時停止し、最後のデータ同期を行い、DNS はあなた自身が変更します。
- 引き継ぎ：agent が新しい環境でのデプロイ、バックアップ、ロールバックの方法を説明します。
実際に稼働中の Django サイト（PostgreSQL、Redis、アプリケーション、nginx）をこの方法で移行しました。28 個のテーブルすべてで行数が一致し、本番切り替えの停止時間は約 6 分、そのうち約 3 分は証明書の発行待ちでした。
困ったときは
まず agent に現在の状態とエラーメッセージをまとめてもらい、期限日を添えて Zeabur Support からお知らせください。緊急度の判断に使います。