Phusion white papers Phusion overview

Phusion Blog

Introducing Phusion Passenger 5 beta 1, codename “Raptor”

By Hongli Lai on November 25th, 2014

Phusion Passenger Raptor

Executive summary

Phusion Passenger is an app server that supports Ruby. We have released version 5 beta 1, codename “Raptor”. This new version is much faster, helps you better identify and solve problems, and has a ton of other improvements. If you’ve followed the Raptor campaign then you may wonder why we held the campaign like this. Read on if you’re interested. If you just want to try it, scroll all the way down for the changelog and the installation and upgrade instructions.

Learn more about Phusion Passenger


A month ago, we released a website in which we announced “Raptor”, supposedly a new Ruby app server that’s much faster than others. It has immediately received a lot of community attention. It was covered by Fabio Akita and by RubyInside’s Peter Cooper. From the beginning, “Raptor” was Phusion Passenger 5, a new major version with major internal overhauls. In the weeks that followed, we blogged about how we made “Raptor” fast.

Even though “Raptor” is Phusion Passenger, it doesn’t make the impact any less powerful. The performance improvements that we claim are real, and they are open source. Because “Raptor” is Phusion Passenger 5, it means that it automatically has a mature set of features:

  • Handle more traffic
    Phusion Passenger 5 is up to 4x faster than other Ruby app servers, allowing you to handle more traffic with the same hardware.
  • Reduce maintenance
    Automates more system tasks than other app servers. Spend less time micromanaging software, and more time building your business.
  • Identify & fix problems quickly
    Why is your app behaving the way it does? What is it doing? Phusion Passenger 5 provides tools that give you the insights you need.
  • Keep bugs & issues in check
    Limit the impact of bugs and issues, making downtime and user dissatisfaction less likely. Reduce pressure on developers while the root problem is being fixed.
  • Excellent support
    We have excellent documentation and a vibrant community discussion forum. And with our professional and enterprise support contracts, you can consult our team of experts directly.
  • Improve security
    Provides extra layers of defense, reduces attack surfaces on applications and limits the impact of security vulnerabilities.

However, the authors behind “Raptor” remained unknown — until today. The reason why we ran the campaign like this is explained in this article.

A brief history

It is perhaps hard to fathom now, but in the early days of Ruby, getting an app into a production environment was a painful task in itself. Many hours were spent by developers on tedious tasks such as manually managing ports and performing other error-prone configuration sit-ups. The status quo of deployment back then wasn’t exactly in line with what Rails advocates through its “convention over configuration” mantra. Far from it in fact.

When we first introduced Phusion Passenger back in 2008, we wanted to “fix” this. We wanted Ruby deployment to be as easy as PHP so that developers could focus on their apps and lower the barrier of entry for newcomers.

Even though we have been able to help power some of the largest sites on the Internet over the past few years through Phusion Passenger, we have always remained vigilant as to not become complacent: we have been eagerly listening to the community as to what they expect the next big thing to be.

The observations we have made over the years have eventually culminated into Phusion Passenger 5, which was codenamed Raptor for a number of reasons.

A greater focus on performance and efficiency

Whether you are deploying a small web app on a VPS or spinning up tens of thousands of instances to power your e-commerce business, we all want the most bang for our buck. Being able to reduce the number of required servers would be beneficial in reducing costs and it is for this reason that developers seek to employ the most efficient software stack currently available. When it comes to making that choice, benchmarks from third parties often seem to play an important part in the decision making process. Even though they are convenient to consult, it is easy to overlook a couple of important things that we would like to underline.

When it comes to performance benchmarks for example, it does not always become clear how the results have been obtained and how they will affect the reader. This is mostly due to the fact that benchmarks are often performed on synthetic applications in synthetic environments that don’t take into consideration real world workloads and latencies. This often leads to skewed results when compared to real time workloads.

A good example of this is the “Hello World” benchmark, where people tend to benchmark app servers against a so-called “Hello World” application: an app that basically returns “Hello World”. Needless to say, this is hardly a real world application.

Anyone who has ever deployed a real world application will know that these kinds of benchmarks don’t really say anything useful as they effectively measure how fast an app server is at “doing nothing”.

In real world Ruby applications on the other hand, processing time quickly gets overtaken by the app itself, plus network overhead, rather than the app server: the differences in performance between the app servers basically become insignificant when compared to the time spent in the hosted app itself.

Despite this, benchmarks remain a popular source to consult when trying to figure out what the “best” software solution is. The danger here lies in the possibility that a developer might be tempted to base their decision solely on what bar chart sticks out the most, without so much as looking at what the other solutions all bring to the table.

There is a reason for example why Phusion Passenger — even though hot on the heels of its competitors — has not been leading these kinds of Hello World benchmarks in the past: we do much more than the competition does when it comes to ease of use, memory efficiency, security and features. All these things are not free, and this is basically what is being measured with said benchmarks.

When benchmarked against real world applications however, the differences in performance between app servers becomes almost indistinguishable. The focus should then be put on what feature-set is most suitable for your production app. We believe that on that front, Phusion Passenger is leading the pack.

We have tried many times to explain this in the comment sections of benchmarks, but have unfortunately had to infer that such explanations often fall on deaf ears. We think that’s a shame, but rather than continue to fight it, we have decided to try to beat our competitors on performance as well. This has led to a series of internal optimizations and innovations which we have documented in the Raptor articles. Not only do we believe we are now able to win these kinds of benchmarks, we believe we have been able to do so with mechanisms that are incredibly useful in real world scenarios too (e.g. Turbocaching).

A greater focus on showcasing the technology

Software that is easy to use runs the risk of being considered “boring” to hackers, or worse, “simple”. In the latter case, the underlying technology facilitating the ease of use gets taken granted for. Over the years, we felt this was happening to Phusion Passenger to the extent that we wanted to set the record straight.

