Deep-dive on the Next Gen Platform. Join the Webinar!

Skip Navigation
Show nav
Dev Center
  • Get Started
  • ドキュメント
  • Changelog
  • Search
  • Get Started
    • Node.js
    • Ruby on Rails
    • Ruby
    • Python
    • Java
    • PHP
    • Go
    • Scala
    • Clojure
    • .NET
  • ドキュメント
  • Changelog
  • More
    Additional Resources
    • Home
    • Elements
    • Products
    • Pricing
    • Careers
    • Help
    • Status
    • Events
    • Podcasts
    • Compliance Center
    Heroku Blog

    Heroku: Powering the Next Wave of Apps with AI

    17 hours ago by Betty Junod

    In a short amount of time, AI has transformed life, work, and how we think about the future. These rapid advancements have left many of us wondering how to integrate AI into our existing workflows... Read More

    Visit Blog
  • Log inorSign up
Hide categories

Categories

  • Heroku のアーキテクチャ
    • Dyno (アプリコンテナ)
      • Dyno Management
      • Dyno Concepts
      • Dyno Behavior
      • Dyno Reference
      • Dyno Troubleshooting
    • スタック (オペレーティングシステムイメージ)
    • ネットワーキングと DNS
    • プラットフォームポリシー
    • プラットフォームの原則
  • Developer Tools
    • コマンドライン
    • Heroku VS Code Extension
  • デプロイ
    • Git を使用したデプロイ
    • Docker によるデプロイ
    • デプロイ統合
  • 継続的デリバリーとインテグレーション
    • 継続的統合
  • 言語サポート
    • Node.js
      • Working with Node.js
      • Troubleshooting Node.js Apps
      • Node.js Behavior in Heroku
    • Ruby
      • Rails のサポート
      • Bundler の使用
      • Working with Ruby
      • Ruby Behavior in Heroku
      • Troubleshooting Ruby Apps
    • Python
      • Working with Python
      • Python でのバックグランドジョブ
      • Python Behavior in Heroku
      • Django の使用
    • Java
      • Java Behavior in Heroku
      • Working with Java
      • Maven の使用
      • Spring Boot の使用
      • Troubleshooting Java Apps
    • PHP
      • PHP Behavior in Heroku
      • Working with PHP
    • Go
      • Go の依存関係管理
    • Scala
    • Clojure
    • .NET
  • データベースとデータ管理
    • Heroku Postgres
      • Postgres の基礎
      • Postgres スターターガイド
      • Postgres のパフォーマンス
      • Postgres のデータ転送と保持
      • Postgres の可用性
      • Postgres の特別なトピック
      • Migrating to Heroku Postgres
    • Heroku Data For Redis
    • Apache Kafka on Heroku
    • その他のデータストア
  • モニタリングとメトリクス
    • ログ記録
  • アプリのパフォーマンス
  • アドオン
    • すべてのアドオン
  • 共同作業
  • セキュリティ
    • アプリのセキュリティ
    • ID と認証
      • シングルサインオン (SSO)
    • Private Space
      • インフラストラクチャネットワーキング
    • コンプライアンス
  • Heroku Enterprise
    • Enterprise Accounts
    • Enterprise Team
    • Heroku Connect (Salesforce 同期)
      • Heroku Connect の管理
      • Heroku Connect のリファレンス
      • Heroku Connect のトラブルシューティング
  • パターンとベストプラクティス
  • Heroku の拡張
    • Platform API
    • アプリの Webhook
    • Heroku Labs
    • アドオンのビルド
      • アドオン開発のタスク
      • アドオン API
      • アドオンのガイドラインと要件
    • CLI プラグインのビルド
    • 開発ビルドパック
    • Dev Center
  • アカウントと請求
  • トラブルシューティングとサポート
  • Salesforce とのインテグレーション
  • 言語サポート
  • PHP
  • Heroku の PHP サポート

Heroku の PHP サポート

日本語 — Switch to English

この記事の英語版に更新があります。ご覧の翻訳には含まれていない変更点があるかもしれません。

最終更新日 2024年05月30日(木)

Table of Contents

  • アクティベーション
  • PHP ランタイム
  • 拡張機能
  • 設定をカスタマイズする
  • 動作のビルド
  • ランタイムの動作
  • Web サーバー

このドキュメントでは、PHP アプリケーションの認識と実行に関連した Heroku の一般的な動作について説明します。

アクティベーション

Heroku の PHP サポートがアプリケーションに適用されるのは、アプリケーションに composer.json​ という名前のファイルがルートディレクトリにある場合だけです。アプリケーションに Composer​ 依存関係がない場合でも、PHP アプリケーションとして認識されるために少なくとも空​ ({}​) の composer.json​ を含んでいなければなりません。

Heroku は PHP アプリケーションを認識すると、それに応じてプッシュ中に応答します。

$ git push heroku main
-----> PHP app detected
…

