Cache Service Settings in the Boxfile

Last Updated February 2015

Cache services are caching mechanisms available on Pagoda Box. The following documentations covers available Boxfile config options for cache services. The Boxfile is a yaml config file that houses all configuration related to your app’s deployment and infrastructure and allows you to custom-configure your app's environment. After reading this doc, you will be familiar with:

  • Configuring cache services
  • What options are available in the Boxfile

Overview of Cache Boxfile Settings YAML

    name: cache-name
    type: redis
    version: 2.8
    stability: production

Cache Service Config Options

Redis Settings

You can see all available Redis settings in the Redis Settings in the Boxfile doc.

Memcached Settings

You can see all available Memcached settings in the Memcached Settings in the Boxfile doc.


Creating a custom name for your cache service will act as a quick reference for your cache in your App Dashboard. If you have multiple cache services, custom names will come in handy. If you do not define a custom name, Pagoda Box will generate a cache name for you.

Note: This will not set the "name" connection credential for your service.

name YAML

    name: buela

This one is fairly self-explanatory. What type of cache you need completely depends on your app. The following cache types are available:

  • memcached

  • redis

You Must Include a Cache Type

A cache type must be included in your Boxfile config. If no type is specified, the service will not be created on deploy.

type YAML

    type: redis

The "version" config specifies which version of the cache type to use. Only the major and minor version should be specified. The patch level is determined by the "stability" config.

Cache Version Defined on Create

Due to version compatibility constraints, cache versions cannot be changed after the service is created. To use a different version, you'll have to create a new cache service.

version YAML

    type: redis
    version: 2.8

The "stability" config allows you to specify which patch level of your service "version" you'd like to use. There are three stability options:

  • alpha

  • beta

  • production

Pagoda Box assigns the patch levels to each stability setting. When the patch levels are updated, applications will be updated automatically on deploy.

Alpha & Beta Versions

Alpha and beta versions are for bleeding edge developers who want nothing but the latest releases of languages. Please note however, Pagoda Box does not guarantee the compatibility of these versions with the Pagoda Box infrafstructure or your app. These are "builds-in-progress," and using them is done at your own risk. Pagoda Box will only provide support for infrastructure-compatibility issues related to these specific versions. No app-compatibility support will be provided.

stability YAML

    type: redis
    version: 2.8
    stability: production

Automated Environment Variables

Anytime you create a cache, we automatically create Environment Variables for each of your database credentials.

Boxfile Modifications Only Take Affect After a New Build

Whenever changes are made to a cache service's configuration in the Boxfile, those changes will not apply until the service is rebuilt. By default, cache services are not rebuilt on deploy. However, there are three options for rebuilding your cache services:

Enable Rebuild on Deploy

In your app dashboard, under Dev Config > Code Deployment, you can enable the option to have data services rebuild on deploy whenever changes to the service's Boxfile config are detected.

Rebuilding data services on deploy will increase deploy times, but only when changes to the service's config are detected.


Any time you scale a cache, a new instance or instances are provisioned, data is migrated (if possible), requests routed to the new instance(s) and old instances decommissioned. The new instances are built using the modified settings in your Boxfile.


In your dashboard, click on your database service to expand it's options. Each data service has a "Repair" option.

"Repairing" your service will provision a new instance (or instances) based on the settings in your Boxfile, migrate data to the new instance (if possible), then reroute requests away from the old instance to the new.

New Builds Require Data Migrations

Data migrations are required during a rebuild. Your service will temporarily go offline during the migration process. The Data Migrations During Scaling & Repairs doc has more information.

If you have any questions, suggestions, or corrections, let us know.