Configure Cloud Run and Cloud Functions services

Stay organized with collections Save and categorize content based on your preferences.

Use the following environment variables to configure the behavior of your services when deployed to either Cloud Run or Cloud Functions.

Learn how to set these environment variable in your container image.

Cloud Run and Cloud Functions environment variables

The following configurations support building services for both applications and functions. Also see the additional Cloud Functions environment variables below.


Specifies the command that is run when your container is executed. This is equivalent to entrypoint in a Dockerfile.

  • Examples:
    • Java: java -jar target/myjar.jar
    • PHP: php -S index.php
    • Python: gunicorn -p :8080 main:app


Forces the runtime to opt-in. If the runtime buildpack image appears in multiple groups, the buildpack image in the first group is used across all groups.

Node.js example: Specifying nodejs forces the Node.js runtime buildpack to opt-in.


Specifies the version of your runtime to install. For .NET, specifies the .NET SDK version.


  • Go: 1.14.1
  • Java: 8
  • Node.js: 13.7.0
  • .NET: 3.1.301


For Go, Dart, and .NET runtimes: Specifies path to a buildable unit.

Go example: Specifying ./maindir builds the package rooted at maindir.


For Java (Maven and Gradle) and .NET runtimes: Appends arguments to the build command.

Java example: Specifying -Pprod runs mvn clean package ... -Pprod.


For Skaffold: Enables the development mode buildpacks. Use live local development to trigger automatic container rebuilds for changes to your source code. You must install Skaffold and run skaffold dev.

  • Supported values: true, True, 1


For functions and Go or Java applications: Clears source after the application is built. If the application depends on static files, such as Go templates, setting this variable may cause the application to misbehave.

Supported values: true, True, or 1

Additional Cloud Functions environment variables

The following configurations are only available for source code built as functions that use Functions Framework and Cloud Functions. For more information about these configuration option, see the contract.


  • Specifies the name of the exported function to be invoked in response to requests.
  • Example: myFunction will cause the Functions Framework to invoke the function of the same name.


  • Specifies the signature used by the function.
  • Example: http, event, or cloudevent.


  • Specifies the name of the directory or file containing the function source, depending on the language.
  • (Only applicable to some languages, please see the language-specific documentation.)
  • Example: for Python.