Notice: Over the next few months, we're reorganizing the App Engine documentation site to make it easier to find content and better align with the rest of Google Cloud products. The same content will be available, but the navigation will now match the rest of the Cloud products. If you have feedback or questions as you navigate the site, click Send Feedback.

Testing and deploying your application

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

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

Go

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.

Java

To test your application's functionality before deploying, run your application in your local environment with the development tools that you usually use. For details, including specific commands depending on your plugin, see Local testing for the Java 8/Jetty 9 runtime or Local testing for the Java 8 runtime.

Node.js

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, npm start.

PHP

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

Python

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, you can usually run a Flask application with Flask's development server using:

python main.py

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

Ruby

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, if you use Sinatra, you can run an application with Sinatra's development server using:

bundle exec ruby app.rb -p 8080

If you use Rails, you can start an application using:

rails server

.Net

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

Custom Runtimes

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, you can download and install Docker to run and test your containerized apps on your local machine.

Deploying your application

Go

Deploy your application to App Engine using the gcloud app deploy command, which will correctly assemble your application's dependencies in the same way that the go tool does.

This command automatically builds a container image by using the Cloud Build service and then deploys that image to the App Engine flexible environment. The container will include any local modifications that you've made to the runtime image.

To programmatically deploy your apps, use the Admin API.

Java

No additional information for this runtime.

Node.js

Deploy your application to App Engine using the gcloud app deploy command.

This command automatically builds a container image by using the Cloud Build service and then deploys that image to the App Engine flexible environment. The container will include any local modifications that you've made to the runtime image.

To programmatically deploy your apps, use the Admin API.

PHP

Deploy your application to App Engine using the gcloud app deploy command.

This command automatically builds a container image by using the Cloud Build service and then deploys that image to the App Engine flexible environment. The container will include any local modifications that you've made to the runtime image.

To programmatically deploy your apps, use the Admin API.

Python

Deploy your application to App Engine using the gcloud app deploy command.

This command automatically builds a container image by using the Cloud Build service and then deploys that image to the App Engine flexible environment. The container will include any local modifications that you've made to the runtime image.

To programmatically deploy your apps, use the Admin API.

Ruby

Deploy your application to App Engine using the gcloud app deploy command.

This command automatically builds a container image by using the Cloud Build service and then deploys that image to the App Engine flexible environment. The container will include any local modifications that you've made to the runtime image.

To programmatically deploy your apps, use the Admin API.

.NET

Deploy your application to App Engine using the gcloud app deploy command.

This command automatically builds a container image by using the Cloud Build service and then deploys that image to the App Engine flexible environment. The container will include any local modifications that you've made to the runtime image.

To programmatically deploy your apps, use the Admin API.

Custom

Deploy your application to App Engine using the gcloud app deploy command.

This command automatically builds a container image by using the Cloud Build service and then deploys that image to the App Engine flexible environment. The container will include any local modifications that you've made to the runtime image.

To programmatically deploy your apps, use the Admin API.

Before you begin

Before you can deploy your application:

Ensuring successful deployment

Go

If you enable updated health checks, deployments are rolled back if your application does not reach healthy status. When you deploy your first application to the flexible environment, there might be a delay as your virtual machine (VM) and other infrastructure are set up. After the initial setup, the health checks make sure that your instance is healthy and ready to receive traffic. If your application does not reach ready status in a specified amount of time, indicated by the initial_delay_sec field in the liveness_check section of your app.yaml file, then your deployment fails and is rolled back.

Your application might need more time to become ready. For example, you might initialize your application by downloading large files or preloading caches. If you are using updated health checks, then you can increase the amount of time by modifying the app_start_timeout_sec configuration setting in the readiness_check section of in your app.yaml file.

If your deployment fails, make sure the Cloud Build API is enabled in your project. App Engine enables this API automatically the first time you deploy an app, but if someone has since disabled the API, deployments will fail.

Java

No additional information for this runtime.

Node.js

If you enable updated health checks, deployments are rolled back if your application does not reach healthy status. When you deploy your first application to the flexible environment, there might be a delay as your virtual machine (VM) and other infrastructure are set up. After the initial setup, the health checks make sure that your instance is healthy and ready to receive traffic. If your application does not reach ready status in a specified amount of time, indicated by the initial_delay_sec field in the liveness_check section of your app.yaml file, then your deployment fails and is rolled back.

