Phusion が Phusion Passenger（ mod_railsとしても知られている）の次回バージョンである3.2のプレビュー版をリリースした。 Passengerは Apache上でRuby webアプリケーションを走らせる推奨の方法であるが、 nginxとも走り Pythonもサポートしている。バージョン3.2は ApplicationPoolが書き換えられており、I/Oハンドリングがイベント駆動となり、Pythonサポートは第一級市民となった。
Passenger はデプロイされたRubyアプリケーションの複数のインスタンスをフォークし、プールすることで動く。これによって、典型的なRuby webアプリケーションの2つの問題、新しいインスタンスの生成が遅いのとそうすると非常にメモリーを消費すること、に対処している。 ApplicationPool はこのキャッシュとインスタンスのプーリングを行う。
Phusion Passengerの中心的なサブシステムの1つが ApplicationPoolで、必要な時にRubyアプリケーションプロセスを生成し、それらを追跡する。トラフィックに応じてプロセスの数をスケールし、プロセス数が決められたリソース制限値を超えないことを保証する。
3.2では、ApplicationPoolは完全にC++で書き直された。その理由は「 Phusion Passengerのようなシステムソフトウェアには、Rubyは向いていない言語であることがわかった」からで、その結果「ずっと並列処理性と耐障害性が向上した」システムになった。
新しいコードはまた可読性と保守性も向上した。このことで多くの潜在的な将来の改善に向けた道が開けた。3.2はまた、同時に複数のRubyバージョンをサポートする。
リクエスト－レスポンスI/O は、複数スレッドの代わりにlibev （ソケットとタイムアウト用に）と libeio（ファイルI/O)を使って、イベント駆動で処理する。これで同時処理できるI/O数が劇的に増加し（libev と libeioはまたNode.jsでも使われている）、更に
これによって、WebSocket、長時間ポーリング、潜在的に長時間オープン状態にするための、接続ソケットが要る他のメカニズムを将来サポートする道を開いた。
新しいI/Oハンドラーの最高のフィーチャの1つは、リアルタイムなディスクバッファされたレスポンス転送です。 Phusion Passenger 3.2では、もしクライアントが遅ければレスポンスデータをメモリーにバッファするか、データがある閾値よりも大きければディスクにバッファします。対照的にほとんどのwebサーバーに対しては、データを転送する前に、全レスポンスが終わるまで待ちません。それを直ちにやります。
3つ目の改善は、Pythonアプリケーションを走らせるための、 WSGI サポートである、と彼らは言っている。彼らが言うには、それらは「動いたが、特に良いものではなかった。 WSGIは第一級市民として非公式にサポートされることになりました。PythonプロセスはちょうどRubyプロセスのように管理されます
Phusionは最近ドキュメントページを綺麗にした。 Mizuhoを使ったが、これは、文書フォーマットツールAsciiDocに彼らが書いたラッパーである。