Note: For new projects you create after March 2025, App Engine sets theautomatic scaling maximum instances default for standard environment deploymentsto 20. This change doesn't impact existing apps. To override the default, specifya newmax_instancesvalue in yourapp.yaml file, and deploy a new version or redeploy over anexisting version.

Instances are the basic building blocks of App Engine, providing all theresources needed to successfully host your application. At any given time, yourapplication can be running on one or many instances with requests being spreadacross all of them. Each instance includes a security layer to ensure thatinstances cannot inadvertently affect each other.

App Engine can automatically create and shut down instances as trafficfluctuates, or you can specify a number of instances to run regardless of theamount of traffic. To determine how and when new instances are created, youspecify ascaling type for your app. The scaling settings are applied at theApp Engine version level as part of theapp.yamlfile.

Scaling types

App Engine supports the followingscaling types, which controls howand when instances are created:

• Automatic (default)
• Basic
• Manual

You specify the scaling type in your app'sapp.yaml.By default, your app uses automatic scaling, which means App Engine willmanage the number of idle instances.

Automatic scaling

Automatic scaling creates instances based on request rate, response latencies,and other application metrics. You can specify thresholds for each of thesemetrics, as well as a minimum number instances to keep running at all timesby configuring theautomatic_scaling element.

Basic Scaling

Basic scaling creates instances when your application receives requests. Eachinstance will be shut down when the application becomes idle. Basic scaling isideal for work that is intermittent or driven by user activity.

Manual scaling

Manual scaling specifies the number of instances that continuously runregardless of the load level. This allows tasks such as complex initializationsand applications that rely on the state of the memory over time.

Scaling dynamic instances

App Engine applications that use basic or automatic scaling are poweredby any number of dynamic instances at a given time, depending on the volume ofincoming requests. As requests for your application increase, the number ofdynamic instances may increase as well.

Apps with basic scaling

If you use basic scaling, App Engine attempts to keep your cost low,even though that may result in higher latency as the volume of incoming requestsincreases.

When none of the existing instances are available to serve an incoming request,App Engine starts a new instance. Even after starting a new instance,some requests may need to be queued until the new instance completes itsstartupprocess.If you require the lowest latency possible consider using automatic scaling,which creates new instances preemptively to minimize latency.

Apps with automatic scaling

If you use automatic scaling, each instance in your app has its own queue forincoming requests. Before the queues become long enough to have a noticeableeffect on your app's latency, App Engine automatically creates one ormore new instances to handle the increasing load.

You can configure the settings for automatic scaling to achieve a trade-offbetween the performance you want and the cost you can incur. The following tabledescribes these settings.

Watch the App EngineScheduler settingsvideo to see the effects of these settings.

Scaling down

When request volumes decrease, App Engine reduces the number of instances.This downward scaling helps ensure that all of your application's currentinstances are being used for optimal efficiency and cost effectiveness.

When an application is not being used at all, App Engine turns off itsassociated dynamic instances, but readily reloads them as soon as they areneeded. Reloading instances can result in loading requests and additionallatency for users.

You can specify a minimum number of idle instances. Setting an appropriatenumber of idle instances for your application based on request volume allowsyour application to serve every request with little latency, unless you areexperiencing abnormally high request volume.

Scaling down in automatic scaling

If your app uses automatic scaling, it takes approximately 15 minutes ofinactivity for the idle instances to start shutting down. To keep one or moreidle instances running, set the value ofmin_idle_instancesto1 or higher.

Scaling and batches of requests

If you are sending batches of requests to your services, for example, to a taskqueue for processing, a large number of instances will be created quickly. Werecommend controlling this by rate limiting the number of request sent persecond, if possible. For example, if you use Google Tasks, youcancontrol the rate at which tasks arepushed.

Instance life cycle

Instance states

An instance of an auto-scaled service is always running. However, an instance ofa manual or basic scaled service can be either running or stopped. All instancesof the same service and version share the same state. You change the state ofyour instances by managing your versions. You can:

• Use theVersions page in theGoogle Cloud console
• Usegcloud app versions startandgcloud app versions stop commands

Startup