composer.json​ があらゆる種類の依存関係を require​ セクションで指定すると、対応する composer.lock​ が composer update​ を実行することで生成されますが、リポジトリにもコミットされなければなりません。そうしないと、プッシュは拒否されます。これにより、Heroku がインストールする依存関係が他のあらゆる環境の依存関係と全く同じになります。詳細な説明は、PHP デプロイガイドの「依存関係の管理」セクション​を参照してください。

PHP ランタイム

Heroku では、公式 PHP​ ランタイムを使用してご使用のアプリケーションを実行できます。

サポートされているバージョン

Heroku の PHP サポートは、PHP 8.1​、PHP 8.2​、PHP 8.3​ シリーズの利用可能な最新リリースを使用するアプリケーションにまで及びます。

Heroku プラットフォームでの PHP リリースシリーズのサポートに適用される PHP Group のサポートポリシー​では、一般に初期 x.y.0 バージョンの後 2 年間のアクティブアップデートがあり、その後 1 年間のセキュリティアップデートがあります。

PHP リリースシリーズがサポート終了になると、Heroku によってサポートされなくなりますが、その最新リリースは、顧客がアプリケーションを新しい PHP バージョンにアップグレードできるようにビルドで利用可能なままになります。

PHP 8.1 はセキュリティのみのメンテナンスモードであり、2023 年末に完全にサポート終了となります。重大なセキュリティ修正だけが PHP メンテナンスにより、このリリースシリーズに提供されます。 ユーザーにはできるだけ早く、ご使用のアプリケーションを PHP 8.3 にアップデートすることを強くお勧めします。 PHP リリースのサポートタイムラインの詳細は、公式 PHP Web サイトのサポート対象バージョンページ​を参照してください。

利用可能なバージョン

次の表に、各スタック​のビルドで利用可能なランタイムバージョンの一覧を示します。

PHP 7 および PHP 8.0 はサポートが終了しています。これらのバージョンについて、今後のバグ修正 (重大なセキュリティ修正を含む) が PHP メンテナンスにより提供されなくなります。Heroku では、これらのリリースを使用するアプリケーションのサポートが提供されません。 ユーザーにはできるだけ早く、ご使用のアプリケーションを PHP 8.3 にアップデートすることを強くお勧めします。 PHP リリースのサポートタイムラインの詳細は、公式 PHP Web サイトのサポート対象バージョンページ​を参照してください。

​ランタイム/シリーズ ​heroku-20 ​heroku-22
​PHP 7.3 ​7.3.33 ​-
​PHP 7.4 ​7.4.33 ​-
​PHP 8.0 ​8.0.30 ​-
​PHP 8.1 ​8.1.28 ​8.1.28
​PHP 8.2 ​8.2.19 ​8.2.19
​PHP 8.3 ​8.3.7 ​8.3.7

​黄色のテキストと背景でマークアップされている​行は、上流の保守担当からセキュリティアップデートのみ受け取っている​ PHP リリースシリーズを示しています。​赤色のテキストと背景でマークアップされている​行は、サポートが完全に終了し、上流の保守担当からいかなる種類のアップデートも受け取っておらず​、Heroku によるサポートが終了している PHP リリースシリーズを示しています。

ランタイムの設定

すべての PHP ランタイムがそれぞれのリリースの php.ini-production​ ファイルをベース php.ini​ 設定​として使用します。

上記にもかかわらず、次の INI ディレクティブは Heroku 固有の値に設定されています。

  • date.timezone​ を UTC​ に設定
  • error_reporting​ を以下に設定
    • E_ALL & ~E_STRICT​ (8.1 より前の PHP バージョン)
    • E_ALL & ~E_STRICT & ~E_DEPRECATED​ (PHP 8.1 以降)
  • expose_php​ を Off​ に設定
  • session.sid_length​ を 32​ に設定 (PHP 7.1 以降)
  • short_open_tag​ を On​ に設定
  • user_ini.cache_ttl​ を 86400​ に設定
  • variables_order​ を EGPCS​ に設定

さらに、PHP ランタイムでは常に OPcache​ が有効になっているためパフォーマンスが向上しており、次の設定変更が Heroku の dyno の固有特性に合わせて最適化されています。

  • opcache.enable_cli​ を 1​ に設定
  • opcache.validate_timestamps​ を 0​ に設定

PHP CLI

php​ CLI 実行可能ファイルの memory_limit​ PHP INI ディレクティブは、PHP バージョン 7.2 以降について完全に利用可能な dyno メモリにデフォルトで設定されます。つまり、たとえば php​ コマンドを使用する Worker dyno は、デフォルトの PHP INI の値 128M​ の代わりにこのメモリ制限を使用します。

デフォルトランタイム

アプリケーションで composer.json​ を使用しない場合や、composer.lock​ でパッケージ php​ の要件がどの依存パッケージにも含まれていない場合、アプリケーションは heroku-20​ スタックでは利用可能な最新バージョンの PHP 7 または PHP 8 を選択し、その他のすべてのスタックでは PHP 8 を選択します。

