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.
We recommend that you use standard Python tools, such as
virtualenv to create isolated environments and
to run unit tests and integration tests, rather than depending on
dev_appserver, the local development server provided
with the Google Cloud SDK.
For example, you can usually run a Flask application with Flask's development server using:
Django applications can be started using:
python manage.py runserver
To simulate a production App Engine environment, you can run the full
Web Server Gateway Interface (WSGI) server locally. To do this, use the same
command specified as entrypoint in your
app.yaml, for example:
gunicorn -b :$PORT main:app
Before deploying your application
Before you can deploy your application:
- The Owner of the Cloud project must enable App Engine.
- You must ensure that your user account includes the required privileges.
Deploying your applicationDeploy your application to App Engine using the
gcloud app deploycommand.
During deployment, the Cloud Build service builds a container image of your application to run in the App Engine standard environment. The builds are created in the app's region. Learn more in 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.
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
Requirements for deploying multiple services
- 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
Viewing build logs
Cloud Build streams build and deploy logs that are viewable in the Cloud Build history section of the 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.
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.
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. Once 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.
For more information about managing images in Container Registry, see the
Container Registry documentation.
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 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 also set build environment variables for runtimes that support buildpacks.
Build environment variables are key/value pairs deployed alongside an app that
let you pass
to buildpacks. For example, you might want to customize compiler options. You
can add or remove these build environment variables by configuring the
field in your
Using the local development server
The Google Cloud CLI includes a local development server named
dev_appserver that you can run locally to simulate your application running in
production App Engine. This development server partially simulates the
environment in which your application runs, allowing you to test apps written for
any of the standard environment runtimes.
Running the local development server
After you create the
file for your app, you can start the local development server with the
dev_appserver.py command to run your app locally.
To obtain access credentials for your user account, run:
gcloud auth login
Allow your local application to temporarily use your user credentials for API access:
gcloud auth application-default login
To start the local development server:
dev_appserver.pycommand from the root of your project directory. If Python 2 is not the default interpreter on your system, you need to run
python2 dev_appserver.pyto ensure the Python 2 interpreter is used.
Specify your project ID and path to your
dev_appserver.py --application=PROJECT_ID app.yaml
To change the port, include the
dev_appserver.py --application=PROJECT_ID app.yaml --port=9999
To test a Python 3 app, run
dev_appserver.pywith the Python 3 interpreter, you must specify the Python 3 binary in the
--runtime_python_pathflag. For example:
dev_appserver.py --runtime_python_path=/usr/bin/python3 --application=PROJECT_ID app.yaml --port=9999
To learn more about the
dev_appserver.pycommand options, see Local Development Server Options.
As the local development server starts, it sets up a development environment that pre-installs the dependencies found in your
The local development server is now running and listening for requests. Visit http://localhost:8080/ in your web browser to see the app in action.
If you specified a custom port with the
--portoption, remember to open your browser to that port.
To stop the local server from the command line, press Control-C on your keyboard.
Detecting application runtime environment
To determine whether your code is running in production or in the local
development server, you can check the
GAE_ENV environment variable:
if os.getenv('GAE_ENV', '').startswith('standard'): # Production in the standard environment else: # Local execution.
Using the local development server with Google Cloud services
You can integrate
dev_appserver with other Google Cloud components.
Cloud client libraries
Many Google Cloud client libraries depend on the presence of the
GOOGLE_CLOUD_PROJECT environment variable, which should be your
Cloud project ID. You can find its value by running the
gcloud config list project command or looking at your project page in the
Google Cloud console.
To ensure that this environment variable is set correctly during local
dev_appserver using the
--application=PROJECT_ID parameter as shown in the
The local development server automatically installs dependencies found in your
dev_appserver also allows you to test functionality
that is configured via
app.yaml. For example, you can test your app's ability
to serve static
dev_appserver is running, any changes to
automatically restarts your app to reflect these changes. This may result in a
temporary delay as dependencies are downloaded and installed.
Instance management and routing in the development server
Discovering instance addresses
The local development server creates all manual scaling instances at startup. Instances for automatic and basic scaling services are managed dynamically. The server assigns a port to each service, and clients can depend on the server to load-balance and select an instance automatically. The port assignments for addressing each service appear in the server's log message stream.
Here are the ports for an app that defines three services:
INFO Starting module "default" running at: http://localhost:8084 INFO Starting module "service1" running at: http://localhost:8082 INFO Starting module "service2" running at: http://localhost:8083
When you use a service's address, for example
server creates or selects an instance of the service and sends the request to
The server assigns unique ports to each instance of a service. You can use the admin server to discover these ports. There is a unique port for the admin server, which appears in the message log:
INFO Starting admin server at: http://localhost:8000
This address takes you to the admin server console. Click on Instances to see the dynamic state of your app's instances
A separate entry appears for each manual and basic instance. The instance numbers are links with unique port addresses for each instance. Click on the link to send a request directly to that instance.
If your app includes a
dispatch.yaml file, the log messages stream includes a
INFO Starting dispatcher running at: http://localhost:8080
Requests to this port are routed according to the rules in the dispatch file.
The server does not support
dispatch.yaml file rules that include
hostnames, for example,
url: "customer1.myapp.com/*"). Rules with relative
path patterns (
url: "*/fun", do work, so you can use URLs like
http://localhost/fun/mobile to reach instances. The server reports an error in
the log stream if you try to start an application with a
that contains host-based rules.