Each service instance is created in response to a start request, which is anempty HTTPGET request to/_ah/start. App Engine sends this requestto bring an instance into existence; users cannot send a request to/_ah/start. Manual and basic scaling instances must respond to the startrequest before they can handle another request. The start request can be usedfor two purposes:

• To start a program that runs indefinitely, without accepting further requests.
• To initialize an instance before it receives additional traffic.

Manual, basic, and automatically scaling instances startup differently. When youstart a manual scaling instance, App Engine immediately sends a/_ah/start request to each instance. When you start an instance of a basicscaling service, App Engine allows it to accept traffic, but the/_ah/start request is not sent to an instance until it receives its first userrequest. Multiple basic scaling instances are only started as necessary, inorder to handle increased traffic. Automatically scaling instances do notreceive any/_ah/start request.

When an instance responds to the/_ah/start request with an HTTP status codeof200–299 or404, it is considered to have successfully started and canhandle additional requests. Otherwise, App Engine terminates theinstance. Manual scaling instances are restarted immediately, while basicscaling instances are restarted only when needed for serving traffic.

Shutdown

The shutdown process might be triggered by a variety of planned and unplannedevents, such as:

• There are too many instances and not enough app requests (traffic).
• You manually stop an instance.
• You deploy an updated version to the service.
• The instance exceeds the maximum memory for its configuredinstance_class.
• Your application runs out of Instance Hours quota.
• Your instance is moved to a different machine, either because the currentmachine that is running the instance is restarted, or App Engine movedyour instance to improve load distribution.

One of the benefits App Engine standard environment's "pay for only what you need" platform asdescribed earlier inScaling Down is that the system autoscalesthe number of instances down to zero when there is no traffic. This helps makeApp Engine a cost-effective solution for small applications that don't receivecontinuous requests. When an instance needs to be shut down, new incomingrequests are routed to other instances (if any) and requests that are currentlybeing processed are given time to complete.

App Engine normally sends aSTOP (SIGTERM) signal to the app container.Your app does not need to respond to this event, but it can use this to performany necessary clean-up actions before the container is shut down. Undernormal conditions, the system waits up to 2 seconds for theapp to stop and then sends aKILL (SIGKILL) signal. If your app does notcatch theSIGTERM signal, the instance is immediately shut down.

Some instance shutdown log messages you might see include:

[start]Quittingonterminatedsignal[INFO]Handlingsignal:term[INFO]Workerexiting(pid:21)[INFO]Workerexiting(pid:24)[INFO]Shuttingdown:Master[start]Startprogramfailed:terminationtriggeredbynginxexit

These log messages do not indicate any error condition but are indications ofthe normal instance shut down process. Note that[start] andStart in thelogs refer to a platform process namedstart and has nothing to do withstarting an instance or an app.

Loading requests

When App Engine creates a new instance for your application, theinstance must first load any libraries and resources required to handle therequest. This happens during the first request to the instance, called aLoading Request. During a loading request, your application undergoesinitialization which causes the request to take longer.

The following best practices allow you to reduce the duration of loadingrequests:

• Load only the code needed for startup.
• Access the disk as little as possible.
• In some cases, loading code from a zip or jar file is faster than loading frommany separate files.

Warmup requests

Warmup requests are a specific type of loading request that load applicationcode into an instance ahead of time, before any live requests are made.Manual or basic scaling instances do not receive an/_ah/warmup request.

To learn more about how to use warmup requests, seeConfiguring warmuprequests.

Instance uptime

App Engine attempts to keep manual and basic scaling instances runningindefinitely. However, at this time there is no guaranteed uptime for manual andbasic scaling instances.

NTP with App Engine standard environment

The App Engine standard environment has network time protocol (NTP) services which use Google NTP servers. However, the NTP serviceis not editable.

Manage services

Depending on thescaling type of your instance, you can manageservices and versions in the Google Cloud console or Google Cloud CLI.

Stop a version

Each version in App Engine runs within one or more instances, dependingon how much traffic you configured it to handle.

Click the tab for instructions on using the tool of your choice:

  gcloud app versions stop --service=SERVICEVERSION

Delete a service

Each service can be configured to use different runtimes and to operate withdifferent performance settings. You can't delete the default service. Deleting aservice also deletes all of its accompanying versions in your project.

Click the tab for instructions on using the tool of your choice:

  gcloud app services deleteSERVICE