Google Cloud Platform
Managed VMs

Managed VMs

The Managed VM hosting environment

When your App Engine application is running in the cloud, Google provides a scalable number of instances of your app's modules. Each instance runs in its own hosting environment. From the beginning, the App Engine hosting environment has been a sandbox, containing your code, a webserver, and a language runtime. Aside from your application code, the other components in the App Engine hosting environment are immutable and managed by Google. The language runtime is modified in order to enforce the sandbox constraints, disabling some of the usual language APIs (such as access to the file system).

App Engine now offers a second hosting option: Managed VMs. The managed VM hosting environment lets you run App Engine applications on configurable Compute Engine Virtual Machines (VMs). The VM hosting environment offers more flexibility and provides more CPU and memory options.

Applications that run on managed VMs are not subject to the restrictions imposed on the sandboxed runtimes (Java, Python, PHP, and Go).

app engine hosting environments

Google manages the underlying VM hosting environment, ensuring that:

  • instances are health-checked, healed as necessary, and co-located with other module instances within the project
  • critical, backwards compatible updates are automatically rolled out to the underlying operating system

You can choose the hosting environment (sandboxed or managed VM) separately for each module in your application. This means an application can contain a mix of modules that use different hosting environments. For instance, you might use the sandbox environment for your client-facing frontend, and use a module running in a managed VM for backend processing. Note that every instance of any specific module will run in the same type of environment.

The following table summarizes the differences between the two App Engine hosting enviroments:

Feature App Engine sandbox Managed VM
Instance startup time Milliseconds Minutes
Maximum Request Timeout 60 seconds 24 hours
Background threads Yes, with restrictions Yes
Background processes No Yes
SSH debugging No Yes
Scaling Manual, Basic, Automatic Manual, Automatic
Writing to local disk No Yes, ephemeral (disk initialized on each VM startup)
Customizable serving stack No Yes (built by customizing a Dockerfile)
Automatic in-place security patches Yes Yes
Network access Only via App Engine services (includes outbound sockets) Yes
Supports installing third party binaries No Yes
Location United States or European Union While in Beta, United States only. European Union-hosted applications should not deploy Managed VM modules.
Pricing Based on Instance hours While in Beta, based on Compute Engine Pricing for each VM. Pricing will change in the future.

Also, note that Managed VMs differ from Compute Engine VMs in the following ways:

  • Managed VMs are restarted on a weekly basis. During restarts Google’s management services will apply any necessary OS and security updates. Your application's image will remain the same across restarts. (Weekly restarts are disabled if you switch a VM to user-managed.)
  • Users always have root access to Compute Engine VMs. SSH access to managed VMs is disabled by default. This ensures that the fleet of compute instances is homogenous and manageable. If you choose, you can enable root access to managed VMs; see Accessing VMs.
  • Managed VMs are automatically located by geographical region according to the settings in your project. Google’s management services will ensure that all the managed VMs for a project are co-located for optimal performance.

Container technology

Managed VMs use software containers to run multiple user spaces in one Google Compute Engine instance. A container is portable and isolates the runtime environment from the target machine. This means you can develop an application in a container that you test locally, and then deploy the identical environment to the cloud.

Managed VMs build and run Docker container images, which are specified by a Dockerfile. The file includes all the system and application software necessary to run your app, along with dependency rules that keep everything up to date. You use Google Cloud SDK commands to run this container on your local machine, or deploy it to App Engine in the cloud.


You can build a managed VM application on a standard runtime, which is based on a Google-supplied Dockerfile (which can be modified and extended), or a custom runtime, which is based on a Dockerfile that you write from scratch.

Standard Runtimes

A standard runtime is defined by a docker image that is preconfigured and created by Google. Every standard runtime contains a complete language implementation, with no sandbox constraints. A standard runtime has built-in support for the managed VM life-cycle and health checking requests, and also includes APIs that support these App Engine services:

Standard runtimes are available for Python, Java, and Go. Because standard runtimes are created and maintained by Google, they provide the highest level of reliability and support.

Using a standard runtime in a managed VM requires minimal setup. You only need to add a few lines to your app's configuration file.

Each standard runtime uses a default Dockerfile, which is supplied by the SDK. You can extend and enhance a standard runtime by adding new docker commands to this file.

Custom Runtimes

If you'd like to use an alternative implementation of Java, Python, or Go, or write code in any other language, custom runtimes are for you. Custom runtimes allow you to define new runtime environments, which might include additional components like language interpreters or application servers.

To create a custom runtime, you supply a Dockerfile with a base image of your choice, and add other docker commands as needed to build the desired runtime environment. Remember that with freedom comes responsibility. You must ensure that the components you've included in your Dockerfile are compatible, and are configured to deliver the desired performance.

When you use a custom runtime, you must write the application code to handle certain managed VM life-cycle and health checking requests. Read about custom runtimes before you start developing.

Applications using custom runtimes can take advantage of many Cloud Platform services using the public REST APIs, or client libraries, when they are available.

The following table compares the two kinds of runtimes.

Feature Standard Runtime Custom Runtime
Dockerfile Default file supplied automatically by the SDK Hand-written by the developer
Dockerfile modifications permitted Yes Yes
Languages Python, Java, and Go Any software that can service HTTP requests
Configuration file Python and Go modules use app.yaml, Java modules use WAR and appengine-web.xml app.yaml
Start/Stop Request Requests are handled automatically by default. You may optionally write your own handlers. Your app will receive these requests but does not need to respond to them. You may optionally write your own handlers.
Health Checking Requests are handled automatically by default. You may optionally write your own handlers. You must write your own handlers or disable health checks.
App Engine Service APIs Some API support is baked in. Read the Python, Java, or Go page for each runtime. You must use the publicly available REST APIs for cloud services.