Use Custom Buildpacks

The Salesforce Function build system uses Cloud Native Buildpacks to transform your function code into a runnable image.

Buildpacks are composed of a set of executables that inspects your source code to detect the programming language, install dependencies, compile code and assets, and more.

Salesforce provides a set of official buildpacks to support Java, JavaScript, and TypeScript. With the custom buildpacks feature, Functions developers can change build behavior to suit their needs with third-party buildpacks or their own custom buildpack.

You can learn more about buildpacks here.

Custom buildpacks allow you to use features that are otherwise not available by default. For example:

• A custom buildpack gives you the freedom to write a function in any language, beyond the officially supported ones.
• You can extend the build system with libraries or binaries that aren't included by default. For instance, a custom buildpack can set up and install PDF authoring tools like puppeteer, which depend on Chromium executables.
• Change the command that's executed to launch your function. Learn more in the Buildpacks' official docs.

Whether you're using a third-party buildpack or creating your own, Salesforce Functions only supports buildpacks with the following Buildpack API spec range:

Buildpack API: 0.7 - 0.9

You can use custom buildpacks that follow the spec from Cloud Native Buildpacks. You can find existing third-party buildpacks in the Cloud Native Buildpack registry. Not every buildpack listed works with Functions. Test out the buildpack before adding it to production.

Writing a custom buildpack from scratch is out of scope for this documentation. For a complete guide, see the official Buildpack Author Guide from the Cloud Native Buildpacks project.

The following example is from the Heroku Procfile buildpack. This buildpack allows a developer to specify a custom process using the Procfile.

Salesforce Functions run on the most recently updated version of the stack. Buildpacks have a configuration file, buildpack.toml. As part of the configuration, buildpack authors list what stacks are compatible. You must include heroku-22, which is the current Salesforce Functions stack, or *, which is a wildcard for any stack. With some sections cut for brevity, the Procfile buildpack has a buildpack.toml that looks like:

Add the buildpack by including a [[io.buildpacks.group]] in your project.toml file. For example, to use the Procfile buildpack in a JavaScript function:

Buildpack groupings are executed sequentially. heroku/nodejs-function is the official buildpack that provides JavaScript support for Functions. In the example, that buildpack is listed first in the buildpack groupings so that it runs before the Procfile buildpack.

You can also insert buildpacks at the beginning or end of the buildpack group using [[io.buildpacks.pre.group]] and [[io.buildpacks.post.group]] respectively. With this feature, you decide if the custom buildpack runs before or after the normal buildpack grouping.

For example, to run the Procfile buildpack after the normal buildpack grouping in a JavaScript function:

If you don't specify [[io.buildpacks.group]] in your file, the default buildpack group is used. So in this Javscript function example, heroku/nodejs-function runs as part of the default buildpack group, followed by the Procfile buildpack specified in [[io.buildpacks.post.group]].

There's no way to remove a particular buildpack from the default buildpack group, but specifying [[io.buildpacks.group]] replaces the entire group. This change takes effect on your next function deploy.

You can check for buildpack-related errors in the build output when deploying your function with sf deploy functions.