Your application might need more time to become ready. For example, you might initialize your application by downloading large files or preloading caches. If you are using updated health checks, then you can increase the amount of time by modifying the app_start_timeout_sec configuration setting in the readiness_check section of in your app.yaml file.

If your deployment fails, make sure the Cloud Build API is enabled in your project. App Engine enables this API automatically the first time you deploy an app, but if someone has since disabled the API, deployments will fail.

PHP

If you enable updated health checks, deployments are rolled back if your application does not reach healthy status. When you deploy your first application to the flexible environment, there might be a delay as your virtual machine (VM) and other infrastructure are set up. After the initial setup, the health checks make sure that your instance is healthy and ready to receive traffic. If your application does not reach ready status in a specified amount of time, indicated by the initial_delay_sec field in the liveness_check section of your app.yaml file, then your deployment fails and is rolled back.

Your application might need more time to become ready. For example, you might initialize your application by downloading large files or preloading caches. If you are using updated health checks, then you can increase the amount of time by modifying the app_start_timeout_sec configuration setting in the readiness_check section of in your app.yaml file.

If your deployment fails, make sure the Cloud Build API is enabled in your project. App Engine enables this API automatically the first time you deploy an app, but if someone has since disabled the API, deployments will fail.

Python

If you enable updated health checks, deployments are rolled back if your application does not reach healthy status. When you deploy your first application to the flexible environment, there might be a delay as your virtual machine (VM) and other infrastructure are set up. After the initial setup, the health checks make sure that your instance is healthy and ready to receive traffic. If your application does not reach ready status in a specified amount of time, indicated by the initial_delay_sec field in the liveness_check section of your app.yaml file, then your deployment fails and is rolled back.

Your application might need more time to become ready. For example, you might initialize your application by downloading large files or preloading caches. If you are using updated health checks, then you can increase the amount of time by modifying the app_start_timeout_sec configuration setting in the readiness_check section of in your app.yaml file.

If your deployment fails, make sure the Cloud Build API is enabled in your project. App Engine enables this API automatically the first time you deploy an app, but if someone has since disabled the API, deployments will fail.

Ruby

If you enable updated health checks, deployments are rolled back if your application does not reach healthy status. When you deploy your first application to the flexible environment, there might be a delay as your virtual machine (VM) and other infrastructure are set up. After the initial setup, the health checks make sure that your instance is healthy and ready to receive traffic. If your application does not reach ready status in a specified amount of time, indicated by the initial_delay_sec field in the liveness_check section of your app.yaml file, then your deployment fails and is rolled back.

Your application might need more time to become ready. For example, you might initialize your application by downloading large files or preloading caches. If you are using updated health checks, then you can increase the amount of time by modifying the app_start_timeout_sec configuration setting in the readiness_check section of in your app.yaml file.

If your deployment fails, make sure the Cloud Build API is enabled in your project. App Engine enables this API automatically the first time you deploy an app, but if someone has since disabled the API, deployments will fail.

.NET

No additional information for this runtime.

Custom

If you enable updated health checks, deployments are rolled back if your application does not reach healthy status. When you deploy your first application to the flexible environment, there might be a delay as your virtual machine (VM) and other infrastructure are set up. After the initial setup, the health checks make sure that your instance is healthy and ready to receive traffic. If your application does not reach ready status in a specified amount of time, indicated by the initial_delay_sec field in the liveness_check section of your app.yaml file, then your deployment fails and is rolled back.

Your application might need more time to become ready. For example, you might initialize your application by downloading large files or preloading caches. If you are using updated health checks,then you can increase the amount of time by modifying the app_start_timeout_sec configuration setting in the readiness_check section of your app.yaml file. If your deployment fails, make sure the Cloud Build API is enabled in your project. App Engine enables this API automatically the first time you deploy an app, but if someone has since disabled the API, deployments will fail.

Deploying a service

Go

You deploy your application to App Engine by deploying versions of your application's services and each of their configuration files.