ランタイムを選択する

使用するランタイムを Composer Platform Packages​ composer.json​ を介して選択できます。プッシュ時に、Heroku は必要な情報を composer.lock​ から (ある場合) 読み取り、ない場合は composer.json​ に戻ります。

たとえば、次の composer.json​ が Heroku に使用するよう指示するのは最新バージョンの PHP 8 (8.2.0 以降) で、PHP 9 ではありません。

{
  "require": {
    "php": "^8.2.0"
  }
}

「8.2.13​」のように、厳密なバージョンを PHP や他のパッケージで指定しないでください。

代わりに、“^” や “~”next significant release operators​ を使用して適切なアップデートが、利用可能になったらプッシュ時に入手できるようにしてください。

PHP で、たとえば「~8.2.0​」を指定することで常に入手できる最新の 8.2.x リリースは、他の 8.2 シリーズ以降のリリースと完全互換性を持ちます (ただしセキュリティまたはパフォーマンスアップデートが含まれる場合があります)。ただし 8.3.0 以降とは互換性がありません。

最新の PHP 8.2 以降 (PHP 8.3、8.4 などを含む) を入手し、PHP 9 を入手しないためには、「^8.2.0​」を指定します。

Heroku は、解決済でインストールされるバージョンをプリントします。

-----> Installing platform packages...
       - php (8.2.13)

不明なバージョンやサポートされていないバージョンを指定するとエラーになり、代替えのバージョンのリストが表示されます。

PHP

「php​」を composer.json​ の require​ セクションで依存関係として指定して、PHP をランタイム (たとえば PHP 8.1 以降) として使用します。

{
  "require": {
    "php": "^8.1.0"
  }
}

必ず、受け取りたい最小バージョンに接頭辞として ^​ セレクタを付加することをお勧めします。こうすることで、更新されたバージョンが利用可能になると送信されるようになります。上記の例では、PHP 8.1.0 以降 (8.x シリーズの新しいバージョンを含む) を入手できますが PHP 9 はリリースされても送信されません (このリリースは、予期しない下位互換性問題が生じた場合、最初にアプリケーションのテストが必要になります)。

次に、新しい要件が composer.lock​ に「凍結」されていることを確認するため、次を実行します。

$ composer update

最後に、両方のファイルを git add​ および git commit​ することを忘れないでください。

アップグレード

ランタイムバージョン依存関係を明記していないアプリケーションをデプロイすると、当時の最新バージョンの PHP が使用されます。ご使用のアプリケーションは、より新しいバージョンの PHP がある場合、次のデプロイ時に自動的にアップグレードされます。

ご使用のアプリケーションがランタイムバージョン依存関係を明記している場合、バージョン制約に適合する最新のバージョンがインストールで選択されます。

拡張機能

利用可能なビルトイン拡張機能

次の表に、PHP にバンドルされているどのビルトイン拡張機能が PHP の各リリースシリーズで利用できるか、問題の拡張機能がデフォルトでロードされるかどうか、または composer.json​ 経由で明示的に有効化される​必要があるかどうかの一覧を示します。

​拡張機能 ​PHP 7.3 ​PHP 7.4 ​PHP 8.0 ​PHP 8.1 ​PHP 8.2 ​PHP 8.3
​ext-bcmath ​✔ ​✱ ​✱ ​✱ ​✱ ​✱
​ext-bz2 ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-calendar ​✔ ​✱ ​✱ ​✱ ​✱ ​✱
​ext-ctype ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-curl ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-date ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-dom ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-exif ​✔ ​✱ ​✱ ​✱ ​✱ ​✱
​ext-fileinfo ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-filter ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-ftp ​✔ ​✱ ​✱ ​✱ ​✱ ​✱
​ext-gd ​✔ ​✱ ​✱ ​✱ ​✱ ​✱
​ext-gettext ​✔ ​✱ ​✱ ​✱ ​✱ ​✱
​ext-gmp ​✔ ​✱ ​✱ ​✱ ​✱ ​✱
​ext-hash ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-iconv ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-imap ​✔ ​✱ ​✱ ​✱ ​✱ ​✱
​ext-intl ​✔ ​✱ ​✱ ​✱ ​✱ ​✱
​ext-json ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-ldap ​✔ ​✱ ​✱ ​✱ ​✱ ​✱
​ext-libxml ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-mbstring ​✔ ​✱ ​✱ ​✱ ​✱ ​✱
​ext-mysqli ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-mysqlnd ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-openssl ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-pcntl ​✔ ​✱ ​✱ ​✱ ​✱ ​✱
​ext-pcre ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-pdo ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-pdo_mysql ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-pdo_pgsql ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-pdo_sqlite ​✔ ​✱ ​✱ ​✱ ​✱ ​✱
​ext-pgsql ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-phar ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-posix ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-random ​- ​- ​- ​- ​✔ ​✔
​ext-readline ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-reflection ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-session ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-shmop ​✔ ​✱ ​✱ ​✱ ​✱ ​✱
​ext-simplexml ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-soap ​✔ ​✱ ​✱ ​✱ ​✱ ​✱
​ext-sockets ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-sodium ​✔ ​✱ ​✱ ​✱ ​✱ ​✱
​ext-spl ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-sqlite3 ​✔ ​✱ ​✱ ​✱ ​✱ ​✱
​ext-tokenizer ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-xml ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-xmlreader ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-xmlrpc ​✔ ​✱ ​- ​- ​- ​-
​ext-xmlwriter ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-xsl ​✔ ​✱ ​✱ ​✱ ​✱ ​✱
​ext-zend-opcache ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-zip ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​ext-zlib ​✔ ​✔ ​✔ ​✔ ​✔ ​✔
​✔: デフォルトで有効化される
​✱: オプション。​composer.json​ 経由で有効化​できる