A lot of thought went into using the right algorithms and applying the right optimizations to allow Phusion Passenger to do what it does best: being able to deliver an “upload-and-go” deployment experience second to none in a secure and performant manner is by no means a trivial task. We chose to abstract these implementation details however from the end-user as we wanted them to be able to focus more on their app and business rather than the nitty gritty when it came down to how “the soup was made”. Who cares right?

Well, as it turned out, a lot of hackers do. Articles about “Unicorn being Unix” sparked a lot of interest from hackers allowing it to quickly garner a following. We thought articles such as these were great, but felt somewhat disappointed that people seemed to forget that Phusion Passenger was already doing the majority of what was written in such articles a full year earlier. It then dawned on us that we were no longer being considered to be the new shiny thing, but rather considered being part of the establishment.

In hindsight, it was perhaps also an error of judgement of us to focus our marketing efforts mostly on businesses rather than the grassroots hacker community we originated from ourselves: they are not mutually exclusive and instead of mostly underlining the business advantages, we should have underlined the technological advantages much more as well.

In an effort to set this straight, we chose to document Raptor’s underlying technology in great detail which was incredibly well received by the Hacker News community. It was in fact on the front page for most of the day with close to 200 upvotes and sparked a lot of discussions on Twitter too.

Besides the new optimizations and features found in Raptor, a lot of technology discussed in those articles was already available in Phusion Passenger 4 and its precursors. If there is a lesson to take from all this, it is that marketing is indeed the art of repetition. And that it probably helps to present it as the new kid on the block to get rid of any preconceived notions/misconceptions people might have had about Phusion Passenger.

Smoke and mirrors

Whether or not people would be just as excited if they knew that it was Phusion Passenger 5 all along is perhaps another discussion to be had: some actually found out ahead of time due to the similar writing style of our tech articles and / or through nslookups (a fedora hat-tip goes out to you folks! May your sense of scrutiny live long and prosper!).

What we do however know is that our Raptor approach over the past month has produced more subscribers to our newsletter than we have been able to accomplish over the past 6 years through the Phusion Passenger moniker. We still have a hard time comprehending this, but there is no denying the numbers: we — the community — seem to like shiny new things.

Truth be told, we didn’t really bother trying to cover up the fact that it was in fact Phusion all along that was behind Raptor. We kind of left it as an exercise to the reader to figure this out amidst all the “hype” and claims of “vaporware” to see if people still remembered Phusion Passenger’s fortes.

We were not disappointed when it came to that and felt incredibly proud that a lot of people questioned why Phusion Passenger was not included within the Raptor benchmarks and requested it to be included. Needless to say, this was something we were unable to do because it already was included all along as Raptor itself 😉 We were also happy to see that some even pointed out that some of the features look like they came straight out of Phusion Passenger.

What’s in a name?

You might be wondering why we chose to market Phusion Passenger 5 under the Raptor code name and went through so many hoops in doing so. To quote Shakespeare: “Conceal me what I am, and be my aid, for a disguise as haply shall become, the form of my intent”.

With all the new improvements and features pertaining to performance and introspection, we felt Phusion Passenger deserved new consideration from its audience in an objective manner. To circumvent any preconceived notions and/or misconceptions people may have had about Phusion Passenger over the years, we decided to market it as Raptor. We felt the codename was particularly appropriate for our renewed commitment to performance.

Just to be clear, Phusion Passenger will not be renamed to Raptor. Raptor is just a codename that has served its purpose by the time of this writing for Phusion Passenger 5. We will drop this name starting from today: from now on, “Raptor” is Phusion Passenger 5.

With a little help from our friends

The success of the Raptor campaign would not have been possible without the help and support of our friends. In particular, we would like to thank Peter Cooper and Fabio Akita for their in-depth write-ups on Phusion Passenger 5 / Raptor and its precursors. Their articles carried the necessary weight to allow us to focus on explaining and improving the technology itself rather than having to spend time on trying to debunk “vaporware” claims. In a similar manner, we would also like to thank David Heinemeier Hansson for helping us out via his tweets and feedback.

Lastly, we would like to thank the community and our customers for being so supportive. At the end of the day, it is you folks who make this all possible and we can’t wait to show you what we have in store for the future.

Final words before upgrade instructions

Phusion Passenger’s core is open source. Learn more about Phusion Passenger or fork or watch us on Github. 🙂

If you would like to stay up to date with Phusion news, please fill in your name and email address below and sign up for our newsletter. We won’t spam you, we promise.


5.0.0 beta 1 is a beta release. It may still have bugs and we do not recommend using it in production yet.

Version 5.0.0 beta 1 contains major changes. It is mostly compatible with version 4, but there are a few minor breakages, which are described below. Major changes and notable breakages are:

  • Performance has been much improved. This is thanks to months of optimization work. You can learn more at
  • We have published a server optimization guide for those who are interested in tuning Phusion Passenger.
  • Support for Rails 1.2 – 2.2 has been removed, for performance reasons. Rails 2.3 is still supported.
  • Phusion Passenger now supports integrated HTTP caching, which we call turbocaching. If your app sets the right HTTP headers then Phusion Passenger can tremendously accelerate your app. It is enabled by default, but you can disable it with --disable-turbocaching (Standalone), PassengerTurbocaching off (Apache), or passenger_turbocaching off (Nginx).
  • Touching restart.txt will no longer restart your app immediately. This is because, for performance reasons, the stat throttle rate now defaults to 10. You can still get back the old behavior by setting PassengerStatThrottleRate 0 (Apache) or passenger_stat_throttle_rate 0 (Nginx), but this is not encouraged. Instead, we encourage you to use the passenger-config restart-app tool to initiate restarts, which has immediate effect.
  • Websockets are now properly disconnected on application restarts.
  • The Phusion Passenger log levels have been completely revamped. If you were setting a log level before (e.g. through passenger_log_level), please read the latest documentation to learn about the new log levels.
  • If you use out-of-band garbage collection, beware that the X-Passenger-Request-OOB-Work header has now been renamed to !~Request-OOB-Work.
  • When using Rack’s full socket hijacking, you must now output an HTTP status line.
  • [Nginx] The passenger_set_cgi_param option has been removed and replaced by passenger_set_header and passenger_env_var.
  • [Nginx] passenger_show_version_in_header is now only valid in the http context.
  • [Apache] The PassengerStatThrottleRate option is now global.

