REGION_ID is an abbreviated code that Google assigns
based on the region you select when you create your app. The code does not
correspond to a country or province, even though some region IDs may appear
similar to commonly used country and province codes. For apps created after
REGION_ID.r is included in
App Engine URLs. For existing apps created before this date, the
region ID is optional in the URL.
Learn more about region IDs.
Learn how to run your application locally, deploy it, and test on App Engine.
To test your application's functionality before deploying, run your application in your local environment with the development tools that you usually use.
Before deploying your application
Before you can deploy your application:
- The Owner of the Google Cloud project must set up your Google Cloud project for App Engine.
- You must ensure that your user account includes the required privileges.
Deploying your application
Deploy your application to App Engine using the
gcloud app deploy command. During
deployment, the Cloud Build service builds a container
image of your application to run in the App Engine standard environment.
Each build is run in the same region as your Google Cloud project. Learn more
about Managing build images.
To programmatically deploy your apps, use the Admin API.
Deploying a service
You deploy your application to App Engine by deploying versions of your application's services and each of their configuration files.
To deploy a version of your application's service, run the following command
from the directory where the
app.yaml file of your service is located:
gcloud app deploy
Specifying no files with the command deploys only the
app.yaml file in your
current directory. By default, the
deploy command generates a unique ID for
the version that you deploy, deploys the version to the
Google Cloud project you configured the Google Cloud CLI to use,
and routes all traffic to the new version.
You can change the default behavior of the command by targeting specific files or including additional parameters:
- To deploy the other configuration files of your service, you must target and
deploy each file separately. For example:
gcloud app deploy cron.yaml gcloud app deploy dispatch.yaml gcloud app deploy index.yaml
- To specify a custom version ID, use the
- To prevent traffic from being automatically routed to the new version, use
- To deploy to a specific Google Cloud project, use the
For example, to deploy the service defined by the
app.yaml file to a specific
Google Cloud project, assign it a custom version ID, and prevent traffic
from being routed to the new version:
gcloud app deploy --project PROJECT_ID --version VERSION_ID --no-promote
For more information about this command, see the
gcloud app deploy
Deploying multiple services
You use the same deployment command for deploying or updating the multiple services that make up your application.
Before you begin:
- You must initially deploy a version of your application to the
defaultservice before you can create and deploy subsequent services.
- The ID of each of your services must be specified in their corresponding
app.yamlconfiguration files. To specify the service ID, include the
serviceelement definition in each configuration file. By default, excluding this element definition from your configuration file deploys the version to the
To deploy multiple services, separately deploy each service's
file. You can specify multiple files with a single
gcloud app deploy command:
gcloud app deploy service1/app.yaml service2/app.yaml
Viewing build logs
Cloud Build streams build and deploy logs that are viewable in the Cloud Build Build history section of the Google Cloud console. To view builds in the app's region, use the Region drop-down menu at the top of the page to choose the region you would like to filter by.
Managing build images
Each time you deploy a new version, a container image is created using the Cloud Build service. That container image is built in the app's region, and then runs in the App Engine standard environment.
Built container images are stored in the
in Container Registry. You can download these images to
keep or run elsewhere. After deployment is complete, App Engine no
longer needs the container images. Note that they are not automatically deleted,
so to avoid reaching your storage quota, you can safely delete any images you
don't need. However, if you might need the images in the future or want to keep
a copy of the images, you need to export a copy prior to deletion. For more
information about managing images in Container Registry, see the
Container Registry documentation.
You can use a
.gcloudignore file to specify files and directories that will
not be uploaded to App Engine when you deploy your services. This is
useful for ignoring build artifacts and other files that do not need to be
uploaded with your deployment.
Viewing your application
After you deploy your application to App Engine, you can run the
following command to launch your browser and view it at
gcloud app browse
Testing on App Engine before shifting traffic
Before configuring a new version to receive traffic, you can test it on
App Engine. For example, to test a new version of your
Deploy your new version, but prevent traffic from being automatically routed to the new version:
gcloud app deploy --no-promote
Access your new version by navigating to the following URL:
Now you can test your new version in the App Engine runtime environment. You can debug your application by viewing its logs. For more information, see Writing Application Logs.
App Engine routes requests sent to
https://PROJECT_ID.REGION_ID.r.appspot.comto the version previously configured to receive traffic.
When you want to send traffic to the new version, use the Google Cloud console to migrate traffic:
Select the version you just deployed and click Migrate traffic.
You can use the same process to test new versions of other services by replacing
default in the URL with your service's name:
For more information about targeting specific services and versions, see How requests are routed.
Using build environment variables
You can set build environment variables for runtimes that support buildpacks.
Build environment variables are key/value pairs that you can specify to configure the buildpack you use to deploy your app. For example, you might want to specify compiler options.
Before you begin:
- Keys must start with an uppercase ASCII letter, and can include uppercase ASCII letters, digits, and underscores.
- You should avoid creating any variables with a
- The following keys are reserved for Google's use:
- You can use any key that is supported by buildpacks.
To use environment variables with buildpacks, specify the
field in your
Learn more about buildpacks.
Using Cloud Trace
Cloud Trace is useful for understanding how requests propagate through your application. You can inspect detailed latency information for a single request or view aggregate latency for your entire application.