​黄色のテキストと背景でマークアップされている​列は、上流の保守担当からセキュリティアップデートのみ受け取っている​ PHP リリースシリーズを示しています。​赤色のテキストと背景でマークアップされている​列は、サポートが完全に終了し、上流の保守担当からいかなる種類のアップデートも受け取っておらず​、Heroku によるサポートが終了している PHP リリースシリーズを示しています。

利用可能なサードパーティ拡張機能

次の表に、PHP の各リリースで利用できるサードパーティ拡張機能の一覧を示します。これらは PHP ランタイムとは別々に配布されているため、これらのバージョンも一覧で示しています。これらはデフォルトでロードされないため、composer.json​ 経由で明示的に有効化​する必要があります。

​拡張機能 ​PHP 7.3 ​PHP 7.4 ​PHP 8.0 ​PHP 8.1 ​PHP 8.2 ​PHP 8.3
​ext-amqp​ (1.x) ​1.11.0 ​1.11.0 ​1.11.0 ​1.11.0 ​1.11.0 ​-
​ext-amqp​ (2.x) ​- ​- ​2.1.2 ​2.1.2 ​2.1.2 ​2.1.2
​ext-apcu ​5.1.23 ​5.1.23 ​5.1.23 ​5.1.23 ​5.1.23 ​5.1.23
​ext-blackfire ​1.92.17 ​1.92.17 ​1.92.17 ​1.92.17 ​1.92.17 ​1.92.17
​ext-cassandra ​1.3.2 ​- ​- ​- ​- ​-
​ext-ev ​1.1.5 ​1.1.5 ​1.1.5 ​1.1.5 ​1.1.5 ​1.1.5
​ext-event​ (2.x) ​2.5.7 ​2.5.7 ​- ​- ​- ​-
​ext-event​ (3.x) ​3.1.3 ​3.1.3 ​3.1.3 ​3.1.3 ​3.1.3 ​3.1.3
​ext-imagick ​3.7.0 ​3.7.0 ​3.7.0 ​3.7.0 ​3.7.0 ​3.7.0
​ext-memcached ​3.2.0 ​3.2.0 ​3.2.0 ​3.2.0 ​3.2.0 ​3.2.0
​ext-mongodb ​1.16.2 ​1.19.1 ​1.19.1 ​1.19.1 ​1.19.1 ​1.19.1
​ext-newrelic​ (9.x) ​9.21.0.311 ​9.21.0.311 ​9.21.0.311 ​9.21.0.311 ​- ​-
​ext-newrelic​ (10.x) ​10.20.0.10 ​10.20.0.10 ​10.20.0.10 ​10.20.0.10 ​10.20.0.10 ​10.20.0.10
​ext-oauth ​2.0.7 ​2.0.7 ​2.0.7 ​2.0.7 ​2.0.7 ​2.0.7
​ext-pcov ​1.0.11 ​1.0.11 ​1.0.11 ​1.0.11 ​1.0.11 ​1.0.11
​ext-phalcon​ (4.x) ​4.1.3 ​4.1.3 ​- ​- ​- ​-
​ext-phalcon​ (5.x) ​- ​5.4.0 ​5.7.0 ​5.7.0 ​5.7.0 ​5.7.0
​ext-pq ​2.2.3 ​2.2.3 ​2.2.3 ​2.2.3 ​2.2.3 ​2.2.3
​ext-psr ​1.2.0 ​1.2.0 ​1.2.0 ​1.2.0 ​1.2.0 ​1.2.0
​ext-raphf ​2.0.1 ​2.0.1 ​2.0.1 ​2.0.1 ​2.0.1 ​2.0.1
​ext-rdkafka​ (4.x) ​4.1.2 ​4.1.2 ​- ​- ​- ​-
​ext-rdkafka​ (5.x) ​5.0.2 ​5.0.2 ​5.0.2 ​5.0.2​​[​2​] ​- ​-
​ext-rdkafka​ (6.x) ​6.0.3 ​6.0.3 ​6.0.3 ​6.0.3 ​6.0.3 ​6.0.3
​ext-redis​ (5.x) ​5.3.7 ​5.3.7 ​5.3.7 ​5.3.7 ​5.3.7 ​-
​ext-redis​ (6.x) ​6.0.2 ​6.0.2 ​6.0.2 ​6.0.2 ​6.0.2 ​6.0.2
​ext-uuid ​1.2.0 ​1.2.0 ​1.2.0 ​1.2.0 ​1.2.0 ​1.2.0
​[1]: この拡張機能は ​heroku-20​ スタック​では利用できません。 ​[2]: この拡張機能は ​heroku-22​ スタック​では利用できません。

