One weird trick to keep your Rails application away from prying eyes during development
By David Jones /

Hackers HATE it.

Have you ever stopped to consider that running

rails server

in development mode is a security risk?

Let’s say you are grooving on some Rails code in a coffee shop or co-working space and fire up rails server, as you do.

Whoa buddy, Put the brakes on! Anyone on that network can now potentially see what you are doing, or even interfere with your dev process by visiting your computer’s IP address with a web browser.

Check your network IP address in Network monitor or whatever your crazy OS calls it. Let’s say you are at

Now try visiting that from the browser of another computer on the same network like so:

No way dude, this thing is hush hush, and under NDA! This is an old unpatched version of Rails! All the security and access controls aren’t setup yet! Rack::Bug, Rails Footnotes, and New Relic are exposed to the whole place!

While this behavior may be acceptable and even desirable at times (internal testing team behind a company firewall?), it is a bad default.

Running rails server by default starts up a web server on port 3000 of This means all interfaces will accept a connection.

Luckily, there is a way to start the rails server to only listen to requests that come directly from your computer:

rails server —binding=

All the benefits and none of the drawbacks, the only problem is there really isn’t a good way to make this the default (you know, so you’ll actually remember to do it every time).

My preferred solution is to add a line like this to my ~/.profile:

alias rails-server='rails server —binding='

and just use that all the time.

Actually, to make it sticky for me, I’ve aliased it to something ridiculously short, since I use it so often:

alias rs='rails server —binding='
alias rc='rails console'

However, there are ways to make it always do this on a per-project basis through such hackery as demonstrated in this StackOverflow post.

But I believe it is a brittle approach to reach into Rails internals like this, and it may cause unexpected consequences in production.

This is definitely not the end-all-solution for everything, but every little bit helps. Other things worth considering to secure your development machine:

Go forth and compute with confidence!