Re: VCAP_APPLICATION in the V3 Cloud Foundry API

Nicholas Calugar

Thanks for all your input. Upon seeing how the buildpacks use VCAP_APPLICATION, I’m thinking we want to leave it as is and potentially add a few new top level environment variables.





With the already present

CF_INSTANCE_INDEX, we could encourage buildpacks to build the identifier using all ENV variables:


Nicholas Calugar

Cloud Foundry API Product Manager

Pivotal Software, Inc.

On Mon, May 02, 2016 at 2:36 PM Sabha Parameswaran

mailto:Sabha Parameswaran <sabhap(a)>
Agree with Dan.

Currently most APM vendors use the VCAP_APPLICATION env variable for mapping and keeping track of a specific instance using the instance guid, instance index, app guid fields. Changing it would affect the buildpacks and extensions.

Sample for AppD APM:


$(ruby -e "require 'json' ; a = JSON.parse(ENV['VCAP_APPLICATION']);

puts \"#{a['application_name']}









Some of these complex expressions might become simpler, as long as the values still come through with different names. 

So, as long as the current set of values continue to exist and either in flat or easy to grab from ENV, I am okay with that.



On Mon, May 2, 2016 at 2:19 PM, Mike Youngstrom


I have a few customers that grab that instance index to aid in monitoring and logging and to self identify in certain situations.  Is there an issue with continuing to expose the instance index?

I don't know anything about v2 vs v3 apis.  Would VCAP_APPLICATION continue to work for apps pushed using the v2 api and only have this new value if pushed using the v3 api?


On Mon, May 2, 2016 at 2:49 PM, Daniel Mikusa


I know some of the build packs will look at application name and use that for configuration of some of the APM agents (NewRelic, AppDynamics, etc..).  


The PHP build pack does this too.

As long as that info is exposed somewhere, it would be OK.


On Mon, May 2, 2016 at 4:34 PM, john mcteague


While I dont use this directly, my first reaction is some libraries such as Spring Cloud Connectors depend on this to identify that an app is running in CF, and we rely heavily on Spring Cloud Connectors.

That being said, assuming there are alternative variable that uniquely identify CF, the library authors could key off that instead.

On Mon, May 2, 2016 at 9:28 PM, Nicholas Calugar


Hi CF-Dev,

The CAPI team is working hard to get to MVP for V3 of the Cloud Foundry API. You can follow along by visiting our documentation and tracker:

We'd like to get some feedback from the community regarding VCAP_APPLICATION, an environment variable provided to applications running on Cloud Foundry. In V3, an application contains 1 or more processes that can be scaled independently, so VCAP_APPLICATION doesn't quite fit.

Do you have any use cases around VCAP_APPLICATION that you could share? Are there Cloud Foundry operators / users that would like to get rid of this all together? Our current plan was to do something like below, but wanted to hear from the community first.


  "space": {

    "guid": "682e10a0-6f3a-4a9f-b52c-f508b2bd99c6",

    "name": "ncalugar-a1"


  "application": {

    "guid": "<v3-app-guid>",

    "name": "nickdora"

    "version": "<app-version-guid>"


  "process": {

    "guid": "<v3-proc-guid>",

    "type": "web",

    "ports": [8080,8081]


  "route_mappings": [


      "guid": "<v3-route-mapping-guid>",

      "uri": "

      "port": 8080



      "guid": "<v3-route-mapping-guid>",

      "uri": "




  "limits": {

    "fds": 16384,

    "mem": 1024,

    "disk": 4096






Sabha Parameswaran

Platform Engineering, Cloud Foundry

Pivotal, Inc.


Join to automatically receive all group messages.