Is redis on Heroku possible without an addon?

Question

I'm looking into using Heroku for a PHP app that uses Redis. I've seen the various addons for redis. With Redis To Go, for example, you can use an environment variable $_ENV['REDISTOGO_URL'] in your PHP code, as the URL of the Redis Server.

Most of these add ons have their own pricing schemes which I'd like to avoid. I'm a little confused about how heroku works. Is there a way that I can just install Redis on my own Dynos without the addons?

Like for example, have one worker dyno that acts as a server, and another that acts as a client? If possible, how would I go about:

1. Installing and running the redis server on a Dyno? Is this just the same as installing on any other unix box? Can I just ssh to it and install whatever i want?

2. Have one Dyno connect to another with an IP/port via TCP? Do the worker dynos have their own reference-able IP addresses or named URLS that I can use? Can I get them dynamically from PHP somehow?

The php code for a redis client assumes there is a host and port that you can connect to, but have no idea what it would be?

$redis = new Predis\Client(array(
        "scheme" => "tcp",
        "host" => $host, //how do i get the host/port of a dyno? 
        "port" => $port));

Answer 1

Running redis on a dyno is an interesting idea. You will probably need to create a redis buildpack so your dynos can download and run redis. As "redis has no dependencies other than a working GCC compiler and libc" this should be technically possible.

However, here are some problems you may run into:

1. Heroku dynos don't have a static IP address

   "dynos don’t have static IP addresses .. you can never access a dyno directly by IP"

   Even if you set up and run Redis on a dyno I am not aware of a way to locate that dyno instance and send it redis requests. This means your Redis server will probably have to run on the same dyno as your web server/main application.

   This also means that if you attempt to scale your app by creating more web dynos you will also be creating more local redis instances. Data will not be shared between them. This does not strike me as a particularly scalable design, but if your app is small enough to only require one web dyno it may work.

2. Heroku dynos have an ephemeral filesystem

   "no files that are written are visible to processes in any other dyno and any files written will be discarded the moment the dyno is stopped or restarted"

   By default Redis writes its RDB file and AOF log to disk. You'll need to regularly back these up somewhere so you can fetch and restore after your dyno restarts. See the documentation on Redis persistence.

3. Heroku dynos are rebooted often

   "Dynos are cycled at least once per day, or whenever the dyno manifold detects a fault in the underlying hardware"

   You'll need to be able to start your redis server each time the dyno starts and restore the data.

4. Heroku dynos have 512MB of RAM

   "Each dyno is allocated 512MB of memory to operate within"

   If your Redis server is running on the same dyno as your web server, subtract the RAM needed for your main app. How much Redis memory do you need?

   Here are some questions attempting to estimate and track Redis memory use:

   • Redis: Database Size to Memory Ratio?
   • Profiling Redis Memory Usage

--

Overall: I suggest reading up on 12 Factor Apps to understand a bit more about heroku's intended application model.

The short version is that dynos are intended to be independent workers that can be easily created and discarded to meet demand, and that dynos access various resources to read or write data and serve your app. A redis instance is an example of a resource. As you can see from the items above, by using a redis add-on you're getting something that's guaranteed to be static, stable, and accessible.

Reading material:

1. http://www.12factor.net/ - specifically Processes and Services
2. The Heroku Process Model
3. Heroku Blog - The Process Model