You can run your applications in App Engine using the flexible environment or standard environment. You can also choose to simultaneously use both environments for your application and allow your services to take advantage of each environment's individual benefits.
The App Engine environments
App Engine is well suited to applications that are designed using a microservice architecture, especially if you decide to utilize both environments. Use the following sections to learn and understand which environment best meets your application's needs.
When to choose the standard environment
Application instances run in a sandbox, using the runtime environment of a supported language listed below.
Applications that need to deal with rapid scaling.
The standard environment is optimal for applications with the following characteristics:
Source code is written in specific versions of the supported
- Python 2.7, Python 3.7, Python 3.8
- Java 8, Java 11
- Node.js 8, Node.js 10, and Node.js 12
- PHP 5.5, PHP 7.2, PHP 7.3, and PHP 7.4
- Ruby 2.5, Ruby 2.6, and Ruby 2.7
- Go 1.11, Go 1.12, Go 1.13, and Go 1.14
- Intended to run for free or at very low cost, where you pay only for what you need and when you need it. For example, your application can scale to 0 instances when there is no traffic.
- Experiences sudden and extreme spikes of traffic which require immediate scaling.
When to choose the flexible environment
Application instances run within Docker containers on Compute Engine virtual machines (VM).
Applications that receive consistent traffic, experience regular traffic fluctuations, or meet the parameters for scaling up and down gradually.
The flexible environment is optimal for applications with the following characteristics:
Source code that is written in a version of any of the supported
Python, Java, Node.js, Go, Ruby, PHP, or .NET
- Runs in a Docker container that includes a custom runtime or source code written in other programming languages.
- Uses or depends on frameworks that include native code.
- Accesses the resources or services of your Google Cloud project that reside in the Compute Engine network.
Comparing high-level features
The following table summarizes the differences between the two environments:
|Feature||Standard environment||Flexible environment|
|Instance startup time||Seconds||Minutes|
|Maximum request timeout||Depends on the runtime and type of scaling.||60 minutes|
|Background threads||Yes, with restrictions||Yes|
|Scaling||Manual, Basic, Automatic||Manual, Automatic|
|Scale to zero||Yes||No, minimum 1 instance|
|Writing to local disk||
||Yes, ephemeral (disk initialized on each VM startup)|
|Modifying the runtime||No||Yes (through Dockerfile)|
|Automatic in-place security patches||Yes||Yes (excludes container image runtime)|
|Access to Google Cloud APIs & Services such as Cloud Storage, Cloud SQL, Memorystore, Tasks and others.||Yes||Yes|
Java 8, Python 2, and PHP 5 provide a proprietary Sockets API (beta), but the API is not available in newer standard runtimes.
|Supports installing third-party binaries||
|Location||North America, Asia Pacific, or Europe||North America, Asia Pacific, or Europe|
|Pricing||Based on instance hours||Based on usage of vCPU, memory, and persistent disks|
Comparing the flexible environment to Compute Engine
The App Engine flexible environment has the following differences to Compute Engine:
Flexible environment VM instances are restarted on a weekly basis. During restarts, Google's management services apply any necessary operating system and security updates.
You always have root access to Compute Engine VM instances. By default, SSH access to the VM instances in the flexible environment is disabled. If you choose, you can enable root access to your app's VM instances.
Code deployments can take longer as container images are built by using the Cloud Build service.
The geographical region of a flexible environment VM instance is determined by the location that you specify for the App Engine application of your Cloud project. Google's management services ensures that the VM instances are co-located for optimal performance.