制限
この記事の英語版に更新があります。ご覧の翻訳には含まれていない変更点があるかもしれません。
最終更新日 2025年04月21日(月)
この記事は、Heroku プラットフォームのさまざまなコンポーネントで課される制限をまとめたものです。
制限は、さまざまな理由から存在します。Heroku プラットフォームのアーキテクチャ (Heroku ではアプリのログ履歴が最新の 1500 行しか保存されないなど) によって存在する制限もあれば、良質なプラットフォームシチズンシップ (1 時間あたり 4500 より多くのプラットフォーム API リクエストを行うことができないなど) を確保するために存在する制限もあります。
以下に記載されている制限の多くは他の Dev Center の記事にリンクされており、リンク先でその制限に関する詳細が提供されます。
アドオンアタッチメント
同じアドオンを最大 100 個の異なるアプリに接続できます。
API
Heroku Platform API のレート制限は、1 時間あたり 4500 回の呼び出しです。
アプリ
アプリ名
アプリ名の最大文字数は 30 文字です。
アプリの数
- 1 つのアカウントでは最大 100 個のアプリを保有できます。
- Heroku Team では最大 100 個のアプリを保有できます。
- Enterprise Team では最大 200 個のアプリを保有できます。
- Cedar Private Space では最大 25 個のアプリを保存できます。
- Fir Private Space では最大 200 個のアプリを保存できます。
カスタムドメイン
1 つのアプリには、最大 1,000 件のカスタムドメインを割り当てることができます。
Webhook
アプリ、アドオン、パイプラインごとに最大 10 個の独立したアプリの Webhook サブスクリプションを設定できます。
ビルド
並列ビルド
検証済みアカウントのみが、1 つのアカウントで複数のアプリのビルドを同時に実行できます。
確立された支払履歴のない検証済みユーザーは、一度に 10 個まで並列ビルドを作成できます。確立された支払履歴のある検証済みユーザーは、一度に 300 個まで並列ビルドを作成できます。
ほぼ同じアプリに対して Heroku Pipeline を正しく使用していることを確認します。同じアプリを複数バージョン構築してデプロイする代わりに、パイプラインを使用して一度だけアーティファクトを構築し、そのアーティファクトをパイプライン内の複数のアプリにプロモートします。
Git リポジトリ
ユーザーは、1 時間あたり、アプリごと、ユーザーごとに、Heroku Git リポジトリに対して 75 件のリクエストの繰り返しに制限されます。
リポジトリからの HEAD のチェックアウトの圧縮されていないサイズは、復元されたサブモジュールのサイズと合わせて 1 GB 以下にする必要があります。
slug のサイズ
slug のサイズは、正常に行われたコンパイルの最後に表示されます。slug のサイズ (圧縮後) は最大 500 MB であり、大半のアプリはこの上限を十分下回るようにします。slug のサイズが 300 MB に達すると、slug のサイズが大きくなるとブート時間が長くなる可能性がある旨が警告されます。
slug のコンパイル
slug のコンパイルは 15 分に制限されています。
ビルドリソース
ビルドには約 12 GB の最大メモリ制限があります。この制限を超えるビルドではメモリ不足エラーが発生し、メモリ制限内に収まるようにアプリのビルドを調整する必要があります。
OCI イメージサイズ
OCI イメージの最大サイズは 5 G です。この制限を超えるイメージを生成するアプリのビルドは失敗します。
dyno
dyno メモリ
dyno のサイズによって最大 RAM 容量が異なります。「dyno サイズ別の技術仕様」を参照してください。
dyno メモリと再起動
アプリケーションで使用できる RAM の上限は、使用する dyno サイズによって異なります。Dyno Manager によって dyno が再起動され、メモリ使用率が以下の場合は R15 エラーがログ記録されます。
eco、basic、またはstandard-1x dyno が割り当ての 2 倍にあたる 1 GB に到達した場合。standard-2x dyno が割り当ての 2 倍にあたる 2 GB に到達した場合。performance-m dyno が割り当ての 2 倍にあたる 5 GB に到達した場合。performance-l dyno が割り当ての 2 倍にあたる 28 GB に到達した場合。performance-l-ram dyno が割り当ての 1.2 倍にあたる 36 GB に到達した場合。performance-xl dyno が割り当ての 1.2 倍にあたる 74 GB に到達した場合。performance-2xl dyno が割り当ての 1.2 倍にあたる 151 GB に到達した場合。private-s またはshield-s dyno が割り当ての 1 GB に到達した場合。private-m またはshield-m dyno が割り当ての 2.5 GB に到達した場合。private-l またはshield-l dyno が割り当ての 14 GB に到達した場合。private-l-ram またはshield-l-ram dyno が割り当ての 30 GB に到達した場合。private-xl またはshield-xl dyno が割り当ての 62 GB に到達した場合。private-2xl またはshield-2xl dyno が割り当ての 126 GB に到達した場合。
メモリ使用量が割り当て量の 100% に達すると、Fir 世代のアプリのすべての dyno が再起動されます。
接続された One-off dyno のタイムアウト
One-off dyno への接続は、入力と出力の両方でアイドル状態が 1 時間続くと終了します。接続が終了すると、その dyno には SIGHUP が送信されます。このアイドルタイムアウトにより、対話型コンソールセッションを開いて使用しないままにすることによる、意図しない請求の発生が阻止されます。
分離された One-off dyno のタイムアウト
分離された One-off dyno は 24 時間ごとに再起動されます。つまり、One-off dyno の実行時間は最長で 24 時間となります。
One-off dyno の停止
アプリごとに以下の制限があります。
- 1 つの Eco One-off dyno (Eco には Eco dyno プランのサブスクリプションが必要)
- 最大 50 の並列 One-off Basic dyno
- 最大 50 の並列 One-off Standard dyno
- 最大 5 つの並列 One-off Performance dyno
- 最大 5 つの並列 One-off Private dyno
- 最大 5 つの並列 One-off Shield dyno
- 最大 255 の並列 One-off Fir dyno
アプリケーションのこの制限を上げるには、リクエストを送信します。
Spaces (Space)
「Private Space の制限」を参照してください。
環境設定
環境設定のデータ (すべてのキーと値の集まり) は、アプリごとに 64 KB 以内に制限されています。
ブートタイムアウト
dyno の Web プロセスでは、割り当てられた $PORT に 60 秒以内にバインドする必要があります。
アプリケーションの起動にさらに時間がかかる場合は、ブートタイムアウトツールを使用して上限を増やすことができます。ただし、一般的に起動時間が遅いとアプリケーションのデプロイが困難になり、dyno のエラーからのリカバリにも時間がかかるため、この方法は一時的な解決策としてのみ検討してください。
終了タイムアウト
dyno が強制終了または再起動された場合、dyno 内のプロセスは SIGTERM を受信してから 30 秒以内に終了する必要があります。30 秒を過ぎても終了しない場合は、SIGKILL を送信してプロセスを強制終了させます。
dyno の再起動の制限
「dyno の自動再起動」および「dyno のクラッシュ再起動ポリシー」を参照してください。
dyno のスケール
eco および basic dyno タイプでは、プロセスタイプごとに最大 1 つの実行中の dyno がサポートされます。さらに、eco dyno タイプを使用するアプリケーションは、最大で 2 つの並列実行されている dyno に制限されます。
「dyno のスケーリングとプロセスの制限」を参照してください。
アプリケーションのこの制限を上げるには、リクエストを送信します。
プロセス/スレッド
同時に 1 つの dyno 内に存在できるプロセス/スレッドの最大数は、[dyno サイズ](dyno-type. See Dyno Scaling and Process Limitsに応じて異なります。
Enterprise Team
メンバーシップの制限
Enterprise Team のメンバーシップは、以下のとおり制限されています。
- エンタープライズ以外のアカウント: 25 メンバー
- エンタープライズアカウント: 500 メンバー
Heroku Postgres
Dataclips の行制限
Dataclips が返す行は最大で 100,000 行です。
Dataclips のデータ制限
Dataclips が返すデータは最大で 100 MBです。
Dataclips のクエリ制限のタイムアウト
Dataclips のクエリは 10 分後にキャンセルされます。
Basic、Standard、Premium、Enterprise 層の制限
Postgres プランの各層に関連する制限については、「Choosing the Right Heroku Postgres Plan」 (適切な Heroku Postgres プランの選択) の記事で説明されています。
資格情報の制限
Heroku Postgres では 120 個までの資格情報がサポートされています。
セキュリティと運用上の理由から、使用する資格情報はできるだけ少なくすることを強くお勧めします。資格情報が使用されているところを必ず追跡してください。
ログ
ログ履歴
Heroku では、アプリのログ履歴は最新の 1500 行のみが保存されます。1500 行を超えるログを保存するには、ロギングアドオンを使用するか、独自の syslog ドレインを作成するか、テレメトリードレインを追加します。Private Space Logging が有効になっている Shield Space 内のアプリ、または Fir 世代のアプリにはログ履歴がありません。
ドレイン
- Cedar 世代のアプリでは、最大 5 つのログドレインを設定できます。
- Fir 世代のアプリまたはスペースでは、最大 5 つのテレメトリードレインを設定できます。
行の長さ
dyno によって生成される行が 10000 バイトを超えると、末尾に余分な改行を追加せず、10000 バイトのチャンクに分割されます。それぞれのチャンクは個別のログ行です。
ビルド、CI、リリースフェーズ
ビルド、CI 実行、リリースフェーズによって生成されるログ出力は、300 MB に制限されています。その制限に到達した出力は、先頭から 150 MB のチャンクで切り捨てられます。
ネットワーク
ネットワーク帯域幅
ネットワーク帯域幅はアプリあたり 1 か月で 2 TB にソフト制限されています。
ルーター
HTTP タイムアウト
HTTP リクエストでは、最初の 30 秒間に Web プロセスが応答データを返す必要があります。このデータは、完了済みの応答でも、プロセスがアクティブであることを示す一定量の応答データでもかまいません。最初の 30 秒以内に応答データを返さないプロセスについては、H12 エラーがログに記録されます。
初回応答の後、サーバーから送信されるバイトごとに繰り返しの 55 秒間の時間枠が再開されます。同様の 55 秒間の時間枠が、クライアントから送信されるバイトごとに再開されます。
この 55 秒間の時間枠で dyno からのデータを何も受信しない場合は接続が切断され、H15 エラーがログに記録されます。
同様に、この 55 秒間の時間枠でクライアントからのデータを何も受信しない場合は接続が切断され、H28 エラーがログに記録されます。
HTTP 応答バッファ
ルーターは、dyno からの応答に対して、1 接続あたり 1 MB のバッファを維持します。
HTTP リクエストバッファ
受信リクエストを処理するとき、ルーターは 8 KB の受信バッファを設定し、HTTP リクエスト行およびリクエストヘッダーの読み込みを開始します。それぞれの長さは最大で 8 KB ですが、まとめると合計で 8 KB より大きくなります。リクエスト行またはヘッダー行が 8KB より長いリクエストは、ルーターによってディスパッチされずに破棄されます。
SSH キー
すべてのアカウントで、最大 50 の SSH キーをアカウントに関連付けられます。それ以上必要な場合は、Build API の使用を検討してください。