The Redis® database is often use for cache purpose with Rails deployments. Hence you might want to clear its content after each deployment. One solution could be to empty it in a postdeploy hook. Another solution can be to prefix the cache key with the build deployment ID provided by Scalingo.

The deployment ID is available in the SOURCE_VERSION during the build phase and CONTAINER_VERSION at runtime. More information about these variables.

With Ruby on Rails, configuring such cache is done using this single line:

config.cache_store = :redis_cache_store, {
    url: "#{ ENV['REDIS_URL'] }/0:#{ ENV['SOURCE_VERSION'] || ENV['CONTAINER_VERSION'] }"
}

By default, Scalingo for Redis® databases have a timeout.

If you don’t want to depend on the timeout of the server, you may want to change the client connection timeout. You can do it like this:

config.cache_store = :redis_cache_store, {
    url: "#{ ENV['REDIS_URL'] }/0:#{ ENV['SOURCE_VERSION'] || ENV['CONTAINER_VERSION'] }",
    connect_timeout: 1,
    read_timeout: 1,
    write_timeout: 1
}

If you want an automatic reconnection after the connection timed out, you should set the reconnect_attempts option:

config.cache_store = :redis_cache_store, {
    url: "#{ ENV['REDIS_URL'] }/0:#{ ENV['SOURCE_VERSION'] || ENV['CONTAINER_VERSION'] }",
    connect_timeout: 1,
    read_timeout: 1,
    write_timeout: 1,
    reconnect_attempts: 1
}

This simple trick will automatically invalidate the cache after each successful deployment. You’d certainly also want to enable Redis® cache mode on its Dashboard on Scalingo to avoid filling your Redis® database completely and tell Redis® to drop old and unused keys.