Pivotal Knowledge Base


Understanding Pivotal Cloud Foundry® Redis Provisioning, Deprovisioning, Binding, Unbinding of Dedicated-VM Plan Instances


  • Pivotal Cloud Foundry 1.7.x
  • Redis all versions 


This article aims to:

  • Provide a better understanding of how the Pivotal Cloud Foundry (PCF) Redis handles service instances and bindings
  • Provide diagnostic tooling around identifying the root cause of inconsistencies between Cloud Foundry (CF) and the PCF Redis service broker 

Basic Terms

PCF Redis offers Redis-as-a-Service to application developers. In line with Cloud Foundry services specification, developers can: 




cf create-service

Make a Redis Database available for use within Cloud Foundry.
With the Dedicated-VM Plan, the Redis Service Instances are created at deployment time so that it is up and running prior to the provision. However, provision is when Cloud Foundry finds out about the Redis Instance




cf bind-service

Make the credentials of a provisioned Redis Instance available to an app in their Cloud Foundry, also known as a service binding. This step must be preceded by `cf create-service`




cf unbind-service

Delete an existing binding, i.e. remove the credentials of a previously bound Redis Instance from an app in their Cloud Foundry and delete the credentials




cf delete-service

Release a previously provisioned Redis Instance from their Cloud Foundry. If Cloud Foundry has an app bound to the instance, the binding must be deleted first.
With the Dedicated-VM Plan, the instance will simply be flushed and released into a pool of instances for future use.

Cloud Foundry fulfills the above requests by interacting with the Redis Service Broker. 

The PCF Redis ecosystem is packaged as a BOSH release and deployed as a BOSH deployment. 


How does PCF Redis work?

A PCF Redis BOSH deployment comprises of:

  • One Broker VM that fulfills Cloud Foundry requests, and
  • A number of Redis Instances
    The number of instances is equal to the maximum number of Dedicated-VM Instances that the operator wishes to make available. When the tile is first installed, these VMs are spun up, with an up-and-running Redis ready to be used. They are not provisioned by an app developer, meaning that Cloud Foundry does not know about them. As they are not provisioned, they are also not bound to anything; they are simply on standby. In comparison, instances of Shared-VM do not exist before they are provisioned through a cf create-service request. 

PCF Redis versions up to and including 1.7.x offer two plans: Shared-VM and Dedicated-VM.

Instances of a Shared-VM plan are all Redis processes that run on the Broker VM.

Instances of Dedicated-VM plan are Redis processes, each running on its own VM. In fact, when a Dedicated-VM is provisioned in Cloud Foundry because of a cf create-service request, it will claim one of the standby instances.

For more details on how PCF Redis works, please see the Documentation on PCF Redis architecture


A binding is a Cloud Foundry term that describes making the credentials of a cf-provisioned service instance available to a cf-pushed app.

For a service instance to be bound to an app, the service instance must be provisioned.

However, the opposite is not a requirement. A provisioned service instance need not be bound to an app.

An app binding is not the only way of getting the credentials of a service instance. CF service keys work in the same way; they retrieve the credentials from the broker in the same way as a binding. They simply do not require an app to consume them. As far as the Redis Broker is concerned, a binding and a service key to a provisioned instance are exactly the same things.

What if things go wrong?

From the above, we can see that there are 4 places where information is held:

  • Cloud Foundry knows what Redis Instances and Bindings are currently in place
  • The Redis Broker VM:
    • Knows which of the Dedicated VMs correspond to provisioned services
    • Knows which of the Dedicated-Node Instances (BOSH) are still available to be provisioned (Cloud Foundry)
    • Knows what Bindings, if any, exist on the provisioned Dedicated Redis Instances.
    • Has a directory where all the instances of the Shared-VM Plan (if any are provisioned) keep their data (redis.conf and dump.rdb files for example)
  • BOSH knows what VMs were deployed as part of the PCF Redis ecosystem, but not their Cloud Foundry status. I.e., BOSH does not know whether a VM is provisioned or not, bound or not
  • The users’s view of what Redis Instances are in use

In rare occasions, there are discrepancies between those sources of truth.

In the vast majority of these cases, the discrepancy is between Cloud Foundry and the Redis Broker. BOSH does not know at all about any of the following:

  • Shared-VM Instances
  • Bindings of any type
  • The CF status of a Dedicated-Node VM 

Remember that a Dedicated-VM Instance must be provisioned in order to be part of a Binding. However, a provisioned instance is not necessarily the part of a binding.

We list a few scenarios below, together with commands that can help diagnose discrepancies between Cloud Foundry and the Redis Broker.


How to Backup and Restore Redis Instances

Detailed instructions on how to backup and restore Redis Instances can be found here




How to access the variables


The name of the Redis Instance that is under troubleshooting

cf services


The guid of the Redis Instance that is under troubleshooting

cf service SERVICE_INSTANCE --guid


The Broker URL

cf service-brokers | grep p-redis


The Broker username

Operator can get it from the manifest



The Broker password

Operator can get it from the manifest




Powered by Zendesk