​黄色のテキストと背景でマークアップされている​列は、上流の保守担当からセキュリティアップデートのみ受け取っている​ PHP リリースシリーズを示しています。​赤色のテキストと背景でマークアップされている​列は、サポートが完全に終了し、上流の保守担当からいかなる種類のアップデートも受け取っておらず​、Heroku によるサポートが終了している PHP リリースシリーズを示しています。

オプションの拡張機能を使用する

使用したいオプションの拡張機能を、composer.json​ から Composer Platform Packages​ を使用して明記できます。パッケージ名で上の拡張機能のリストの中の好きな識別子の前に「ext-​」を付けるだけです。

たとえば、オプションでバンドルされている拡張機能 bcmath​ や GMP​、サードパーティの Memcached​、サードパーティの MongoDB​ の特定のバージョンを有効にする場合、以下のようになります。

{
    "require": {
        "ext-bcmath": "*",
        "ext-gmp": "*",
        "ext-memcached": "*",
        "ext-mongodb": "^1.19.0"
    }
}

PHP にバンドルされている拡張機能を指定するとき「*​」をバージョンセレクタとして使用することをお勧めします。これは、そのバージョン番号が異なっていることがあるからです (しばしばバージョンが「0」として報告されます)。

次に、新しい要件が composer.lock​ に「凍結」されていることを確認するため、次を実行します。

$ composer update

最後に、両方のファイルを git add​ および git commit​ することを忘れないでください。

自分のローカルコンピュータで利用できる希望の拡張機能がない場合は、composer.json​ の要件を満たせないため、composer update​ ステップはエラーになります。 欠落している拡張機能をコンピュータに pecl​、brew​、あるいは同様の方法 (開発/本番パリティ)​を維持するために必ず行うこと) を使ってインストールできない場合は、欠落している (いわゆる「プラットフォーム」) の要件を無視するよう Composer に指示することができます。

$ composer update --ignore-platform-reqs

同じ --ignore-platform-reqs​ フラグは、新しい環境 (たとえば開発者のコンピュータ) で拡張機能が同様に利用できない場合に、composer install​ をさらなる依存関係インストールで実行するときにも使用できます。

次のプッシュ時に、Heroku が対応する PHP 拡張機能をインストールして有効にします。

-----> Installing platform packages...
       - php (8.2.13)
       - ext-bcmath (bundled with php)
       - ext-mcrypt (bundled with php)
       - ext-mongodb (1.17.0)
       - ext-memcached (3.2.0)
       - apache (2.4.58)
       - nginx (1.24.0)

Heroku にプッシュされたプロジェクトの依存関係が必要とするあらゆる PHP 拡張機能は、インストールされる拡張機能のリストが composer.lock​ から読み込まれて、自動的にインストールされます。

たとえば、プロジェクトが stripe/stripe-php​ PHP SDK for Stripe​ に依存する場合、Stripe SDK が必要とする mbstring​ 拡張機能は、デプロイ時に自動的にインストールされます。ext-mbstring​ パッケージがメイン composer.json​ の require​ セクションで明記される必要はありません。

userland パッケージによって “provide” 済みの拡張機能の扱い

さまざまな Symfony Polyfill​ などの特定の Composer パッケージは、そのパッケージメタデータ内でネイティブ PHP 拡張機能を provide​ 済みとして宣言します (また、その拡張機能の機能を、純粋に PHP コードを使用して部分的または完全に実装します)。それにより、Composer は依存関係の解決中に、それらを実際のネイティブ PHP 拡張機能の可能性のある置き換えであると見なすようになります。

ビルド中に、これらの “polyfill” 宣言は、Composer がパッケージのインストール​に適用するのとまったく同じルールを使用して、プラットフォームパッケージのインストール時に Heroku によって遵守されます。

つまり、symfony/polyfill-mbstring​ では ext-mbstring​ が provide​ 済みとして宣言されているため、composer.lock​ 内に symfony/polyfill-mbstring​ パッケージも存在する場合は、たとえば ext-mbstring​ に対する composer.json​ (または何らかの依存関係) の要件があってもネイティブ ext-mbstring​ 拡張機能はインストールされません。

-----> Installing platform packages...
       - php (8.1.2)
       - apache (2.4.52)
       - composer (2.2.5)
       - nginx (1.20.2)

