<commit_before>---
title: Buildpacks
---

Buildpacks are a convenient way of packaging framework and/or runtime support
for your application.
For example, by default Cloud Foundry does not support Python, or a Python
framework like Django. Using a buildpack for Python and Django would allow you
to add support for these at the deployment stage.

When an application written using one of these languages and frameworks is
pushed, the required buildpack is automatically installed on the Cloud Foundry
Droplet Execution Agent (DEA) where the application will run.

Cloud Foundry has three system buildpacks: one each for [Java]
(https://github.com/cloudfoundry/java-buildpack), [Node.js]
(https://github.com/cloudfoundry/heroku-buildpack-nodejs), and [Ruby]
(https://github.com/cloudfoundry/cf-buildpack-ruby).

You can create [custom buildpacks](./custom.html) to add support for the
languages or frameworks of your choice.

Cloud Foundry stages application using buildpacks. Heroku developed the buildpack approach and made it available to the open source community.

Cloud Foundry uses buildpacks to transform user-provided artifacts into runnable applications.  The functionality of buildpacks varies, but many of them examine the user-provided artifact in order to properly download needed dependencies and configure applications to communicate with bound services.  Heroku developed the buildpack approach and Cloud Foundry embraces it.

**Cloud Foundry Buildpacks** --- When an artifact is pushed to Cloud Foundry, the system chooses a buildpack automatically. Buildpacks are designed such that they can examine the artifact and opt to process an artifact. For information about the built-in candidate buildpacks, see:

* [Java Buildpack][j]
* [Node.js Buildpack][n]
* [Ruby Buildpack][r]

If you have an application that uses a language or framework that Cloud Foundry
buildpacks do not support, there may be a third-party or community-developed
buildpack that you can use. You can also customize existing buildpacks or write your own. To use a buildpack that is not built-in to Cloud Foundry, you specify the URL of the buildpack when you push an application, using the `-b` qualifier or the `buildpack: ` manifest key.

* [Cloud Foundry Community Buildpacks][c] --- This page has links to buildpacks contributed by members of the Cloud Foundry Community.
* [Heroku Third-Party Buildpacks][h] --- This page has links to buildpacks developed for Heroku, which may (but have not been verified to) work with Cloud Foundry.
* [Custom Buildpacks][u] --- See this page for information about writing a custom buildpack.

[c]: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Buildpacks
[h]: https://devcenter.heroku.com/articles/third-party-buildpacks
[j]: ./java-tips.html
[n]: ./node-tips.html
[r]: ./ruby-tips.html
[u]:../../buildpacks/

## <a id='auto-vs-manual'></a>Auto-configuration of Service Connections##

After you create a service instance and bind it to your application, you
configure the application to dynamically fetch the credentials for your
service.
These credentials are stored in the `VCAP_SERVICES` environment variable.

There are generally two methods for these consuming credentials.

* **Auto-configuration**: Some buildpacks create a service connection for you
by creating additional environment variables, updating config files, or passing
system parameters to the jvm.
* **Manual**: [Parse the JSON yourself](../devguide/deploy-apps/environment-variable.html#app). Helper libraries are
available for some frameworks.

| Runtime    | Framework  | Binding Strategy         |
| :--------- |:---------- |:-------------            |
| JVM / Java | <li>[Grails][g] <li>[Play Framework][p] <li>[Spring][s] | Auto-configuration<br/>Manual |
| Ruby       | <li>[Rack, Rails, or Sinatra](./ruby-service-bindings.html) |  [Limited auto-configuration support for Rails only](./ruby-service-bindings.html#auto-config)<br/>Manual |
| Javascript | <li>[Node.js](./node-service-bindings.html) | Manual |

[g]: ./grails-service-bindings.html
[p]: ./play-service-bindings.html
[s]: ./spring-service-bindings.html

## <a id='java'></a>Java, Grails, Play and Spring ##

* [Deploying Java applications](./java-tips.html)
* [Configure Service Connections for Grails](grails-service-bindings.html)
* [Configure Service Connections for Play](play-service-bindings.html)
* [Configure Service Connections for Spring](spring-service-bindings.html)

## <a id='node'></a>Node.js ##

* [Deploying Node.js applications](./node-tips.html)
* [Configure Service Connections for Node](node-service-bindings.html)

## <a id='ruby'></a>Ruby ##

* [Deploying Ruby applications](./ruby-tips.html)<commit_msg>fix link<commit_after>---
title: Buildpacks
---

Buildpacks are packages that provide framework and runtime support for your 
applications.
For example, by default Cloud Foundry does not support Python, or a Python
framework like Django. Using a buildpack for Python and Django would allow you
to add support for these at the deployment stage.

When you push an application, Cloud Foundry automatically installs the required 
buildpack on the Droplet Execution Agent (DEA) where the application needs to run.

Cloud Foundry has three system buildpacks: one each for [Java]
(https://github.com/cloudfoundry/java-buildpack), [Node.js]
(https://github.com/cloudfoundry/heroku-buildpack-nodejs), and [Ruby]
(https://github.com/cloudfoundry/cf-buildpack-ruby).

You can create [custom buildpacks](./custom.html) to add support for the
languages or frameworks of your choice.

Heroku developed the buildpack approach and made it available to the open source community.

Cloud Foundry uses buildpacks to transform user-provided artifacts into runnable applications.  The functionality of buildpacks varies, but many of them examine the user-provided artifact in order to properly download needed dependencies and configure applications to communicate with bound services.  Heroku developed the buildpack approach and Cloud Foundry embraces it.

**Cloud Foundry Buildpacks** --- When an artifact is pushed to Cloud Foundry, the system chooses a buildpack automatically. Buildpacks are designed such that they can examine the artifact and opt to process an artifact. For information about the built-in candidate buildpacks, see:

* [Java Buildpack][j]
* [Node.js Buildpack][n]
* [Ruby Buildpack][r]

If you have an application that uses a language or framework that Cloud Foundry
buildpacks do not support, there may be a third-party or community-developed
buildpack that you can use. You can also customize existing buildpacks or write your own. To use a buildpack that is not built-in to Cloud Foundry, you specify the URL of the buildpack when you push an application, using the `-b` qualifier or the `buildpack: ` manifest key.

* [Cloud Foundry Community Buildpacks][c] --- This page has links to buildpacks contributed by members of the Cloud Foundry Community.
* [Heroku Third-Party Buildpacks][h] --- This page has links to buildpacks developed for Heroku, which may (but have not been verified to) work with Cloud Foundry.
* [Custom Buildpacks][u] --- See this page for information about writing a custom buildpack.

[c]: https://github.com/cloudfoundry-community/cf-docs-contrib/wiki/Buildpacks
[h]: https://devcenter.heroku.com/articles/third-party-buildpacks
[j]: ./java-tips.html
[n]: ./node-tips.html
[r]: ./ruby-tips.html
[u]: ./custom.html

## <a id='auto-vs-manual'></a>Auto-configuration of Service Connections##

After you create a service instance and bind it to your application, you
configure the application to dynamically fetch the credentials for your
service.
These credentials are stored in the `VCAP_SERVICES` environment variable.

There are generally two methods for these consuming credentials.

* **Auto-configuration**: Some buildpacks create a service connection for you
by creating additional environment variables, updating config files, or passing
system parameters to the jvm.
* **Manual**: [Parse the JSON yourself](../devguide/deploy-apps/environment-variable.html#app). Helper libraries are
available for some frameworks.

| Runtime    | Framework  | Binding Strategy         |
| :--------- |:---------- |:-------------            |
| JVM / Java | <li>[Grails][g] <li>[Play Framework][p] <li>[Spring][s] | Auto-configuration<br/>Manual |
| Ruby       | <li>[Rack, Rails, or Sinatra](./ruby-service-bindings.html) |  [Limited auto-configuration support for Rails only](./ruby-service-bindings.html#auto-config)<br/>Manual |
| Javascript | <li>[Node.js](./node-service-bindings.html) | Manual |

[g]: ./grails-service-bindings.html
[p]: ./play-service-bindings.html
[s]: ./spring-service-bindings.html

## <a id='system'></a> Working with System Buildpacks ##

Refer to 

### <a id='java'></a>Java ###

Use the Java buildpack to work with Java, Grails, Play or Spring.

* [Deploying Java applications](./java-tips.html)
* [Configure Service Connections for Grails](grails-service-bindings.html)
* [Configure Service Connections for Play](play-service-bindings.html)
* [Configure Service Connections for Spring](spring-service-bindings.html)

### <a id='node'></a>Node.js ###

* [Deploying Node.js applications](./node-tips.html)
* [Configure Service Connections for Node](node-service-bindings.html)

### <a id='ruby'></a>Ruby ###

* [Deploying Ruby applications](./ruby-tips.html)
{'fraction_non_alphanumeric': 0.1076923076923077, 'fraction_numerical': 0.0, 'mean_word_length': 4.515506143943827, 'pattern_counts': {'":': 0, '<': 35, '<?xml version=': 0, '>': 35, 'https://': 10, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1021498', 'n_tokens_mistral': 2663, 'n_tokens_neox': 2559, 'n_words': 1045}