To deploy your application's service, run the following command from the directory where the app.yaml file of your service is located:

gcloud app deploy

By default, the gcloud app deploy command deploys only the app.yaml file in your current directory. Whenever you run this command, App Engine generates a unique ID for the version that you deploy, deploys the version to the Cloud project you configured the gcloud CLI to use, and routes all traffic to the new version. The new version becomes the default version.

You can change the default behavior of the gcloud app deploy command by targeting specific files, specifying versions, or including additional parameters:

  • You can deploy the other configuration files of your service by targeting and deploying 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 Cloud project, use the --project flag.

For example, to deploy the service defined by app.yaml to a specific 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.

Java

You can use any of the supported tools to deploy your Java application to the App Engine flexible environment. For command-line deployment, use gcloud app deploy from the gcloud CLI, or use the Maven or the Gradle plugins. To deploy using an IDE, use the IntelliJ or Eclipse plugins. To programmatically deploy your apps, use the Admin API.

Node.js

You deploy your application to App Engine by deploying versions of your application's services and each of their configuration files.

To deploy your application's service, run the following command from the directory where the app.yaml file of your service is located:

gcloud app deploy

By default, the gcloud app deploy command deploys only the app.yaml file in your current directory. Whenever you run this command, App Engine generates a unique ID for the version that you deploy, deploys the version to the Cloud project you configured the gcloud CLI to use, and routes all traffic to the new version. The new version becomes the default version.

You can change the default behavior of the gcloud app deploy command by targeting specific files, specifying versions, or including additional parameters:

  • You can deploy the other configuration files of your service by targeting and deploying 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 Cloud project, use the --project flag.

For example, to deploy the service defined by app.yaml to a specific 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.

PHP

You deploy your application to App Engine by deploying versions of your application's services and each of their configuration files.

To deploy your application's service, run the following command from the directory where the app.yaml file of your service is located:

gcloud app deploy

By default, the gcloud app deploy command deploys only the app.yaml file in your current directory. Whenever you run this command, App Engine generates a unique ID for the version that you deploy, deploys the version to the Cloud project you configured the gcloud CLI to use, and routes all traffic to the new version. The new version becomes the default version.

You can change the default behavior of the gcloud app deploy command by targeting specific files, specifying versions, or including additional parameters:

  • You can deploy the other configuration files of your service by targeting and deploying 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 Cloud project, use the --project flag.

For example, to deploy the service defined by app.yaml to a specific 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.

Python

You deploy your application to App Engine by deploying versions of your application's services and each of their configuration files.

To deploy your application's service, run the following command from the directory where the app.yaml file of your service is located:

gcloud app deploy

By default, the gcloud app deploy command deploys only the app.yaml file in your current directory. Whenever you run this command, App Engine generates a unique ID for the version that you deploy, deploys the version to the Cloud project you configured the gcloud CLI to use, and routes all traffic to the new version. The new version becomes the default version.

You can change the default behavior of the gcloud app deploy command by targeting specific files, specifying versions, or including additional parameters:

  • You can deploy the other configuration files of your service by targeting and deploying 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 Cloud project, use the --project flag.

For example, to deploy the service defined by app.yaml to a specific 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.

Ruby

You deploy your application to App Engine by deploying versions of your application's services and each of their configuration files.

To deploy your application's service, run the following command from the directory where the app.yaml file of your service is located:

gcloud app deploy

By default, the gcloud app deploy command deploys only the app.yaml file in your current directory. Whenever you run this command, App Engine generates a unique ID for the version that you deploy, deploys the version to the Cloud project you configured the gcloud CLI to use, and routes all traffic to the new version. The new version becomes the default version.

You can change the default behavior of the gcloud app deploy command by targeting specific files, specifying versions, or including additional parameters:

  • You can deploy the other configuration files of your service by targeting and deploying 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 Cloud project, use the --project flag.

For example, to deploy the service defined by app.yaml to a specific 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.

.NET

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:

gcloud app deploy .\bin\Debug\netcoreapp2.1\publish\app.yaml

By default the deploy command automatically generates a new version ID each time that you use it and will route any traffic to the new version.

To override this behavior, you can specify the version ID with the version flag:

