Boilerplate HTTP Server With Node.js

So you just finished developing your node.js application and you’re ready for the world to use it. Congrats. Now it’s time to decide how to host the application. In many cases you would use a turnkey cloud solution like HerokuOpenShift, or AppFog. These are great services, but what if you want to keep this in-house or you don’t want to shell out the dough for each resource separately? These costs can really add up, even with a non-resource intensive application. Today I’m going to talk about a production-ready boilerplate stack for serving node.js applications from a bare Linux (Ubuntu distro) install.

There are many ways to go about this, and the most popular is letting nginx handle the the http requests. This works well as it adds a separate layer to the stack for caching, websockets (with some effort), load balancing, and a basic http proxy. Again, this is a great setup, but for this I’d like to keep it all in the (node.js) family for the leanest and meanest setup possible while providing the same capabilities. Fortunately, nodejitsu has developed the node-http-proxy module. Alongside forever and proper server configurations, we can lay the foundation for a proper production-ready, secure server for web applications in a similar way you can create virtual hosts with the common LAMP stack.


I will not be talking about the actual linux commands or security practices that go into these steps, as that would exceed the scope of this article. For these purposes, we’re assuming you have a general understanding of node.js and network security and administration.

Users & Permissions

After spinning up a fresh server, the first thing necessary is to create 2 users, one with sudo/root privileges and the other with limited access to be responsible for running the application(s). Let’s call the sudo user devadmin and the other dev. This is important as each of these users will be responsible for specific tasks:

  • devadmin Responsible for starting, stopping, and restarting the proxy server. (permission for port 80 or 443)
  • dev Responsible for running the application(s). This user only has permissions for running the applications themselves.

With these users we can keep the server layer separate from the applications layer, creating an isolated and secure environment. Using creationix‘s nvm script, independent installations of node.js and npm can be installed and independently managed for each user in their respective home directories. forever should be installed globally for each user and lastly, http-proxy-server only needs to be installed for the sudo user, devadmin.

That’s it.

Directory Structure

This will be the home directory for dev:

For demonstration purposes I am using some-app-1 and some-app-2 as dummy apps. Obviously, you will have your own applications in place of these. Here is a break down:

  • apps/ Applications will be deployed to this directory. These are all owned by dev, of course.
  • logs/ Application specific logging. This directory will be specified in the forever command (as shown below).
  • bin/ Various start scripts. These scripts can be run after deployments and during server reboots (via /etc/init.d).
  • server.js HTTP proxy server configuration file. Owned by devadmin.

Among all of the files here, server.js and the shell scripts inside of the bin directory are the most interesting. They essentially are the backbone of this server. Here are the contents of each file:


server.js – (restricted access) Owned by devadmin, called via ~/bin/start-server.


bin/start-server – (restricted access) Owned by devadmin. Called in /etc/init.d/apps or manually.


bin/start-some-app-1 – Owned by dev, called via init.d script, deployment script, or manually. Call when you want to start or restart the application.


Finally, simply add a shell script to the init.d directory so the apps will be started automatically on startup. It can look like so:

/init.d/apps – This will automatically start server and apps on startup.



There you have it. A simple, yet scalable bare bones server built entirely in node.js. Now you are left with things like adding monitoring software, setting up iptables, and installing your storage system. Please checkout the documentation for http-proxy-server for more advanced configurations, as it’s quite feature packed.