Minor changes:

  • The minimum required Nginx version is now 1.6.0.
  • The instance directory is now touched every hour instead of every 6 hours. This should hopefully prevent more problems with /tmp cleaner daemons.
  • Applications are not grouped not only on the application root path, but also on the environment. For example, this allows you to run the same app in both production and staging mode, with only a single directory, without further configuration. Closes GH-664.
  • The passenger_temp_dir option (Nginx) and the PassengerTempDir option (Apache) have been replaced by two config options. On Nginx they are passenger_instance_registry_dir and passenger_data_buffer_dir. On Apache they are PassengerInstanceRegistryDir and PassengerDataBufferDir. On Apache, PassengerUploadBufferDir has been replaced by PassengerDataBufferDir.
  • Command line tools no longer respect the PASSENGER_TEMP_DIR environment variable. Use PASSENGER_INSTANCE_REGISTRY_DIR instead.
  • passenger-status --show=requests has been deprecated in favor of passenger-status --show=connections.
  • Using the SIGUSR1 signal to restart a Ruby app without dropping connections, is no longer supported. Instead, use passenger-config detach-process.
  • Introduced the passenger-config reopen-logs command, which instructs all Phusion Passenger agent processes to reopen their log files. You should call this after having rotated the web server logs.
  • [Standalone] The Phusion Passenger Standalone config template has changed. Users are encouraged to update it.
  • [Standalone] passenger-standalone.json has been renamed to Passengerfile.json.
  • [Standalone] passenger-standalone.json/Passengerfile.json no longer overrides command line options. Instead, command line options now have the highest priority.

Installing or upgrading

Here’s a quickstart:

gem install passenger --pre -v 5.0.0.beta1
cd /path-to-your-app
passenger start

The above is a very short excerpt of how to install or upgrade Phusion Passenger. For detailed instructions (which, for example, take users and permissions into account), please refer to the “RubyGems” section of the installation manuals:

Please note:

  • 5.0.0 beta 1 is a beta release. It may still have bugs and we do not recommend using it in production yet.
  • There are no Homebrew or Debian packages for this release, because this release is still in beta!
  • There is also a 5.0.0 beta 1 release of Phusion Passenger Enterprise available. Please refer to the Customer Area.

Meteor support for Phusion Passenger has been open sourced

By Hongli Lai on November 1st, 2013


For those who haven’t heard of Meteor yet: it is a hip new Javascript platform for developing web apps. It’s quite an innovation compared to “traditional” web frameworks: you develop in a single codebase and the code almost magically works in both the browser and the server. The platform also synchronizes data automatically across all connected clients by using long polling, WebSockets etc. It’s definitely worth checking out.

Are “traditional”[1] frameworks like Rails in danger? We at Phusion tend to believe that each framework has its own strengths and weaknesses, with no single framework being a silver bullet for all possible use cases. But there are many Meteor advocates out there who believe differently. Josh Owens from from Differential claims that Rails has seen its last days.

[1] In this article, “traditional” is used very loosely and refers to all non-Meteor-inspired frameworks. There’s nothing wrong with these older frameworks, just different. I still think Rails is revolutionary in many ways.

Announcing Phusion Passenger + Meteor

Whatever the result will be, the Phusion Passenger application server will be around to help you simplify your deployments and keeping your systems running smoothly.

Meteor support was previously an Enterprise-only feature. But just like we open sourced Node.js support a week ago, we are now open sourcing Meteor support. We are strong open source supporters at heart, and we believe that it’s time to give back to the community. The source code is already available on Github.

Why use Meteor on Phusion Passenger?

Phusion Passenger takes a lot of complexity out of deploying Meteor, and adds powerful enterprise-grade features that are useful in production. It also makes administering Meteor apps much easier. It has already done this for Ruby, Python and Node.js and is being used by high-profile companies such as Apple, Pixar, New York Times, AirBnB, Juniper etc.

Here are some of the benefits that Phusion Passenger gives you:

  • The power of Nginx – Phusion Passenger combines Meteor with the increasingly popular Nginx web server. By combining them, Nginx will offload Meteor from serving static assets. This also adds a buffering reverse proxy layer which provides I/O security and protects Meteor against invalid HTTP requests, slow clients, etc.
  • Multitenancy – Run multiple Meteor applications on a single server easily and without hassle.
  • Process management and supervision – Meteor processes are automatically started, and automatically restarted when they crash.
  • Statistics and insight – Phusion Passenger provides tools for inspecting the applications’ status, such what requests they’re currently processing, how many requests they’ve processed. All relevant information is shown at a glance. Having this in production will help a lot with tracking down problems.
  • Scaling and load balancing – Based on current traffic, Phusion Passenger can spawn more Meteor processes to handle the load, or spin down some existing Meteor processes to conserve resources. Phusion Passenger automatically load balances traffic across Meteor process. The load balancing mechanism utilizes a smart “first-available” selection algorithm to avoid problems caused by slow requests. Although Node.js and Meteor are single-threaded, this approach allows them to utilize multiple CPU cores.

Phusion Passenger is quite small and fast, being written in optimized C++. It’s a lightweight tool which drastically reduces complexity in your production environments.

How’s this any different from putting Meteor behind an Nginx reverse proxy yourself?

  • Using Phusion Passenger is much easier. If you do it yourself, you’ll have to write reverse proxy rules, write init scripts, setup process supervision, etc and the result probably does not handle corner cases properly. Phusion Passenger takes care of all this for you and handles virtually all the corner cases. This reduces the number of moving parts and reduces complexity.
  • Phusion Passenger integrates much deeper into Nginx than a straight reverse proxy does, and as such can leverage Nginx features much better. For example, the load balancing and response buffering in Phusion Passenger is much better than the one you get with manual reverse proxying.
  • By using Nginx’s proxy module, it’s very hard to see what’s going on with the system right now. Are all connections ok? Are all processes ok? Phusion Passenger provides simple and powerful administration tools that can help you with that.