gcloud app deploy .\bin\Debug\netcoreapp2.1\publish\app.yaml --version myID

You can also specify not to send all traffic to the new version immediately with the --no-promote flag:

gcloud app deploy .\bin\Debug\netcoreapp2.1\publish\app.yaml --no-promote

Custom

You deploy your application to App Engine by deploying versions of your application's services and each of their configuration files.

To deploy your application's service, run the following command from the directory where the app.yaml file of your service is located:

gcloud app deploy

By default, the gcloud app deploy command deploys only the app.yaml file in your current directory. Whenever you run this command, App Engine generates a unique ID for the version that you deploy, deploys the version to the Cloud project you configured the gcloud CLI to use, and routes all traffic to the new version. The new version becomes the default version.

You can change the default behavior of the gcloud app deploy command by targeting specific files, specifying versions, or including additional parameters:

  • You can deploy the other configuration files of your service by targeting and deploying 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 Cloud project, use the --project flag.

For example, to deploy the service defined by app.yaml to a specific 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

Go

You use the same deployment command for deploying or updating the multiple services that make up your application.

To deploy multiple services, you must separately deploy each service's app.yaml file. For example:

gcloud app deploy service1/app.yaml
gcloud app deploy service2/app.yaml

You can specify multiple files with a single 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.

Java

No additional information for this runtime.

Node.js

You use the same deployment command for deploying or updating the multiple services that make up your application.

To deploy multiple services, you must separately deploy each service's app.yaml file. For example:

gcloud app deploy service1/app.yaml
gcloud app deploy service2/app.yaml

You can specify multiple files with a single 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.

PHP

You use the same deployment command for deploying or updating the multiple services that make up your application.

To deploy multiple services, you must separately deploy each service's app.yaml file. For example:

gcloud app deploy service1/app.yaml
gcloud app deploy service2/app.yaml

You can specify multiple files with a single 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.

Python

You use the same deployment command for deploying or updating the multiple services that make up your application.

To deploy multiple services, you must separately deploy each service's app.yaml file. For example:

gcloud app deploy service1/app.yaml
gcloud app deploy service2/app.yaml

You can specify multiple files with a single 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.

Ruby

You use the same deployment command for deploying or updating the multiple services that make up your application.

To deploy multiple services, you must separately deploy each service's app.yaml file. For example:

gcloud app deploy service1/app.yaml
gcloud app deploy service2/app.yaml

You can specify multiple files with a single 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.

.NET

No additional information for this runtime.

Custom

You use the same deployment command for deploying or updating the multiple services that make up your application.

To deploy multiple services, you must separately deploy each service's app.yaml file. For example:

gcloud app deploy service1/app.yaml
gcloud app deploy service2/app.yaml

You can specify multiple files with a single 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.

Ignoring files

You can use a .gcloudignore file to specify files and directories not to upload to Google Cloud 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.

Learn more about the syntax of the .gcloudignore file in the gcloud reference.

Manually building a container for deployment

To build your container images outside of Google Cloud Platform, you must first upload your images to a container image repository before you can deploy your images to App Engine with the gcloud app deploy command.

For example, if you build your container images locally with Docker, you can push those images to Google Container Registry and then specify the URL of your image in the --image-url flag of the command:

Go

gcloud app deploy --image-url gcr.io/YOUR_PROJECT_ID/YOUR_CONTAINER_IMAGE
For more information about building your own container image, see the Extending the runtime section.

Java

gcloud app deploy src/main/appengine/app.yaml --image-url gcr.io/YOUR_PROJECT_ID/YOUR_CONTAINER_IMAGE

Node.js

gcloud app deploy --image-url gcr.io/YOUR_PROJECT_ID/YOUR_CONTAINER_IMAGE

PHP

gcloud app deploy --image-url gcr.io/YOUR_PROJECT_ID/YOUR_CONTAINER_IMAGE

Python

gcloud app deploy --image-url gcr.io/YOUR_PROJECT_ID/YOUR_CONTAINER_IMAGE

Ruby

gcloud app deploy --image-url gcr.io/YOUR_PROJECT_ID/YOUR_CONTAINER_IMAGE

.NET