最大のパフォーマンスと互換性のために、プラットフォームパッケージの依存関係の最初の解決がこの方法で完了した後、Heroku の PHP サポートでは、userland パッケージが provide​ 済みとして宣言しているすべての拡張機能のネイティブバージョンをインストールしようと試みます。

-----> Installing platform packages...
       - php (8.1.2)
       - apache (2.4.52)
       - composer (2.2.5)
       - nginx (1.20.2)
       NOTICE: detected userland polyfill packages for PHP extensions
       NOTICE: now attempting to install native extension packages
       Installing extensions provided by symfony/polyfill-mbstring:
       - ext-mbstring (bundled with php)

これらのインストールの試みは、問題の拡張機能が Heroku で使用できない可能性があるため、または選択された PHP バージョンのために、必ずしも成功するとは限りません。

-----> Installing platform packages...
       - php (8.1.2)
       - apache (2.4.52)
       - composer (2.2.5)
       - nginx (1.20.2)
       NOTICE: detected userland polyfill packages for PHP extensions
       NOTICE: now attempting to install native extension packages
       Installing extensions provided by phpseclib/mcrypt_compat:
       NOTICE: no suitable native version of ext-mcrypt available

特に、すでに解決されているプラットフォームパッケージは何も変更されません。インストールされている PHP バージョンでネイティブバリアントが使用できない場合、このような拡張機能を使用できるようになる PHP バージョンへのダウングレードは実行されません。その低い PHP バージョンがその他のすべての依存関係によって許可される場合でも同様です。

この動作により、userland polyfill パッケージは、PHP にバンドルされなくなった拡張機能の置き換えとして機能している (たとえば、上の例で phpseclib/mcrypt_compat​ が ext-mcrypt​ に対して行っているように) 場合など、必要に応じてその目的を確実に正しく果たすことができます。その一方で同時に、最大のパフォーマンスと互換性のために可能な場合は常に、問題のネイティブ PHP 拡張機能が確実にインストールされるようになります。

設定をカスタマイズする

PHP

PHP マニュアルの指示に従って​プロジェクトに置かれたあらゆる .user.ini​ ファイルが、メイン php.ini​ の後にロードされます。これらを使用して、PHP_INI_ALL​、PHP_INI_USER​ および PHP_INI_PERDIR​ のコンテキストで認められたあらゆるディレクティブを設定できます。

この詳細や PHP ランタイムの設定をカスタマイズする他の方法については、対応する Dev Center の記事​を参照してください。

動作のビルド

依存関係のインストール

以下のコマンドはデプロイ時に実行されて、依存関係を解決します。ただし composer.json​ が空で composer.lock​ が存在しない場合を除きます。

$ composer install --no-dev --prefer-dist --optimize-autoloader --no-interaction

Heroku が開発依存関係を composer.json​ の require-dev​ セクションからインストールすることはありません。ただし、require-dev​ セクションに PHP ランタイムバージョン要件が含まれていたり当該の要件を含む依存関係がリストされている場合、composer.json​ の require​ セクションに PHP ランタイムバージョン要件も含まれているか、当該の要件を含む依存関係もリストされていなければなりません。これは、Heroku がデフォルトの PHP ランタイムバージョンを選ばないようにすることで他の環境 (require-dev​ 依存関係を含む) がインストールするものと競合しないようにするためです。

インストールしたバージョンの Composer はプリントされるので、インストールが開始される前に参照できます。ビルドは、アプリケーションの composer.lock​ と互換性がある Composer バージョン (1.x、2.2.x LTS、または 2.3+) を使用して実行されます。Composer のそれぞれのバージョンは、コマンド名 composer​ でアプリの実行時に $PATH​ で参照できます。

後続のデプロイでのパッケージのインストールを高速化するために、アプリケーションの Composer キャッシュディレクトリはビルド間で保持されます。

使用可能な Composer バージョン

次の Composer バージョンが現在利用できます。

​Composer / シリーズ ​heroku-20 ​heroku-22
​Composer 1.x ​1.10.27 ​-
​Composer 2 LTS ​2.2.23 ​2.2.23
​Composer 2.x ​2.7.6 ​2.7.6

Composer 2.2 は、Composer の長期サポート (LTS) シリーズであり、Composer 2.0、2.1、または 2.2 によって生成されたロックファイルを含むアプリケーションのビルドに、または 7.2.5 より古い PHP バージョンを使用しているアプリケーションによって使用されます。

カスタムコンパイルステップ

アプリケーションがビルド中に実行したい追加のコンパイルステップを標準の post-install-cmd​ Composer スクリプト​ (たとえばアセットコンパイルまたはキャッシュプレウォーム手順) の一部にすべきでない場合、compile​ カスタムコマンド​ (composer.json​ にある場合) が次のコマンドを使用して実行されます。

$ composer compile --no-dev --no-interaction

composer.json で定義されているそうしたカスタムスクリプトコマンドはいずれも、1 つの文字列か、実行する複数のコマンドの配列です。​例:

