HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
phusion
passenger
C++2010–2026
phusion / passenger

passenger

A fast and robust web server and application server for Ruby, Python and Node.js

12Distinct people
25Mentions
0Explicit recommenders
5.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A fast and robust web server and application server for Ruby, Python and Node.js

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year25 dated mentions

Observed mentions: 2010-06-08 15:47:35 UTC to 2026-06-09 18:23:39 UTC.

0369122010-01-01 00:00:00 UTC to 2011-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20102011-01-01 00:00:00 UTC to 2012-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 11 mentions; 4 submissions, 7 comments2014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 3 mentions; 2 submissions, 1 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20102010-01-01 00:00:00 UTC2011-01-01 00:00:00 UTC202
20112011-01-01 00:00:00 UTC2012-01-01 00:00:00 UTC202
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC202
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC1147
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC202
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC202
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC000
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC000
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC321
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC000
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

What Hacker News says

25 sources
Another alternative is to migrate to Modern C++. I just did a quick look through the code base. https://github.com/phusion/passenger/blob/stable-5.3/src/cxx... Has some issues. There are pointers everywhere, even a void* * It does not use RAII to manage resources, instead there a a bunch of raw pointer with sizes and a manually called free function void freeAESEncrypted(AESEncResult &aesEnc); Just from this brief look, it does not at all surprise me that the development velocity is suffering. Joel's article on why you should never rewrite software is worth mentioning. There is probably a lot of institutional knowledge that is embedded in the code which will be lost if you convert to Go. A better alternative might be to incrementally update the code to C++17 following C++ best practices https://github.com/isocpp/CppCoreGuidelines. That way
Read the rest
you always have a working product, that has the features and performance that people have come to expect, while at the same time you are eliminating technical debt and increasing development velocity. In regards to the question about networking libraries all conflicting with each other, it is about to get better. The C++ committee will standardize a C++ Networking library in the near future. The good news is that it is based on asio https://think-async.com/ and asio is tracking the evolving standard. Most new C++ networking libraries are also standardizing on asio.
In Migrating Passenger from C++ to Go?
> The first example looks nothing like parsing a specific cookie. It merely sanitizes the cookie headers a little, but it doesn't extract out a specific cookie to use as cache key. You say you don't parse a specific cookie, but doesn't extract a specific cookie as a cache key? The blog post says the opposite: > We modified Passenger to parse cookies, and to vary turbocache responses based on the value of this user_id cookie. We invoke Passenger like this: passenger start --vary-turbocache-by-cookie user_id In other words: parse the user_id cookie. The mentioned commit even adds a ~250 LoC file (ext/common/ServerKit/CookieUtils.h) to do cookie parsing: https://github.com/phusion/passenger/commit/a760649cd79fde43... --- Anyway, what you're getting at is that Phusion only parses a certain value from the cookie and then uses it as a custom Va
Read the rest
ry header, whereas the examples I linked to clean up the Cookie header and then varies on that cleaned up Cookie header. That boils down to exactly the same thing. P.S.: downvoting? Not very nice.
In Researching a new form of HTTP caching optimization
Phusion Passenger author here. See https://github.com/phusion/passenger/issues/1286 for details. In short: Phusion Passenger sometimes spawns application processes (e.g. during startup). This spawning happens through bash. Some environment variables are set according to certain HTTP headers' values. We've been hoping the entire day that bash is going to be fixed "any time now", but the fix still isn't released. If it's still vulnerable by tomorrow we'll release a temporary workaround that fixes it inside Phusion Passenger, by not setting those environment variables. However this workaround will break apps that relied on it. Furthermore, this workaround will have no effect on any other software which may be vulnerable. The core problem is bash. Until bash is fixed, there's no way to get rid of this vulnerability completely. Please note tha
Read the rest
t Shellshock+Phusion Passenger does not grant you root access. Phusion Passenger lowers privilege before calling bash. In the mean time, you can lower your risk by configuring a static process pool (passenger_min_instances N, passenger_max_pool_size N). That way you will reduce process spawning in Phusion Passenger to a minimum. [EDIT] Looks like the bash patch is released in Debian 7. Other OSes may soon follow.
In Security Advisory: Phusion Passenger and the CVE-2014-6271 Bash Vulnerability
At least with Linux I don't have to wait 6 hours for all my software to finish compiling. Think about all the trees that are unnecessarily cut down because of all that compiling. And support for Linux is much easier to get than support for OpenBSD. Also, this is why anybody would want to use Passenger over Puma: https://github.com/phusion/passenger/wiki/Puma-vs-Phusion-Pa... (or vice versa, for that matter) TLDR: Passenger takes a more holistic and integrated approach and is a lot easier to use. It has superior management and administration tools, superior robustness features, superior security features (e.g. sandboxing through user switching), better documentation, uses less memory, etc.
In Install Ruby 2.1, Rails and Passenger on Ubuntu
Passenger runs in Nginx. The architecture is very similar to plugging Node.js apps to Nginx, except now all that plugging is taken care for you. There are also a bunch of features that you get compared to straight reverse proxying with Nginx. From https://github.com/phusion/passenger/wiki/Node.js (that document is slightly outdated because of recently developments, we're updating it): * Multitenancy - Run multiple Node.js applications on a single server easily and without hassle. With vanilla Node, you have to remember where your ports are configure Nginx reverse proxies. With Phusion Passenger, you create a virtual host, set `passenger_enabled on`, and you're done. * Process management and supervision - Node.js processes are automatically started, and automatically restarted when they crash. * Statistics and insight - Phusion Passenger p
Read the rest
rovides tools for inspecting the applications' status, such what requests they're currently processing, how many requests they've processed. * Scaling - Based on current traffic, Phusion Passenger can spawn more Node.js processes, or spin down some existing Node.js processes. * Load balancing - Phusion Passenger automatically load balances traffic across Node.js process. The load balancing mechanism utilizes a smart "first-available" selection algorithm to avoid problems caused by slow requests. Nginx's proxy balancer does not do this by default. * I/O security - Node.js is automatically put behind a buffering web server, such as Apache or Nginx, which preprocesses and postprocesses HTTP requests and responses. This protects the Node.js app against slow-client attacks such as Slowloris. It also provides a secure environment which sanitizes HTTP headers, to protect against vulnerabilities in the app's HTTP parser. * System security - Node.js processes are automatically started as the user which owns the app. This allows the OS to separate their privileges, so that a vulnerability in one app does not affect another. * Static file acceleration - Static files are directly served by the web server (Apache/Nginx), not by Node.js. This offloads the Node.js application from handling those things. * System integration and less moving parts - Phusion Passenger fully integrates Node.js with the web server (Apache/Nginx), so that in most cases the administrator only has to deal with the web server and with centralized Phusion Passenger management tools, instead of dealing with each app individually. Note that the integration we talk about here pertains to usability only. Under the hood, each Node.js application is still its own OS process, and does not run in the web server's address space.
In Phusion Passenger's Node.js support has been open sourced
I know of several large users of Python + Phusion Passenger. Globo.com, one of the largest media companies in Brazil, runs Django on Phusion Passenger on some of their sites. There was also a site that monitors the forest firefighting progress in California, that runs on Python + Phusion Passenger. Unfortunately I forgot its name. We run Graphite (a Django app) on Phusion Passenger on our internal servers. By the way, we open source Node.js support in 4.0.16. Previously it was only available in the Enterprise variant. You can learn more at https://github.com/phusion/passenger/wiki/Node.js
In Debian and Ubuntu packages for Phusion Passenger
The point of serving Node through Phusion Passenger is not performance, but supervision, stability, robustness, security, multitenancy, etc. Although Phusion Passenger can increase performance by load balancing requests between multiple nodes. Please see https://github.com/phusion/passenger/wiki/Node.js for reasons to use Phusion Passenger with Node. The cluster module is great, but it requires you to manage your processes yourself and to write your own load balancer. Phusion Passenger provides all this functionality for you for free, through a C++ core.
In Puma, a fast concurrent web server for Ruby

Showing the 15 most recent of 25 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.