gcloud app deploy .\bin\Debug\netcoreapp2.1\publish\app.yaml --image-url gcr.io/YOUR_PROJECT_ID/YOUR_CONTAINER_IMAGE

Custom

gcloud app deploy --image-url gcr.io/YOUR_PROJECT_ID/YOUR_CONTAINER_IMAGE

Using automated continuous deployment pipelines

You can use Cloud Build to automate deployments in continuous deployment pipelines. For more information, see Deploying artifacts, and Automating Builds using Build Triggers in the Cloud Build documentation.

Docker base images

Go

Not applicable to this runtime.

Java

If you'd like to build a Java custom runtime application from scratch, use a provided base image in your Dockerfile:

Runtime Docker command
Java 8 FROM gcr.io/google_appengine/openjdk
Java 8 / Jetty 9 FROM gcr.io/google-appengine/jetty

Node.js

If you'd like to build a Node.js custom runtime application from scratch, use a provided base image in your Dockerfile:

Runtime Docker command
Node.js FROM gcr.io/google-appengine/nodejs

PHP

If you'd like to build a PHP custom runtime application from scratch, use a provided base image in your Dockerfile:

Version Docker command
PHP 5.6 FROM gcr.io/google-appengine/php56
PHP 7.0 FROM gcr.io/google-appengine/php70
PHP 7.1 FROM gcr.io/google-appengine/php71
PHP 7.2 FROM gcr.io/google-appengine/php72
PHP 7.3 FROM gcr.io/google-appengine/php73

The source code of the base images are available at: https://github.com/GoogleCloudPlatform/php-docker

Python

If you'd like to build a Python custom runtime application from scratch, use a provided base image in your Dockerfile:

Runtime Docker command Equivalent Google runtime
Python (2.7, 3.6 can be specified in the Dockerfile) FROM gcr.io/google-appengine/python runtime: python

Ruby

If you'd like to build a Ruby custom runtime application from scratch, use a provided base image in your Dockerfile:

Runtime Docker command
Ruby FROM gcr.io/google-appengine/ruby

.NET

If you'd like to build a .Net custom runtime application from scratch, use a provided base image in your Dockerfile:

Runtime Docker command
.NET FROM gcr.io/google-appengine/aspnetcore:1.0.11
.NET FROM gcr.io/google-appengine/aspnetcore:1.1.8
.NET FROM gcr.io/google-appengine/aspnetcore:2.0.7
.NET FROM gcr.io/google-appengine/aspnetcore:2.1.0

Custom

No additional information for this runtime.

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

Go

  1. Deploy your new version and include the --no-promote flag:

    gcloud app deploy --no-promote

  2. Access your new version by navigating to the following URL:

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

    Now you can test your new version in the App Engine runtime environment. You can debug your application by viewing its logs in the Google Cloud console Logs Explorer. For more information, see Writing Application Logs. Requests sent to https://PROJECT_ID.REGION_ID.r.appspot.com will still be routed to the version previously configured to receive traffic.

  3. 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:

For more information about targeting specific services and versions, see How Requests are Routed.

Java

  1. Deploy your new version with the promote parameter set to false:

  2. Access your new version by navigating to the following URL:

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

    Now you can test your new version in the App Engine runtime environment. You can debug your application by viewing its logs in the Google Cloud console Logs Explorer. For more information, see Writing Application Logs.

    Requests sent to https://PROJECT_ID.REGION_ID.r.appspot.com will still be routed to the version previously configured to receive traffic.

  3. 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:

For more information about targeting specific services and versions, see How Requests are Routed.

Node.js

  1. Deploy your new version and include the --no-promote flag:

    gcloud app deploy --no-promote

  2. Access your new version by navigating to the following URL:

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

    Now you can test your new version in the App Engine runtime environment. You can debug your application by viewing its logs in the Google Cloud console Logs Explorer. For more information, see Writing Application Logs. Requests sent to https://PROJECT_ID.REGION_ID.r.appspot.com will still be routed to the version previously configured to receive traffic.

  3. 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:

For more information about targeting specific services and versions, see How Requests are Routed.