{
  "scripts": {
    "compile": [
      "@php app/console assetic:dump --env=prod --no-debug",
      "MyVendor\\MyClass::postDeployComposerCallback"
    ]
  }
}

php​ または composer​ をいずれかの Composer スクリプトで実行する必要がある場合、常に @php​ または @composer​ の省略表記を使用して実行可能ファイルを参照してください。これにより、すべての環境で常に正しい PHP または Composer 実行可能ファイルが呼び出され、すべての Composer 設定​ (正しい PHP memory_limit​ を含む) が確実に適用されます。

 

Composer の bin-dir​ がコマンド実行中に $PATH​ の上にプッシュされている​ので、依存関係によりインストールされたバイナリが、スクリプトを記述するとき、vendor/bin/​ または同様の接頭辞を使用しなくても、CLI コマンドとして容易にアクセス可能になります。

プライベートリポジトリ

Private Packagist​ のようなプライベートリポジトリや、認証を必要とするソースからのパッケージ (プライベートの GitHub リポジトリのパッケージなど) を使用するには、Composer を認証詳細 (一般にはプロバイダまたはサービスにより生成されたトークン) とともに指定しなければなりません。

開発マシンで、これらは一般に Composer により auth.json​ に保存されます。しかし Heroku では、このような秘密情報は環境変数として保存されます​。COMPOSER_AUTH​環境変数は自動的に Composer から読み込まれます​。その JSON 構造は auth.json​ と同じです。

以下のエントリは、JSON ドキュメントで最上位の鍵として認められています。

  • http-basic
  • github-oauth
  • gitlab-oauth
  • gitlab-token
  • bitbucket-oauth

各エントリにはドメインのハッシュが鍵として、認証詳細が値として含まれます。認証詳細構造は、上記の各ソースに固有のものであり、ドキュメントで説明されています。

GitHub Enterprise や Self-Managed version of GitLab を使用しているときは、github-domains​ または gitlab-domains​ 設定オプションをプロジェクトの composer.json​ 内で設定することも忘れないでください。

たとえば、Private Packagist​ アカウントの認証詳細を保管するには、COMPOSER_AUTH​ 変数を heroku config:set​ と http-basic​ 詳細を使用して設定します (“YOURTOKEN” を生成された実際のトークン Private Packagist に置き換えます)。

$ heroku config:set COMPOSER_AUTH='{"http-basic":{"repo.packagist.com":{"username":"token","password":"YOURTOKEN"}}}'

もう 1 つの例を挙げると、プライベート GitHub リポジトリのコードを Composer 依存関係として使用​しているとき、個人用の OAuth トークン​を認証で設定できます。新しい Token を作成した後で​、それを Heroku で設定できます (“YOURTOKEN” を生成された実際のトークン GitHub に置き換えます)。

$ heroku config:set COMPOSER_AUTH='{"github-oauth":{"github.com":"YOURTOKEN"}}'

composer.json​ の中のプライベートリポジトリ URL は https://​ プロトコルを使用しなければなりません。git://​ プロトコルを使用すると Composer が OAuth トークンを認証で使用できなくなります。

複数の認証詳細セットを組み合わせて 1 つのドキュメントにして、たとえばプライベート GitHub リポジトリとプライベート BitBucket リポジトリの両方を使用することもできます。

$ heroku config:set COMPOSER_AUTH='{
    "github-oauth": {"github.com": "YOURTOKEN"},
    "bitbucket-oauth": {"bitbucket.org": {
        "consumer-key": "YOURKEY", "consumer-secret": "YOURSECRET"}
    }
}'

上記の例のように Heroku で環境変数を設定するとき引用符内で改行を使用できます。しかし、heroku config:set​ コマンドを実行するとき引用が正しくなるようにしなければなりません。

Composer 設定

Composer の次の設定は、便宜上、環境変数を使用して自動的に設定されます。

  • $COMPOSER_MEMORY_LIMIT​ はデフォルトで、利用可能な dyno メモリに設定されます。
  • $COMPOSER_MIRROR_PATH_REPOS​ はデフォルトで 1​ に設定されます。
  • $COMPOSER_NO_INTERACTION​ はデフォルトで 1​ に設定されます。

ランタイムの動作

$PATH​ 環境変数には、アプリケーションがランタイム時に機能するために必要なすべてのパスが含まれています。Composer bin-dir​ は便宜上 $PATH​ に付け加えられています。

PHP-FPM 設定

PHP-FPM は、dyno サイズと設定された PHP memory_limit​ に基づいて、適切な数の Worker プロセスを自動的に生成するよう設定されます。詳細は、「Optimizing PHP Application Concurrency​」(PHP アプリケーションの並列性の最適化) を参照してください。

タイムアウト

リクエストが Heroku ルーターのリクエストタイムアウトに達した​場合であっても、PHP-FPM プロセスは、外部タイムアウトが発生するまで実行を継続することがあります。これにより PHP-FPM プロセスが拘束されることがあり、他の受信リクエストに応答しなくなる可能性があります。

