Managing Custom Buildpacks
Page last updated:
This topic describes how an admin can manage additional buildpacks in Cloud Foundry. If your application uses a language or framework that the Cloud Foundry system buildpacks do not support, you can:
- Write your own buildpack
- Customize an existing buildpack
- Use a Cloud Foundry Community Buildpack
- Use a Heroku Third-Party Buildpack
Note: You must be an administrator for your Cloud Foundry org to run the commands discussed in this section.
To add a buildpack, run:
$ cf create-buildpack BUILDPACK PATH POSITION [--enable|--disable]
The arguments to cf create-buildpack specify the following:
buildpack specifies the buildpack name.
path specifies where to find the buildpack. The path can point to a zip file, the URL of a zip file, or a local directory.
position specifies where to place the buildpack in the detection priority list. See Buildpack Detection.
enable or disable specifies whether to allow apps to be pushed with the buildpack. This argument is optional, and defaults to enable. While a buildpack is disabled, app developers cannot push apps using that buildpack.
To confirm that you have successfully added a buildpack, run
The following example shows the output from running the
cf buildpacks command after the administrator added
a Python buildpack:
$ cf buildpacks Getting buildpacks... buildpack position enabled locked filename ruby_buildpack 1 true false buildpack_ruby_v46-245-g2fc4ad8.zip nodejs_buildpack 2 true false buildpack_nodejs_v8-177-g2b0a5cf.zip java_buildpack 3 true false buildpack_java_v2.1.zip python_buildpack 4 true false buildpack_python_v2.7.6.zip
$ cf rename-buildpack BUILDPACK_NAME NEW_BUILDPACK_NAME
For more information on renaming a buildpack, see the CLI documentation.
$ cf update-buildpack BUILDPACK [-p PATH] [-i POSITION] [--enable|--disable] [--lock|--unlock]
For more information on updating a buildpack, see the CLI documentation.
$ cf delete-buildpack BUILDPACK [-f]
For more information on deleting a buildpack, see the CLI documentation.
Every new version of Cloud Foundry includes an updated buildpack. By default, your deployment applies the most recent buildpack when you upgrade. In some cases, however, you may want to preserve an existing buildpack, rather than upgrade to the latest version. For example, if an app you deploy depends on a specific component in Buildpack A that is not available in Buildpack B, you may want to continue using Buildpack A.
--lock flag lets you continue to use your existing buildpack even after you upgrade. Locked buildpacks are not updated when PCF updates. You must manually unlock them to update them.
If you elect to use the
--unlock flag, your deployment will apply the most recent buildpack when you upgrade PCF.
cf update-buildpack BUILDPACK [-p PATH] [-i POSITION] [--enable|--disable] [--lock|--unlock]
This feature is also available via API. For more information, see the API documentation.
You can disable custom buildpacks using your Ops Manager Elastic Runtime tile. From the Application Containers pane, clear the Enable Custom Buildpacks checkbox, as shown in the image below.
By default, the cf CLI gives developers the option of using a custom buildpack when they deploy apps to Elastic Runtime. To do so, they use the
-b option to provide a custom buildpack URL with the
cf push command. Clearing the Enable Custom Buildpacks checkbox prevents the
-b option from being used with external buildpack URLs.
For more information about custom buildpacks, refer to the buildpacks section of the PCF documentation.