Go 1.11 has reached end of support and will be deprecated on January 31, 2026. After deprecation, you won't be able to deploy Go 1.11 applications, even if your organization previously used an organization policy to re-enable deployments of legacy runtimes. Your existing Go 1.11 applications will continue to run and receive traffic after their deprecation date. We recommend that you migrate to the latest supported version of Go.

Testing and Deploying your Application

Region ID

The 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 February 2020, 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.

Running locally

To test your application's functionality before deploying, run your application in your local environment with the development tools that you usually use. For example, the go run command.

Before deploying your application

Before you can deploy your application:

The Owner of the Google Cloud project must enable 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. The builds are created in the app's region. Learn more in Manage 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 --version flag.
To prevent traffic from being automatically routed to the new version, use the --no-promote flag.
To deploy to a specific Google Cloud project, use the --project flag.

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 reference.

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 app.yaml 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 default service before you can create and deploy subsequent services.
The ID of each of your services must be specified in their corresponding app.yaml configuration files. To specify the service ID, include the service element definition in each configuration file. By default, excluding this element definition from your configuration file deploys the version to the default service.

Viewing build logs

Cloud Build streams build and deploy logs that are viewable in the Cloud 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.

Ignoring files

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.

Manage build images

Here are the steps that occur each time you deploy a new version:

App Engine creates a container image using the Cloud Build service.
Cloud Build builds the container image in the app's region, and runs in the App Engine standard environment.
App Engine stores built container images in Artifact Registry. You can download these images to keep or run elsewhere.

After deployment is complete, App Engine no longer needs the container images. The container images aren't automatically deleted. 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 Artifact Registry, see Manage images.

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 https://PROJECT_ID.REGION_ID.r.appspot.com:

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 default service:

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:

https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com

Note: You can find the version ID in the Google Cloud console or specify one when you deploy with the --version flag. The Google Cloud CLI also outputs the version ID when you deploy.

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.com to 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:

Manage versions

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:

https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com

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 Google Cloud's buildpacks.

Build environment variables are key/value pairs deployed alongside an app that let you pass configuration information to buildpacks. For example, you might want to customize compiler options. You can add or remove these build environment variables by configuring the build_env_variables field in your app.yaml file.

Note: Keys must start with an uppercase ASCII letter, and consist of uppercase ASCII letters, digits, and underscores. You should avoid creating variable keys with a GOOGLE_* prefix. View all supported buildpacks environment variables.

Using the local development server

You can use dev_appserver to run your apps 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.

Since Go 1.11 has reached the end of support, you can no longer use the latest version of dev_appserver.py to locally run your applications. To continue using dev_appserver.py, follow the instructions in Using the local development server.

Running the local development server

After you create the app.yaml configuration 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:

In the directory that contains your app.yaml configuration file, run the dev_appserver.py command and specify your project ID and path to your app.yaml file:
```
python2 DEVAPPSERVER_ROOT/google_appengine/dev_appserver.py/dev_appserver.py --application=PROJECT_ID app.yaml
```
To change the port, include the --port option:
```
python2 DEVAPPSERVER_ROOT/google_appengine/dev_appserver.py/dev_appserver.py --application=PROJECT_ID app.yaml --port=9999
```
Replace DEVAPPSERVER_ROOT with the path to the folder where you extract the archived version of devapp_server.py. For more information about downloading and using the archived version of dev_appserver.py, see Using the local development server.

To learn more about the dev_appserver.py command 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 requirements.txt file.
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 --port option, 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 Cloud Client Libraries depend on the presence of the GOOGLE_CLOUD_PROJECT environment variable, which should be your Google 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 development, initialize dev_appserver using the --application=PROJECT_ID parameter as shown in the previous example.

Cloud emulators

You can test your application with emulators for Cloud Datastore, Cloud Bigtable and Cloud Pub/Sub.

Auto-reloading `requirements.txt` and `app.yaml` changes

The local development server automatically installs dependencies found in your requirements.txt file. 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 files. When dev_appserver is running, any changes to requirements.txt and app.yaml 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 http://localhost:8082/, the server creates or selects an instance of the service and sends the request to that instance.

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.

Dispatch files

If your app includes a dispatch.yaml file, the log messages stream includes a dispatcher port:

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 dispatch.yaml file that contains host-based rules.