PHP 7.4 以降を使用するアプリケーションの場合、PHP-FPM は次の動作を行います。

  • 3 秒 (request_slowlog_timeout​ ディレクティブ) 以上かかっているリクエストのバックトレースをログに記録する
  • 実行時間が 30 秒 (request_terminate_timeout​ ディレクティブ) を超過したことによりタイムアウトした​可能性があるリクエストを終了する。

PHP-FPM の設定を調節して、​ 次の (あるいはその他の) 設定を変更することができます。

Composer 設定

Composer の次の設定は、便宜上、環境変数を使用して自動的に設定されます。

  • $COMPOSER_MEMORY_LIMIT​ はデフォルトで、利用可能な dyno メモリに設定されます。
  • $COMPOSER_MIRROR_PATH_REPOS​ はデフォルトで 1​ に設定されます。
  • $COMPOSER_NO_INTERACTION​ はデフォルトで 1​ に設定されます。
  • $COMPOSER_PROCESS_TIMEOUT​ はデフォルトで 0​ に設定されます。

Web サーバー

Apache HTTPD 2.4​ と Nginx​ が Heroku で専用 Web サーバーとしてサポートされています。テスト目的のため、ユーザーは PHP のビルトイン Web サーバーを使用することもありますが、これは推奨していません。

“Web” dyno タイプに Procfile​ エントリがないとき、Apache Web サーバーは PHP ランタイムと併用されます。

次の Web サーバーのバージョンがサポートされており、ビルド中に自動的にインストールされます。

​Web サーバー / シリーズ ​heroku-20 ​heroku-22
​Apache 2.x ​2.4.59 ​2.4.59
​Nginx 1.x ​1.24.0 ​1.24.0

Apache

Apache は、FastCGI 経由で mod_proxy_fcgi​ を使用して、PHP-FPM とインターフェース接続します。

Apache を PHP-FPM と一緒に正しいすべての設定で起動するには、heroku-php-apache2​ スクリプトを使用します。

web: heroku-php-apache2

デフォルトでは、プロジェクトのルートフォルダはドキュメントルート​として使用されます。サブディレクトリを使用するには、サブフォルダの名前 (たとえば “public_html”) を引数としてブートスクリプトに渡します。

web: heroku-php-apache2 public_html

正規の .htaccess​ ファイルを使用して Apache の動作 (URL 書き換え​など) をカスタマイズできます。この詳細や Apache の設定をカスタマイズする他のオプションについては、該当の Dev Center の記事​を参照してください。

Nginx

Nginx は、FastCGI 経由で PHP-FPM とインターフェース接続します。

Nginx を PHP-FPM と一緒に正しいすべての設定で起動するには、heroku-php-nginx​ スクリプトを使用します。

web: heroku-php-nginx

デフォルトでは、プロジェクトのルートフォルダはドキュメントルート​として使用されます。サブディレクトリを使用するには、サブフォルダの名前 (たとえば “public_html”) を引数としてブートスクリプトに渡します。

web: heroku-php-nginx public_html

Nginx の設定をカスタマイズする様々な方法の詳細は、該当の Dev Center の記事​を参照してください。

PHP ビルトイン Web サーバー

テスト目的のため、PHP のビルトイン Web サーバー​を起動するには、php -S 0.0.0.0:$PORT​ を Procfile​ の “web” でエントリとして使用します。

web: php -S 0.0.0.0:$PORT

Procfile​ には $PORT​ が上記の行に含まれていなければなりません。これを Heroku がランタイム時に使用して、Web サーバーインスタンスを dyno の正しいポートへ動的に結び付けます。

 

重要なのは 0.0.0.0​ を使用してすべてのインターフェースに結び付けることです。そうしないと、Heroku のルーティング​がリクエストを Web サーバーに転送できなくなります。

代わりのドキュメントルートを渡すか、いわゆるルータースクリプトを使用してリクエストを処理することもできます。詳細は、PHP プロジェクトのビルトイン Web サーバーに関するドキュメント​を参照してください。

関連カテゴリー

  • PHP
Memcache を使用した Laravel アプリケーションのスケーリング Heroku スターターガイド (PHP)

Information & Support

  • Getting Started
  • Documentation
  • Changelog
  • Compliance Center
  • Training & Education
  • Blog
  • Support Channels
  • Status

Language Reference

  • Node.js
  • Ruby
  • Java
  • PHP
  • Python
  • Go
  • Scala
  • Clojure
  • .NET

Other Resources

  • Careers
  • Elements
  • Products
  • Pricing
  • RSS
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku Blog
    • Heroku News Blog
    • Heroku Engineering Blog
  • Twitter
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku
    • Heroku Status
  • Github
  • LinkedIn
  • heroku.com
  • Terms of Service
  • Privacy (日本語)
  • Cookies
  • Cookie Preferences
  • Your Privacy Choices
  • © 2025 Salesforce.com