Getting started

Update: for the most recent version of this tutorial, please refer to Phusion Passenger: Meteor tutorial.


Visit the Phusion Passenger download page. There are tailor-made, polished installation methods for OS X, Debian/Ubuntu, Heroku, etc. 🙂 You need at least version 4.0.23.

Preparing your app

A Meteor app in Phusion Passenger must contain the public and tmp subdirectories.

public directory contains static files. All files in this directory are automatically served by the web server. For example, if there’s a file public/foo.jpg, then any requests to /foo.jpg will be handled by the web server, and never passed to the application.

The tmp directory can be used by the application, but is also used by Phusion Passenger for restarting the application. By touching the file tmp/restart.txt, Phusion Passenger will restart the application on the next request. This seemingly strange mechanism comes from the fact that Phusion Passenger is designed to be friendly to shared hosters which only provide FTP access and no SSH access.

meteor create --example leaderboard
cd leaderboard
mkdir public tmp

Developing Meteor apps on Nginx

Developing on Nginx is a matter of adding a virtual host entry in your web server, and telling the web server that it’s a Phusion Passenger-served app. The meteor command must be installed.

Note that the document root must point to the public directory of the app! Suppose the app is located in /webapps/leaderboard, then:

server {
    root /webapps/leaderboard/public;
    passenger_enabled on;
    passenger_app_env development;

If you restart Nginx and visit now (assuming that your system’s DNS or /etc/hosts is configured to route to the web server in question), the request will be handled by your Meteor application.

There are many configuration options that you can tweak. Please refer to the Phusion Passenger manuals.

Deploying to Nginx during production

There are two options when deploying a Meteor app in production mode. You can either deploy a created Meteor bundle, or you can deploy the raw Meteor application directory.

Deploying a Meteor bundle

When deploying a Meteor bundle, we’re treating Meteor as a regular Node.js app. You do not need to have Meteor installed, just Node.js.

Create a bundle first and upload it to your production server:

meteor bundle leaderboard.tar.gz
scp leaderboard.tar.gz someserver:/webapps/leaderboard

On your production server, extract the bundle and install NPM modules:

cd /webapps/leaderboard
# This will create a directory /webapps/leaderboard/bundle
tar xzvf leaderboard.tar.gz
cd bundle
# Install whatever NPM modules your app needs. See the bundle README.
npm install fibers@1.0.1

You need to rename the main.js file in the bundle to app.js, and create a public directory, as per the Phusion Passenger requirements for Node.js.

mv main.js app.js
mkdir public

Now that the directory structure has been setup, create a virtual host in Nginx:

http {
    server {
       root /webapps/leaderboard/bundle/public;
       passenger_enabled on;
       passenger_set_cgi_param MONGO_URL mongodb://localhost:3002/meteor;
       passenger_set_cgi_param ROOT_URL;

Caveat (November 1 2013): unfortunately Nginx only allows setting environment variables globally, not per virtual host. We are working on a solution for this, which we expect to roll out in the coming few weeks. Please stay tuned for updates. This problem turns out to be untrue. passenger_set_cgi_param can be used to set environment variables.

Deploying a raw app directory in production

When deploying a raw Meteor app directory, you need to have Meteor installed. The procedure is the same as for developing Meteor apps on Nginx: you need to create a public directory, and you need to point the Nginx virtual host root there.

In this mode, you do not need to set MONGO_URL and other environment variables because Phusion Passenger will start your Meteor app through meteor run --production. Phusion Passenger even automatically finds a free port for it to run on so that you don’t need to worry about it.

cd /webapps/leaderboard
mkdir public


server {
    root /webapps/leaderboard/public;
    passenger_enabled on;
    # The following is not needed because passenger_app_env defaults to production.
    # But this example sets it explicitly so that you can see what's going on.
    passenger_app_env production;

Further reading and troubleshooting

Phusion Passenger comes with an extensive manual.

Running into any trouble? Please check out the troubleshooting section of the documentation.

Administration tools

The passenger-status tool allows you to inspect Phusion Passenger and the currently application’s state, such as what processes exist, how much memory and CPU they use, how many requests they’ve processed, etc.

The passenger-memory-stats tool allows you to inspect the memory usage of all processes related to Phusion Passenger, including the web server, Phusion Passenger itself and the applications. The difference with passenger-status is:

  • passenger-status does not display the web server’s memory usage.
  • passenger-status does not display the memory usage of internal Phusion Passenger processes.
  • The metrics displayed by passenger-status are gathered by internal Phusion Passenger processes that run in the background. passenger-memory-stats displays information by querying ps. If the Phusion Passenger internal processes are malfunctioning, then passenger-memory-stats still works.

Your feedback is valuable!

We’d like to hear from you if you’re using Phusion Passenger to host Meteor apps! If there are any problems, or even if there are no problems, we’d like to know. Please send an email to the community discussion forum. Thank you!

Discuss this on Hacker News.

Want to stay up to date with the latest Phusion news, including news about our Meteor support? Please sign up for our newsletter. You can unsubscribe any time.

Phusion Passenger’s Node.js support has been open sourced

By Hongli Lai on October 23rd, 2013


Phusion Passenger‘s Node.js support was originally an Enterprise-only feature. Since the introduction of Node.js support, we’ve received awesome feedback from Enterprise customers. Having said that, we are strong open source supporters at heart, and we believe that it’s time to give back to the community.

Today, we are pleased to announce that we are open sourcing Node.js support. Everybody can freely use, modify and distribute this, as in freedom and as in beer.

For those who are not familiar with Phusion Passenger: it is a fast and robust web server and application server for Ruby, Python, Node.js and Meteor. Passenger takes a lot of complexity out of deploying web apps, and adds powerful enterprise-grade features that are useful in production. High-profile companies such as Apple, New York Times, AirBnB, Juniper, American Express, etc are already using it, as well as over 350.000 websites.

The source code for the Node.js support is already available on Github. We’ve also written a detailed Phusion Passenger + Node.js tutorial.

More information about Node.js support will follow soon, so please keep an eye on this blog for the announcement, or subscribe to our newsletter using the form below.

Discuss this on Hacker News.

Debian and Ubuntu packages for Phusion Passenger

By Hongli Lai on September 11th, 2013

Update: this is the original announcement for our APT repository. For the latest instructions, please visit the download page.

We are pleased to announce the availability of the official Phusion Passenger APT repository. This APT repository contains Phusion Passenger packages for multiple versions of Debian and Ubuntu. These packages are automatically built by our build server after we push out a source release, and thus are always up to date with the official source releases. Phusion Passenger Enterprise is also packaged.

The repository even includes an up-to-date version of Nginx (1.4.2 at the time of writing), compiled with Phusion Passenger support. Even if you do not use Phusion Passenger, this repository is an excellent way to get the latest version of Nginx. This Nginx package works even if Phusion Passenger is not installed. We will regularly update the Nginx package so that it stays up-to-date with upstream Nginx releases.

Distributions and architectures

Packages are built for x86 and x86_64. Currently supported distributions are:

  • Ubuntu 10.04 “Lucid”
  • Ubuntu 12.04 “Precise”
  • Ubuntu 13.04 “Raring”
  • Debian 6 “Squeeze”
  • Debian 7 “Wheezy”

Our policy is to support all Ubuntu LTS releases that are still supported by Canonical, plus the latest non-LTS Ubuntu release, plus all Debian releases that are still supported by Debian.

Adding our APT repository

Packages are signed by “Phusion Automated Software Signing (”, fingerprint 1637 8A33 A6EF 1676 2922 526E 561F 9B9C AC40 B2F7. Install our PGP key:

gpg --keyserver --recv-keys 561F9B9CAC40B2F7
gpg --armor --export 561F9B9CAC40B2F7 | sudo apt-key add -

Our APT repository is stored on an HTTPS server so you may need to add HTTPS support for APT:

sudo apt-get install apt-transport-https

Next, create a file /etc/apt/sources.list.d/passenger.list and insert one of the following lines, depending on your distribution.

Phusion Passenger open source:

deb lucid main
deb precise main
deb raring main
deb squeeze main
deb wheezy main

Phusion Passenger Enterprise:

deb lucid main
deb precise main
deb raring main
deb squeeze main
deb wheezy main

You can find the correct value for ‘YOUR_DOWNLOAD_TOKEN’ in the Customer Area.

After creating /etc/apt/sources.list.d/passenger.list, run:

sudo chown root: /etc/apt/sources.list.d/passenger.list
sudo chmod 600 /etc/apt/sources.list.d/passenger.list
sudo apt-get update

Installing packages

Open source

To install Phusion Passenger for Nginx:

sudo apt-get install nginx-full passenger

Then edit /etc/nginx/nginx.conf, and uncomment passenger_root and passenger_ruby. Finally, run sudo service nginx restart.

To install Phusion Passenger for Apache:

sudo apt-get install libapache2-mod-passenger

To install Phusion Passenger Standalone:

sudo apt-get install passenger


Before installing packages, download your license key from the Customer Area and save it as /etc/passenger-enterprise-license.

To install Phusion Passenger for Nginx:

sudo apt-get install nginx-full passenger-enterprise

Then edit /etc/nginx/nginx.conf, and uncomment passenger_root and passenger_ruby. Finally, run sudo service nginx restart.

To install Phusion Passenger for Apache:

sudo apt-get install libapache2-mod-passenger-enterprise

To install Phusion Passenger Standalone:

sudo apt-get install passenger-enterprise


Special thanks go to John Leach from Brightbox for helping us. John has been maintaining third-party Ubuntu packages for Phusion Passenger for years. It is with his help and knowledge of Debian packaging that we were able to setup this official APT repository. is hosted on a server by Brightbox.

Discuss this on Hacker News

If you would like to stay up to date with Phusion news, please fill in your name and email address below and sign up for our newsletter. We won’t spam you, we promise.

Phusion Passenger Enterprise gem server

By Hongli Lai on September 6th, 2013

It is now possible to install Phusion Passenger Enterprise through our gem server. Previously, customers were able to download the gem from the Customer Area and using HTTP basic authentication to automate gem downloads. As of today, customers can use the gem command, and even use gem tools such as Bundler to install Phusion Passenger Enterprise. This should also make installation automation a lot easier.

To install the Phusion Passenger Enterprise gem, run the following commands:

gem source --add
gem install passenger-enterprise-server

Here, you must substitute YOUR_DOWNLOAD_TOKEN with the one you find in the Customer Area.
And notice the trailing slash in the URL! It is very important.

Future plans and conclusion

We’ve been working a lot on packaging and distribution lately. Our goal is to make the installation of both of the open source and the Enterprise variant as easy as possible.

In the past few weeks, we’ve been working on eliminating the need to compile Phusion Passenger for all Linux users. This goal consists of multiple steps, but the first goal has already been met: installation Phusion Passenger Standalone no longer requires compilation for most Linux users. This is also the first step towards making Phusion Passenger work on Heroku.

In order to make installation easier for OS X users, we’ve also introduced a Homebrew recipe for Phusion Passenger. Every time we release a new Phusion Passenger version, the Homebrew recipe is automatically updated!

Our next step is to publish Debian/Ubuntu APT repositories for both the open source and the Enterprise variants of Phusion Passenger. The basic toolchain is now in place, and we are working on integrating the toolchain on our servers.

We would like to thank all our customers for using Phusion Passenger Enterprise and for supporting the continuous development of Phusion Passenger.

No more compiling Phusion Passenger

By Hongli Lai on August 15th, 2013

On Unix systems, compiling software to install it is often the norm. However compiling takes CPU time and memory, and on some systems it is preferable not to have a compiler installed for security reasons. Especially compiling C++ code is memory-intensive, and could require as much as 700 MB of RAM. Since Phusion Passenger is written largely in C++, the need to compile Phusion Passenger could be problematic for some users, e.g. users on small VPSes with little memory.

Another problem is the need to compile Nginx. Unlike Apache, Nginx does not support dynamically loadable modules. So to add Phusion Passenger support, Nginx must be recompiled. Some users do not like doing this.

Today’s solutions

There are some solutions for this problem that you can already use with the current version of Phusion Passenger:

  1. You can use our Debian and Ubuntu packages, kindly contributed by John Leach from Brightbox. John Leach has been helping us with Debian packaging for years now, and he often updates his packages within a few days after an official release. Packages for both the Apache mode and the Nginx mode of Phusion Passenger are available.
    debian-square ubuntu-logo

    If you didn’t already know about this, you should. Strongly recommended. It solves nearly every problem users have with installing Phusion Passenger. Just run apt-get install libapache2-mod-passenger or apt-get install nginx-full, and you’re done. The provided Nginx package is the exact same as the one in Debian/Ubuntu, but with Phusion Passenger support added. This means you get to keep your /etc/init.d/nginx init script and other nice things.

    There are just two drawbacks at the moment: Phusion Passenger Standalone (described later in this article) is not packaged, and Phusion Passenger Enterprise is not packaged.

  2. You can precompile Phusion Passenger on one of your machines, and copy over the binaries to another machine.
  3. Users who do not mind compiling Phusion Passenger but do mind compiling Nginx, can use a reverse proxy setup with Phusion Passenger Standalone.

Tomorrow’s solution: binaries for Phusion Passenger Standalone

While the current Debian packages are great, we haven’t been standing still. There is still room for improvement. One of the things that we’ve been working on is a generic binary building infrastructure for Phusion Passenger. The end goal is to eliminate the need to compile Phusion Passenger, for all users that are using Linux on the x86 and x86_64 architectures, regardless of the distribution that they’re using.

This infrastructure automatically builds generic, multi-distribution-compatible Linux binaries for x86 and x86_64 every time we push commits to our Git repository. The Phusion Passenger installers can then just download binaries from the Phusion server instead of compiling them from source. The installers automatically check whether the downloaded binaries work on the current system, and if not, falls back to compiling. For 95%-99% of the users, this system effectively eliminates the need to compile Phusion Passenger. Furthermore, this infrastructure compiles binaries for both the open source variant and the Enterprise variant.

Rome was not built in one day, so we’re tackling this problem iteratively. Starting from the next version of Phusion Passenger, these automatically built binaries will be used in Phusion Passenger Standalone.

What is Phusion Passenger Standalone, and how is it related to compiling?

For those of you who are not familiar with Phusion Passenger Standalone: it is a third mode of Phusion Passenger, alongside with the Apache mode and the Nginx mode, introduced in 2010. In Standalone mode, Phusion Passenger does not require an external web server, and can be started with just a single command: passenger start. This command starts a fully-featured Phusion Passenger instance. In fact, it is powered by an Nginx core, making it very fast and lightweight, and extremely good at serving static assets. You can even expose Phusion Passenger Standalone immediately on the public Internet without using a reverse proxy, something e.g. Unicorn cannot safely do (“Slow Clients Are Problematic”). Therefore, Phusion Passenger Standalone is the easiest way to get a Ruby web app up and running with minimal hassle and with great performance. It can also be installed in a reverse proxy setup behind Nginx, for those who do not want to or cannot compile Nginx.

The following video, originally created in 2010, demonstrates Phusion Passenger Standalone. Note that back then it was still called “Phusion Passenger Lite”. As you can see, Phusion Passenger Standalone compiles its own runtime when it is run for the first time. Compiling can take a few minutes. Starting from the next version, starting Phusion Passenger Standalone for the first time takes a few seconds.

Day after tomorrow’s solutions: fully-automated binary building and package building

We have two goals for the futher future:

  1. Automatically download binaries when installing Phusion Passenger for Apache and Phusion Passenger for Nginx.
  2. To fully automate the building of Debian packages. Although the generic binaries should work for most of our users, installing Debian packages is easier still, and integrates better with the OS. We’re working on a system that will publish 100% working Debian packages 15 minutes after we publish the source code for a new release, so that no human intervention is required to publish Debian packages. This will greatly increase ease of installation and upgrade for users. There will also be automatically built Debian packages for Enterprise customers.

    We’ve already begun working on integrating Debian packaging scripts into our main Git repository. We’ve also written an automated set of tests for checking whether packages built with these scripts work correctly. These tests are run by our continuous integration server on every commit, so you could say that we’re employing “continuous packaging”.


We’re working hard on making Phusion Passenger as easy to install as possible. We take usability very seriously, and we invite everyone to review our generic binary building system, our Debian packaging scripts, as well as our packaging tests. All code is open source and available on Github.

If you would like to stay up to date with Phusion news, please fill in your name and email address below and sign up for our newsletter. We won’t spam you, we promise.

Technology Preview: Introducing Flying Passenger

By Hongli Lai on July 3rd, 2013

Phusion Passenger is software that deploys Ruby and Python web apps, by integrating into Apache and Nginx and turning them into a fully-featured application server. It is very fast, stable and robust and thus used by the likes of New York Times, AirBnB, Symantec, Pixar, etc. It comes with many features that make your life easier and your application perform better.

“Flying Passenger” is a technology which allows one to decouple Phusion Passenger’s life time from the web server’s life time, so that the web server can be independently restarted from Phusion Passenger, and from any of the application processes served by Phusion Passenger.

Normally, Phusion Passenger starts together with the web server, and shuts down together with the web server. The advantages of this default behavior is that it makes Phusion Passenger easy to administer: one only has to deal with the web server process and can expect all relevant processes to be cleaned up after a web server shut down. However this also brings about a disadvantage: every time one restarts the web server (e.g. to make a minor configuration change), Phusion Passenger and all its application processes also get restarted.

This problem is solved by “Flying Passenger”, which is an advanced mode of operation in Phusion Passenger that allows the web server to be indepedently restarted from Phusion Passenger. When this mode is enabled:

  • One must start Phusion Passenger separately from the web server, namely by starting the Flying Passenger daemon. This daemon must — to an extent — be separately configured and managed from the web server.
  • The web server must be configured to forward requests to the Flying Passenger daemon.
  • You should beware of the caveats and limitations, which will be described in this article.

Flying Passenger is fully documented in the Phusion Passenger manual. This article serves as an introduction.

Differences with existing reverse proxy setups

You may be wondering how this differs from existing reverse proxy setups with other application servers, e.g. Nginx+(G)Unicorn, Nginx+Puma, or Nginx+uWSGI. Most other application servers can serve only one application per instance. Flying Passenger works just like Phusion Passenger for Nginx: it can serve multiple applications. Almost all Phusion Passenger for Nginx features are preserved in the Flying Passenger mode: dynamic process scaling, process supervision, user switching, real-time response buffering, etc all work as one is used to in Phusion Passenger for Nginx. However, Flying Passenger is only partially configured through the Nginx configuration file; some configuration is set through command line options.

Python users may see parallels between Flying Passenger’s mode of operation and uWSGI Emperor’s.


Flying Passenger will become available in the Enterprise variant of the next Phusion Passenger release, namely version 4.0.6.

At this time, this feature is only available in Phusion Passenger for Nginx. You must have Phusion Passenger for Nginx properly installed. Flying Passenger is not available in Phusion Passenger for Apache, and also not in Phusion Passenger Standalone.

Basic usage

Start the Flying Passenger daemon by invoking the flying-passenger command. The only required option is --socket-file. Depending on whether you wish to enable User Switching, you have to start flying-passenger with root privileges or not.

$ sudo flying-passenger --socket-file=/var/run/flying-passenger.sock
I, [2013-06-14T09:10:13.095339 #77179]  INFO -- : Welcome to Flying Passenger 4.1.0
I, [2013-06-14T09:10:13.095339 #77179]  INFO -- : Starting PassengerWatchdog...
I, [2013-06-14T09:10:13.097036 #77179]  INFO -- : PassengerWatchdog started on PID 77181
I, [2013-06-14T09:10:13.129017 #77179]  INFO -- : PassengerWatchdog initialized properly
I, [2013-06-14T09:10:13.129127 #77179]  INFO -- : Flying Passenger up and listening on /var/run/flying-passenger.sock!

Now configure Phusion Passenger for Nginx to make use of the Flying Passenger daemon, by setting the passenger_fly_with option to the socket filename:

http {
    passenger_fly_with /var/run/flying-passenger.sock;

After (re)starting Nginx, Nginx + Flying Passenger is fully operational:

$ sudo /path-to/nginx

You can test it by adding a virtual host for a web app:

http {

    server {
        listen 80;
        root /webapps/foo/public;
        passenger_enabled on;

Verify that it works by making an HTTP request to it:

$ curl

Now let’s verify that restarting the web server does not restart the just-spawned application process. Run passenger-status to obtain the PID of the application process:

$ sudo passenger-status
Version: 4.1.0
Date   : 2013-06-14 09:21:51 -0400
----------- General information -----------
Max pool size : 6
Processes     : 1
Requests in top-level queue : 0

----------- Application groups -----------
  App root: /webapps/foo
  Requests in queue: 0
  * PID: 77283   Sessions: 0       Processed: 1       Uptime: 2s
    CPU: 1%      Memory  : 8M      Last used: 2s ago

As you can see, the PID of the application process is 77283. Now let’s see what happens if we restart Nginx:

$ sudo /path-to/nginx -s stop
$ sudo /path-to/nginx
$ sudo passenger-status

The application process should remain there, unchanged:

$ sudo passenger-status
Version: 4.1.0
Date   : 2013-06-14 09:21:51 -0400
----------- General information -----------
Max pool size : 6
Processes     : 1
Requests in top-level queue : 0

----------- Application groups -----------
  App root: /webapps/foo
  Requests in queue: 0
  * PID: 77283   Sessions: 0       Processed: 1       Uptime: 18s
    CPU: 1%      Memory  : 8M      Last used: 18s ago

Configuring Flying Passenger

Flying Passenger gets some configuration from the web server, but not all. In particular, most web server directives that are only valid in the http context, e.g. passenger_log_level, have no effect when using Flying Passenger. Instead, you are supposed to pass these configuration directives through command line options to the Flying Passenger daemon. Configuration directives that have no effect on Flying Passenger are documented as such. You can assume that configuration directives that are not documented as such, work fine on Flying Passenger.

For example, to achieve the same effect as setting passenger_log_level to 2, run the Flying Passenger daemon as follows:

$ sudo flying-passenger --socket-file=/var/run/flying-passenger.sock --log-level=2

Currently, not all configuration directives have a Flying Passenger equivalent. Run the following command to see an overview of available options:

$ flying-passenger --help

Managing the Flying Passenger daemon

The Flying Passenger daemon runs in the foreground by default. This is undesirable on server environments. You can make it go into the background by passing --daemonize, --log-file and --pid-file:

$ sudo flying-passenger --socket-file=/var/run/flying-passenger.sock \
    --daemonize --log-file=/var/log/flying-passenger.log \

You can shut down a Flying Passenger daemon by sending SIGINT or SIGTERM to it:

$ kill `cat /var/run/`

We recommend using daemontools or runit for managing the Flying Passenger daemon. These tools will automatically start the Flying Passenger daemon at boot, and will automatically restart the daemon if it crashes. You can create and enable a daemontools/runit service as folows:

$ sudo mkdir /etc/service/flying-passenger
$ sudo tee /etc/service/flying-passenger/run <<EOF
exec /path-to/flying-passenger \
    --socket-file=/var/run/flying-passenger.sock \
    --log-file=/var/log/flying-passenger.log \

Immediately after creating the run file, daemontools/runit automatically runs it to start the daemon. Note that the location (/etc/service) depends on the OS or Linux distros. Sometimes it’s /service. Also note that we start the Flying Passenger daemon without --daemonize.

To shut down a daemontools/runit-managed daemon, you need to use svc -d /etc/service/flying-passenger (daemontools) or sv stop /etc/service/flying-passenger (runit) instead of sending a signal to the process.

Caveats and limitations

Beware of the following caveats and limitations when using Flying Passenger:

  • The Nginx executable must be compiled with the same version of Phusion Passenger as the Flying Passenger daemon. Failing to meet this requirement may result in cryptic errors, or may result in certain features not working, until you’ve fixed the situation. When upgrading Phusion Passenger, you must restart both Nginx and the Flying Passenger daemon.
  • The passenger_root directive has no effect. When using Flying Passenger, you are not supposed to set passenger_root.
  • When you add a new application to the web server configuration, Flying Passenger will automatically pick up the application’s settings and spawn this new application upon the first request to it. However it is not capable of automatically starting the new app before a request has been sent to it (i.e. passenger_pre_start-like behavior is not available in this case). As a workaround, you can send an HTTP request to your application after starting the daemon, which forces it to spawn application processes.
  • When you remove an application from the web server configuration, Flying Passenger will not detect the removal and will not shut down the associated application processes. Killing the application processes will also not help, because Flying Passenger will restart them per the (now-removed, but still in the Flying Passenger daemon’s memory) passenger_min_instances settings. At the moment, there are two ways to get rid of those processes:
    • Before removing the application from the web server configuration, explicitly set its passenger_min_instances to 0. Next, send a request to it, which will cause the Flying Passenger daemon to take over the new passenger_min_instances 0 option. You can then proceed with removing the application from the web server configuration, and restarting the web server. Finally, kill the PIDs associated to those application processes and remove the application configuration.
    • Restart the Flying Passenger daemon.


Flying Passenger should especially be useful for those who have to modify Nginx configuration on a regular basis, without modifying application configuration. Flying Passenger is still a young feature, so we encourage users to provide feedback and bug reports.

We at Phusion are continuously developing and improving Phusion Passenger. If you would like to stay up to date with Phusion news, please fill in your name and email address below and sign up for our newsletter. We won’t spam you, we promise.

Phusion Passenger 4.0 Release Candidate 6

By Hongli Lai on April 9th, 2013

Phusion Passenger turns Apache and Nginx into a full-featured application server for Ruby and Python web apps. It has a strong focus on ease of use, stability and performance. Phusion Passenger is built on top of tried-and-true, battle-hardened Unix technologies, yet at the same time introduces innovations not found in most traditional Unix servers. Since mid-2012, it aims to be the ultimate polyglot application server.

Today we are pleased to announce Release Candidate 6 of Phusion Passenger 4.0. The 4.x series is a huge improvement over the 3.x series: during the development of 4.0, we’ve introduced a myriad of changes which we’ve covered in past beta preview articles:

Release Candidate 5 was a private interim release for Phusion Passenger Enterprise customers only.

Changes in 4.0 RC 5 and RC 6

The most important changes in RC 5 and RC 6 are as follows:

  • The default config snippet for Apache has changed! It must now contain a
    PassengerDefaultRuby option. The installer has been updated to output
    this option. The PassengerRuby option still exists, but it’s only used
    for configuring different Ruby interpreters in different contexts. Please
    refer to the manual for more information.
  • We now provide GPG digital signatures for all file releases by Phusion.
    More information can be found in the manual.
  • WebSocket support on Nginx. Requires Nginx >= 1.3.15.
  • passenger-status now displays process memory usage and time when it
    was last used. The latter fixes issue #853.
  • Exceptions in Rack application objects are now caught to prevent
    application processes from exiting.
  • The passenger-config tool now supports the --ruby-command argument,
    which helps the user with figuring out the correct Ruby command to use
    in case s/he wants to use multiple Ruby interpreters. The manual has
    also been updated to mention this tool.
  • Fixed streaming responses on Apache.
  • Worked around an OS X Unix domain socket bug. Fixes issue #854.
  • Out-of-Band Garbage Collection now works properly when the application
    has disabled garbage collection. Fixes issue #859.
  • Fixed support for /usr/bin/python on OS X. Fixes issue #855.
  • Fixed looping-without-sleeping in the ApplicationPool garbage collector
    if PassengerPoolIdleTime is set to 0. Fixes issue #858.
  • Fixed some process memory usage measurement bugs.
  • Fixed process memory usage measurement on NetBSD. Fixes issue #736.
  • Fixed a file descriptor leak in the Out-of-Band Work feature. Fixes issue #864.
  • The PassengerPreStart helper script now uses the default Ruby
    interpreter specified in the web server configuration, and no longer
    requires a ruby command to be in $PATH.
  • Updated preferred PCRE version to 8.32.
  • Worked around some RVM bugs and generally improved RVM support.
  • The ngx_http_stub_status_module is now enabled by default.
  • Performance optimizations.

Installing and testing 4.0.0 Release Candidate 6

Quick install/upgrade

Phusion Passenger Enterprise users can download the Enterprise version of 4.0 RC 6 from the Customer Area.

Open source users can install the open source version of 4.0 RC 6 with the following commands:

gem install passenger --pre

You can also download the tarball at Google Code.

In-depth instructions

In-depth installation and upgrade instructions can be found in the Installation section of the documentation. The documentation has been updated to cover 4.0 changes, including Enterprise features. You can view them online here:


We are excited about the final release. You can help us by testing RC 6 and reporting any bugs. Please submit bug reports to our bug tracker.

We at Phusion are regularly updating our products. Want to stay up to date? Fill in your name and email address below and sign up for our newsletter. We won’t spam you, we promise.