Phusion Passenger 4.0.45: major Node.js and Meteor compatibility improvements
Phusion Passenger 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.
Phusion Passenger is under constant maintenance and development. Version 4.0.45 is a bugfix release.
Phusion Passenger also has an Enterprise version which comes with a wide array of additional features. By buying Phusion Passenger Enterprise you will directly sponsor the development of the open source version.
Recent changes
- Major improvements in Node.js and Meteor compatibility. Older Phusion Passenger versions implemented Node.js support by emulating Node.js’ HTTP library. This approach was found to be unsustainable, so we’ve abandoned that approach and replaced it with a much simpler approach that does not involve emulating the HTTP library.
- Introduced support for sticky sessions. Sticky sessions are useful — or even required — for apps that store state inside process memory. Prominent examples include SockJS, Socket.io, faye-websocket and Meteor. Sticky sessions are required to make the aforementioned examples work in multi-process scenarios. By introducing sticky sessions support, we’ve much improved WebSocket support and support for the aforementioned libraries and frameworks.
- Due to user demand, GET requests with request bodies are once again supported. Support for these kinds of requests was removed in 4.0.42 in an attempt to increase the strictness and robustness of our request handling code. It has been determined that GET requests with request bodies can be adequately supported without degrading robustness in Phusion Passenger. However, GET requests with both request bodies and WebSocket upgrade headers are unsupported. Fixes issue #1092.
- [Enterprise] The Flying Passenger feature is now also available on Apache.
- Fixed some issues with RVM mixed mode support, issue #1121.
- Fixed Passenger Standalone complaining about not finding PassengerHelperAgent during startup.
- Fixed various minor issues such as #1190 and #1197.
- The download timeout for passenger-install-nginx-module has been increased. Patch by 亀田 義裕.
Installing or upgrading to 4.0.45
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Final
Phusion Passenger’s core is open source. PleaseIf 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.
Ruby Rogues 143: Phusion Passenger Enterprise with Hongli Lai and Tinco Andringa
We’ve been invited by Ruby Rogues to participate in a podcast about Phusion Passenger Enterprise. This podcast covers the following topics:
- Hongli Lai and Tinco Andringa Introductions
- Phusion Passenger introduction
- Rack
- Node.js, MeteorJS, Python Support
- Processes and Threads
- Ruby Rogues Episode #58 – Book Club: Working with Unix Processes with Jesse Storimer
- Ruby Enterprise Edition
- Smart Spawning
- Advantages of Phusion Passenger Enterprise
- Rolling Restarts
- Mass Deployment
- Passenger vs Unicorn
- Error Resistant Deploys
- Hosting
- DreamHost
- Apache, Nginx support
- Stability Issues
- Documentation and Support
Listen to the podcast at the Ruby Rogues website
Thanks Ruby Rogues for hosting us!
NPM needs our help, and why you should donate

NPM must be one of the most invaluable tools for Node.js users. It’s used by tons of users all around the world every second. But there have been various issues with the NPM registry lately. One thing is clear: running the NPM registry is not easy and requires a lot of administration time, effort and money. It is for this reason that Nodejitsu, the party who runs the NPM registry, has launched a funding campaign to improve the NPM registry infrastructure.
As active participants in the open source community, we fully understand how difficult it is to run such a service. The sheer amount of resources needed to properly run and maintain something like this, is easily underestimated by a lot of people. The hardware, the bandwidth, shouldn’t cost that much, should they? Once they’re in place, just configure a few things and the thing runs, right?
But setting up a reliable infrastructure and keeping it healthy is by no means a small task. Properly configuring a high-traffic cluster requires a lot of time and expertise. And there will always be unexpected problems. What happens if there’s a network problem? What happens if an OS upgrade broke things? What happens if there’s a disk failure? Even with all the automatic failover you configure, Murphey’s law will always find you. And when it does, you better be prepared and have the man power to solve the issues. Man power costs time and money.
One might think that Nodejitsu, being a commercial, VC-funded company can easily pay for this themselves. So why should anybody donate? Scalenpm.org explains this: their investors want their money to be used for making more money, not for providing free community services. All donations go toward running the NPM registry.
We all rely on NPM a lot. Even though NPM is open source, it is important not to equate open source with free. It is not free for the party that has to run and maintain it. So we believe it’s time to give something back as well, which is why we have donated. You may want to consider donating as well.
Meteor support for Phusion Passenger has been open sourced
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.
Installing
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 {
server_name www.foo.com;
root /webapps/leaderboard/public;
passenger_enabled on;
passenger_app_env development;
}
If you restart Nginx and visit http://www.foo.com/ 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 {
server_name www.foo.com;
root /webapps/leaderboard/bundle/public;
passenger_enabled on;
passenger_set_cgi_param MONGO_URL mongodb://localhost:3002/meteor;
passenger_set_cgi_param ROOT_URL http://www.foo.com;
}
}
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
Then:
server {
server_name www.foo.com;
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!
Phusion Passenger’s Node.js support has been open sourced
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.
SHA-3 extensions for Ruby and Node.js
A few days ago, NIST announced the winner of the SHA-3 competition: Keccak (prounced [kɛtʃak], ketchak). The researchers who authored Keccak released a reference implementation in C.
We’ve created Ruby and Node.js extensions for Keccak. Our extensions utilize the code from the official reference implementation and come with a extensive suite of unit tests. But note however that I do not claim to be a security expert. Feel free to review the code for any flaws.
Install with:
gem install digest-sha3
npm install sha3
We’ve strived to emulate the languages’ standard hash libraries’ interfaces, so using these extensions is straightforward:
require 'digest/sha3'
Digest::SHA3.hexdigest("foo")
and
var SHA3 = require('sha3');
var hash = SHA3.SHA3Hash();
hash.update('foo');
hash.digest();
Both libraries are MIT licensed. Enjoy!
Why does the world need SHA-3?
If you’re not a security researcher then you’ve undoubtedly asked the same questions as I did. What’s wrong with SHA-1, SHA-256 and SHA-512? Why does the world need SHA-3? Why was Keccak the winner?
According to to well-known security researcher Bruce Schneier, there’s nothing wrong with the SHA-2 family of hashing functions. However he likes SHA-3 because it’s completely different. SHA-1 and SHA-2 are both based on the Merkle–Damgård construction. It may be feasible to find a flaw in SHA-1 that also affects SHA-2. In contrast, Keccak is based on the sponge construction so any attacks on SHA-1 and SHA-2 will probably not affect Keccak. Indeed, it appears that NIST chose Keccak because it was looking for some kind of insurance in case SHA-2 would be broken. Many people commented that they expected Skein to win.
Do not hash your passwords
In any case, the following cannot be repeated enough. Do not use SHA-3 (or SHA-256, SHA-512, RIPEMD-160 or whatever fast hash) to hash passwords! Do not even use SHA-3 + salt to hash passwords. Instead, use a slow hash like bcrypt. As Coda Hale explained in his article, you’ll want the hash to be slow so you can defend against attackers effectively.