PHP

  1. Deploy your new version and include the --no-promote flag:

    gcloud app deploy --no-promote

  2. Access your new version by navigating to the following URL:

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

    Now you can test your new version in the App Engine runtime environment. You can debug your application by viewing its logs in the Google Cloud console Logs Explorer. For more information, see Writing Application Logs. Requests sent to https://PROJECT_ID.REGION_ID.r.appspot.com will still be routed to the version previously configured to receive traffic.

  3. 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:

For more information about targeting specific services and versions, see How Requests are Routed.

Python

  1. Deploy your new version and include the --no-promote flag:

    gcloud app deploy --no-promote

  2. Access your new version by navigating to the following URL:

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

    Now you can test your new version in the App Engine runtime environment. You can debug your application by viewing its logs in the Google Cloud console Logs Explorer. For more information, see Writing Application Logs. Requests sent to https://PROJECT_ID.REGION_ID.r.appspot.com will still be routed to the version previously configured to receive traffic.

  3. 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:

For more information about targeting specific services and versions, see How Requests are Routed.

Ruby

  1. Deploy your new version and include the --no-promote flag:

    gcloud app deploy --no-promote

  2. Access your new version by navigating to the following URL:

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

    Now you can test your new version in the App Engine runtime environment. You can debug your application by viewing its logs in the Google Cloud console Logs Explorer. For more information, see Writing Application Logs. Requests sent to https://PROJECT_ID.REGION_ID.r.appspot.com will still be routed to the version previously configured to receive traffic.

  3. 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:

For more information about targeting specific services and versions, see How Requests are Routed.

.NET

  1. Deploy your new version and include the --no-promote flag:

    gcloud app deploy .\bin\Debug\netcoreapp2.1\publish\app.yaml --no-promote

  2. Access your new version by navigating to the following URL:

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

    Now you can test your new version in the App Engine runtime environment. You can debug your application by viewing its logs in the Google Cloud console Logs Explorer. For more information, see Writing Application Logs.

    Requests sent to https://PROJECT_ID.REGION_ID.r.appspot.com will still be routed to the version previously configured to receive traffic.

  3. 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:

For more information about targeting specific services and versions, see How Requests are Routed.

Custom

  1. Deploy your new version and include the --no-promote flag:

    gcloud app deploy --no-promote

  2. Access your new version by navigating to the following URL:

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

    Now you can test your new version in the App Engine runtime environment. You can debug your application by viewing its logs in the Google Cloud console Logs Explorer. For more information, see Writing Application Logs. Requests sent to https://PROJECT_ID.REGION_ID.r.appspot.com will still be routed to the version previously configured to receive traffic.

  3. 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:

Troubleshooting

The following are common error messages that you might encounter when deploying apps:

PERMISSION_DENIED: Operation not allowed
The "appengine.applications.create" permission is required.
If the Cloud project does not include the required App Engine application, the gcloud app deploy command can fail when it tries to run the gcloud app create command. Only accounts with Owner role have the necessary permissions to create App Engine applications.
502 Bad Gateway
The Cloud project can fail to start if the app.yaml is misconfigured. Check the app logs for more detailed error messages.
[13] An internal error occurred while creating a Cloud Storage bucket.

App Engine creates a default Cloud Storage multi-regional bucket on your behalf, on the same region where your application is created. This bucket is required to store the contents of your application. This error is returned when this bucket cannot be created, in the following scenarios:

[13] An internal error occurred.

This error can occur if you are deploying your service with a network configuration using a Shared VPC setup. Ensure that your App Engine flexible environment fulfills all the requirements for this configuration. Next, make sure that the configured service accounts for this setup are present in your project, otherwise you will have to restore the accounts. Note that the region of the subnet in the Shared VPC host project, must match the location where your App Engine environment was created.

If the issue persists after ensuring your app.yaml configuration is valid, use the Google Cloud SDK to re-deploy your service, adding the --verbosity=debug flag, and contact GCP Support by providing the command's output.

IP space of {USER_SUBNETWORK_NAME} is exhausted and needs to be expanded.

If the deployment fails with this error message, it means that the network configured for the App Engine service doesn't have addresses left to allocate, for the new instances of the service. You can resolve the issue by expanding the VPC ranges on the subnet configured for your App Engine flexible environment service.