HerokuからBuildへの移行
まだ検討段階の方へ。2つのプラットフォームの違いと、それぞれどのようなチームに適しているかはBuildとHerokuの比較をご覧ください。このページでは、移行したときに技術的に何が変わるかを説明します。
BuildはBuildpack、API、CLIのいずれのレベルでもHeroku互換です。一般的なHerokuアプリケーションであれば、ほとんどはコードを変更せずにBuild上で動作します。このページでは、同一ではない部分を扱います。
そのまま移行できるもの
Section titled “そのまま移行できるもの”| 移行可否 | 補足 | |
|---|---|---|
| Buildpack | 可 | Heroku Buildpackをそのままサポート |
| Dockerfileによるビルド | 可 | 代替手段として利用可能 |
| プロセスタイプ | 可 | webとworkerのプロセス。Procfileも同じ |
| Config vars | 可 | 同じ概念、同じ名称。インポートも可能 |
| パイプライン | 可 | Buildではリージョンをまたいだ昇格も可能 |
| レビュー環境 | 可 | 同じ概念 |
| Postgres | 可 | Buildが運用 |
| キーバリューストア | 可 | Buildが運用 |
| アドオン | 要確認 | 主要なものは網羅。特定のアドオンに依存している場合は事前にご確認ください |
| リクエストタイムアウト | 変わる | Herokuは30秒固定。Buildはアプリケーション単位で設定可能 |
| ダイノの定期再起動 | 変わる | Herokuは約24時間ごとに再起動。Buildは定期的な再起動を行いません |
| ダイノのクラス | 変わる | BuildにStandardティアはなく、すべてperformanceクラスです |
| アドオンの運用主体 | 変わる | Buildの自社アドオンはパートナーのインフラではなくBuildのハードウェア上で動作します |
Herokuの概念のほとんどは1対1で対応します。
| Heroku | Build | 補足 |
|---|---|---|
| Dyno | Dyno | 同じ単位。Buildのダイノはすべてperformanceクラス |
| ダイノタイプ（Standard-1X、Performance-M） | ダイノサイズ | サイズは1対1で対応し、ダイノ時間で課金 |
| Buildpack | Buildpack | Heroku Buildpackをそのままサポート |
| Config var | Config var | 同じ概念、同じ名称 |
| パイプライン | パイプライン | Buildはリージョンをまたいだ昇格が可能 |
| レビューアプリ | レビュー環境 | 同じ概念 |
| アドオン | アドオン | BuildのアドオンはBuildのインフラ上で動作 |
| Private Space | Private Space | 同じ概念、同じ名称。構成によってはBuild側で追加費用が発生する場合があります |
heroku CLI | bld CLI | ほぼ同じコマンド体系です。CLIガイドをご覧ください |
コンピュートと実行環境
Section titled “コンピュートと実行環境”Buildはすべてのダイノをperformanceクラスで動かすため、Standardティアも、共有テナントから抜け出すための段階もありません。ダイノサイズはHerokuと1対1で対応し、月間のプールに対してダイノ時間で課金されます。Dynoサイズをご覧ください。
Buildはダイノと並べて仮想マシンを動かすことができ、自身のKubernetesネームスペースへのkubectl直接アクセスも提供します。Herokuはいずれも提供しておらず、実行基盤のコントロールプレーンをお客様が操作することはできません。
リクエストタイムアウト。 Herokuのルーターは30秒のリクエスト上限を強制し、変更できません。Buildではレスポンスタイムアウトがアプリケーション単位の設定です。
実行環境のポリシー。 Herokuが固定している項目のいくつかを、Buildはアプリケーション単位の設定として公開しています。App Policiesでは、レスポンスタイムアウト、WebSocketの有効化、共有プロセスネームスペース、TLSパススルー、一時証明書の発行、Webアプリケーションファイアウォール、エロージョンレジスタンス。App Settingsでは、スタック、Buildpackの選択と順序、ビルドキャッシュ、リージョン。いずれもアプリケーション単位です。設定をご覧ください。
再起動。 Herokuは約24時間ごとにすべてのダイノを再起動します。Buildは定期的な再起動を行いません。必要な場合は、エロージョンレジスタンスで一定時間経過後にプロセスを自動再起動するよう設定できます。メモリリーク対策などに有効です。
パイプラインでの昇格。 Buildのイメージはアプリケーション単位・リージョン単位のため、ビルドをリージョンをまたいで昇格できます。Herokuのパイプライン昇格は単一リージョン内に限られます。CI/CDとパイプラインをご覧ください。
ビルドの同時実行。 Buildは同時ビルド数に制限を設けていません。Herokuの制限はアカウント単位で、アカウントの状態によって変わります。未認証アカウントは1件、認証済みで支払い実績のないアカウントは10件、支払い実績のある認証済みアカウントは300件です。多数のアプリケーションを一度に再デプロイする移行作業では、この上限が問題になります。
セッションの記録。 シェルおよびexecのセッションは記録され、アプリケーションのアクティビティログから再生できます。Herokuに同等の機能はありません。
データサービス
Section titled “データサービス”どちらのプラットフォームもマネージドのPostgresとキーバリューストアを提供し、複数のアプリケーションからの接続にも対応しています。Buildの自社アドオンは、コンピュートと同じハードウェア上で単一のチームが運用しています。Schema To Go（PostgreSQL）、Ave To Go（MariaDB）、Sequel To Go（Microsoft SQL Server）、Cache To Go（Redis）、Donkey To Go（MongoDB）、Spandex To Go（ElasticsearchおよびOpenSearch）、そしてトランザクションメール向けのMailer To Go、AI推論向けのInfer To Goです。これらはBuildが請求し、プランに含まれるアドオンクレジットから充当されます。パートナーアドオンはBuild経由でプロビジョニングされますが、提供と請求は別になります。アドオンサービスをご覧ください。
HerokuではPostgres、Key-Value Store、KafkaをHerokuが運用し、それ以外はサードパーティのElementsパートナーが提供しています。
データベースの制御。 Herokuでは変更できない3つの項目が、Buildでは設定可能です。共有バッファ、実効I/O同時実行数、最大並列ワーカー数などのPostgreSQLパラメータをインスタンス単位でチューニングできます。コネクションプーリングは、Buildpackを導入するのではなく設定として切り替えられます。そして、週次のメンテナンス時間とベースバックアップ時間を、指定されるのではなく自分で選べます。
ポイントインタイムリカバリはどちらのプラットフォームにもあります。
リージョン間の移設。 データストアはセルフサービスでリージョン間を移動できます。プロビジョニング、同期、切り替え、設定更新の流れが可視化されています。Herokuには、稼働中のデータアドオンをセルフサービスでリージョン移動する手段はありません。
アドオンの代替。 Herokuのマーケットプレイスはこのカテゴリ最大で、200を超えるアドオンがあります。Buildはそのうち広く使われているものを自社インフラ上で提供しています。特定のアドオンに依存しているアプリケーションでは、移行を計画する前に代替の有無をご確認ください。
ネットワークとリージョン
Section titled “ネットワークとリージョン”Buildは米国・EU・日本でのデータレジデンシーをすべてのプランで提供し、プライベートネットワーキングは標準、アプリ単位のマルチゾーンフェイルオーバーも利用できます。リージョンをご覧ください。
HerokuのCommon Runtimeは米国とEUです。それ以外のリージョンには有料のPrivate Spacesが必要です。Herokuにアプリケーション単位のゾーンフェイルオーバーはありません。
セキュリティとコンプライアンス
Section titled “セキュリティとコンプライアンス”どちらのプラットフォームもSOC 2に対応しています。HerokuはCommon RuntimeとPrivate Spacesの両リージョンでSOC 1・2・3を取得しており、PCI DSSとHIPAAへの対応はShield製品に限られます。
SOC 2レポートとロールベースのアクセス制御は、どちらのプラットフォームでもプランによる制限はありません。Herokuは2026年8月にきめ細かなアクセス制御を全顧客に提供開始しており、コンプライアンスレポートはサポート経由で請求でき、プラン要件の記載もありません。
違いはパッケージングです。BuildではSOC 2認証、プライベートネットワーキング、監査ログ、ロールベースのアクセス制御、Google Workspaceシングルサインオンがすべてのプランに含まれます。Herokuでは監査ログと全社シングルサインオンがエンタープライズアカウントの機能です。
さらにBuildは、Herokuにはどのプランでも同等機能のない次の項目を提供しています。
- OWASP Core Rule Setを用いた、アプリ単位で切り替えられるWebアプリケーションファイアウォール
- ビルドごとに生成されるSPDX形式のソフトウェア部品表
- コンテナイメージの脆弱性スキャン。レポートはイメージ単位で確認可能
- アプリケーションのアクティビティログから再生できる、記録済みのシェルおよびexecセッション
セキュリティをご覧ください。
単位が変わります。Herokuはダイノごと、アドオンごとに月額で課金します。Buildは月間のダイノ時間プールで課金し、稼働しているものがそこから差し引かれます。アドオンクレジットと人数無制限のシートも同じ金額に含まれます。
1ダイノ時間は、Standard-1Xダイノを1時間動かした分です。より大きなサイズはその分だけ多く消費し、Performance-Mは1時間あたり8ダイノ時間を使用します。キャパシティを見積もる際はこの数値が基準になります。
具体的なコスト比較はBuildとHerokuの比較を、プランごとのキャパシティはBuildの料金をご覧ください。
Buildは、接続したHerokuアカウントからアプリケーション、config vars、アドオン設定をインポートできます。アプリケーションを検証する間、両方のプラットフォームを並行して動かすことも可能です。エンジニアによる移行サポートは、エンタープライズプランのすべてのお客様に標準で含まれています。Buildへの移行をご覧ください。
よくある質問
Section titled “よくある質問”Heroku BuildpackはBuildで動作しますか？
はい、そのまま動作します。BuildはDockerfileによるビルドにも対応しています。
ダイノサイズは1対1で対応しますか？
はい。HerokuでN単位として課金されるダイノは、Buildでは1時間あたりNダイノ時間を消費します。Buildのダイノはすべてperformanceクラスです。
Private Spacesに相当するものはありますか？
Buildにも同じ名称のPrivate Spacesがあります。プライベートネットワーキングはすべてのプランで標準であり、米国以外のリージョンもプランを変更することなくすべてのプランで利用できます。構成によってはPrivate Spacesに追加費用が発生する場合があります。
30秒のタイムアウト対策は引き続き必要ですか？
タイムアウト自体への対策は不要になります。Buildではレスポンスタイムアウトがアプリケーション単位の設定のため、Herokuの30秒固定を回避する目的だけで切り出していた処理は、アプリケーションにとってその方が適していれば元の処理に戻せます。
ダイノは毎日再起動されますか？
いいえ。Buildは定期的な再起動を行いません。日次の再起動によって状態のクリアやメモリの解放を行っている場合は、エロージョンレジスタンスで一定時間経過後の再起動を明示的に設定してください。
最終確認日: 2026年9月7日