Deploying from Your Local Machine

This page shows you how to deploy a Cloud Function from your local machine using the gcloud command-line tool. When using the command-line tool, Cloud Functions packages and uploads the contents of your function's directory to a Cloud Storage bucket for you and automatically excludes unnecessary files via the .gcloudignore file.

Alternatively, you can use the Cloud Functions interface in the Cloud Console to upload a ZIP file you make yourself.

Note: Cloud Functions can accept source code directly, or you can store your code in your own Cloud Storage bucket with the optional --stage-bucket parameter. For more information on specifying your own storage bucket for deployment, see the Cloud SDK documentation.

For a complete runnable example that includes downloadable sample code, see the Using the gcloud Command-Line Tool quickstart.

Deploy using the gcloud tool

Using the gcloud command-line tool, deploy your function from the directory containing your function code with the gcloud functions deploy command:

gcloud functions deploy NAME --entry-point ENTRY-POINT --runtime RUNTIME TRIGGER [FLAGS...]

Note: When you deploy a function for the first time, you must include the --runtime flag. The --runtime flag is not required on subsequent deployments of the function.

See the arguments in this command, bearing in mind the terminology discussed in Basic Concepts:

Argument	Description
NAME	The registered name of the Cloud Function you are deploying. NAME can only contain letters, numbers, underscores, and hyphens. NAME can either be the name of a function in your source code, or it can be a custom string (for example, my-http-function). If you use a custom string, you must also use the --entry-point flag to specify a function contained in your code, to tell the deploy command what function to execute.
--entry-point ENTRY-POINT	The name of a function or class in your source code. This flag has two primary uses: You can use it instead of NAME when the functions in your source code do not meet the naming requirements for Cloud Functions. For example, if you're specifying a fully qualified class name (FQN) for Java that contains periods (not allowed in NAME), you need to use this flag. If you simply want to make your registered NAME different from the name of the executed function. If you don't use this flag, it means that NAME must specify the function in your source code to be executed during deployment. Your registered name will then have the same name as the function.
--runtime RUNTIME	The name of the runtime you are using. For a complete list, see the gcloud reference. Note that you must include this flag the first time you deploy a function, but you can omit it on subsequent deployments.
TRIGGER	The trigger type for this function (see Events and Triggers). The rules for specifying triggers when deploying a function are as follows: If you don't specify a trigger when deploying an update to an existing function, it will keep its current trigger. When deploying a new function, you must specify one of --trigger-http, --trigger-topic, or --trigger-bucket, or specify both --trigger-event AND --trigger-resource. You use the flag --trigger-http to deploy HTTP functions. You use the other flags to deploy event-driven functions.
FLAGS...	(Optional) Additional flags you can specify during deployment, such as --stage-bucket or --source. For a full reference, see the gcloud functions deploy documentation.

Each runtime has specific file structuring requirements so Cloud Functions can find your function's definition.

HTTP function example

There are three types of Cloud Functions: HTTP functions, Background functions, and CloudEvent functions. For an example that shows how to deploy an event-driven function, see Event-driven function example.

Java example

The following example deploys an HTTP function written in Java and assigns it a trigger, by using the --trigger-http flag:

gcloud functions deploy my-java-function --entry-point com.example.MyFunction --runtime java11 --trigger-http --allow-unauthenticated

Note: Functions with HTTP(S) triggers are not supported in projects whose IDs contain a colon.

See the arguments in this command:

Argument	Description
my-java-function	The registered name of the Cloud Function you are deploying, in this case my-java-function. This is a custom name you provide. It can only contain letters, numbers, underscores, and hyphens.
--entry-point	The name of a fully qualified Java class name in your source code, in this example, com.example.MyFunction.
--runtime java11	The runtime for this function, in this case java11.
--trigger-http	The trigger type for this function, in this case an HTTP request (webhook).
--allow-unauthenticated	Specifies that the function does not require authentication to invoke. By default HTTP functions require authentication. If you do not include this flag the first time you deploy an HTTP function, you are prompted to allow unauthenticated invocations. You are not prompted on subsequent invocations.

Note: You can configure an HTTP function so that it can only be triggered by HTTPS, not HTTP. For details, see HTTP Functions.

Python example

The syntax is the same when using the --entry-point flag to deploy a non-Java HTTP function. In this example, the registered name is my-python-function, and the function is helloworld:

gcloud functions deploy my-python-function --entry-point helloworld --runtime python37 --trigger-http --allow-unauthenticated

If you run the same command but without the entry-point flag, the NAME (registered name) field must be a function in your source code (in this example, helloworld):

gcloud functions deploy helloworld --runtime python37 --trigger-http --allow-unauthenticated

Event-driven function example

The following example deploys an event-driven function written in Node.js that will be triggered by Cloud Storage:

Note: event-driven Node.js functions use the background function event syntax.

gcloud functions deploy helloGCS --runtime nodejs14 --trigger-resource TRIGGER_BUCKET_NAME --trigger-event google.storage.object.finalize

See the arguments in this command:

Argument	Description
helloGCS	The registered name of the Cloud Function you are deploying, in this case helloGCS. Because the command doesn't use the --entry-point flag, this must be the name of the function in your source code to be executed during deployment.
--runtime nodejs14	The runtime for this function, in this case nodejs14.
--trigger-resource	The trigger resource for this function. The trigger resource specifies the resource for which the trigger event is being observed. In this case, the resource is the name (TRIGGER_BUCKET_NAME) of the Cloud Storage bucket that triggers the function.
--trigger-event	The trigger event for this function, which specifies which action should trigger the function. In this case, the event is google.storage.object.finalize.

Using the flags --trigger-resource MY_RESOURCE and --trigger-event MY_EVENT is the most explicit way to specify a trigger for an event-driven function. However, gcloud provides shorthands for Pub/Sub and Cloud Storage:

• When deploying functions that are assigned Pub/Sub triggers, you can use the flag --trigger-topic MY_TOPIC. This flag is a shorthand for --trigger-resource MY_TOPIC --trigger-event google.pubsub.topic.publish.

• When deploying functions that are assigned Cloud Storage triggers, you can use the flag --trigger-bucket MY_STORAGE_BUCKET to trigger function execution whenever files in the specified bucket change.

Next steps

• Calling HTTP Functions.
• Calling Cloud Storage Trigger Functions.
• Calling Cloud Pub/Sub Trigger Functions.
• HTTP Cloud Functions Tutorial.
• Cloud Functions with Cloud Storage Tutorial.
• Cloud Functions with Cloud Pub/Sub Tutorial.