Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have set up a passenger + nginx setup and I plan to offer a free non-commercial hosting (or in fact on the fly deployment) for rack-based frameworks (e.g. camping, sinatra).

I am facing an "issue" with passenger. For each application you need to configure nginx.conf (it would be the same with apache so it is not an nginx issue) with:

server {
passenger_base_uri /app1;
passenger_base_uri /app2;
passenger_base_uri /app3;

Now this is not inherently bad as, in theory, I could allow a user to run just one app on his webspace but even in this case I need to create a new server directory on nginx e.g. (

As this will mainly be used to deploy apps the behavior I am looking at is more the possibility to auto map several apps (e.g. app1, app2, app3, app4) under the same server (your without having to update the nginx or apache file each time.

This seems to be a limitation in passenger. As such I am thinking about an alternative with lighttpd and fastcgi.

Would this allow immediate deployment without touching the lighttpd config file e.g. I create a new directory with app2 and it will run immediately ? What is your experience in performance difference between passenger + nginx vs. lighttpd + fastcgi ? thanks in advance

scenario details: on nginx + passenger - user cannot add a new sub-folder and run another sinatra/camping app without declaring the path on nginx.conf and restarting the server;

wished behavior with the new setup: - user can add a new folder with a new app and it would run on lighttpd+fcgi without any extra configuration of the web server;

share|improve this question

I'd take the third option -- nginx with fastcgi. It's pretty trivial to configure an nginx vhost using an included directory with all the sub-paths you want routed to each app, and automating the creation of the Rack process (running under daemontools) on first push (along with the rest of the stuff that needs to be done) is a fairly simple matter of programming.

share|improve this answer
what I think that was not an option. what you suggest is a reverse proxy with hundreds of thin / mongrel instances running on the background ..too many moving parts. The option was between nginx and passenger OR lighty and fastcgi (no reverse proxies with thins and daemontools). That was 2005-2006 deployment. – devnull Apr 10 '12 at 2:34
legacy(n): A pejorative term used in the computing industry to mean "it works". – womble Apr 10 '12 at 6:26
yes it works but does it work well ? you can also have thin -port 80 and it works fine but hardly a good solution if you want to host more than one site :) – devnull Apr 10 '12 at 17:35
It works well enough for the likes of – womble Apr 10 '12 at 20:54

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.