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. Including
REGION_ID.r in App Engine URLs is optional for
existing apps and will soon be required for all new apps.
To ensure a smooth transition, we are slowly updating App Engine to use region IDs. If we haven't updated your Google Cloud project yet, you won't see a region ID for your app. Since the ID is optional for existing apps, you don't need to update URLs or make other changes once the region ID is available for your existing apps.
Learn more about region IDs.
Use the following document to understand how to structure the services and related resources of your app for App Engine.
Each version of your App Engine service is defined in an
configuration file. For simple apps, the minimum requirement for deployment is
to define the
app.yaml file. The
app.yaml file acts as a deployment
descriptor and defines the scaling type and the
runtime, handlers, and other resource
settings for a specific
version of a service. If you are deploying several versions of a service, you
can create multiple YAML files in the same directory to represent the
configuration for each of your versions.
For each service, you can create separate directories in the root of your app
when you are developing locally. If you host your app out of a version control
system (VCS), for example GitHub, you can also structure your app to use
separate directories in a repository, or use separate repositories for each
service. Each directory or repository should represent a single service and
contain that service's
app.yaml file along with the associated source code.
You have the option of specifying a unique name for each of your service's
app.yaml file. For example, you can name a configuration file after your
service, or use unique names to represent each version of that particular
The other optional configuration files should
reside in the root directory or repository of the
default service of your app. These optional
configuration files apply app-wide settings that are not specific to a
particular service, including the
The following example demonstrates what an app with three services might look
like if you are developing your app locally. The optional
been added to that app in the root directory. Also in the root are three
directories for each of the app's services. The subdirectory for
includes the source and configuration files for that service. Similarly, both
service3 are in separate directories, which contain each
service's files, although
service3 includes two versions of the YAML
For a single
service app, that app will only include the
default service and all the files can live in the same
directory, at the root of that
app. In the following example, the possible structure of a single service
app is demonstrated and includes the optional
dispatch.yaml configuration file
and two configuration files that represent different versions of that service,
Design considerations for instance uptime
Hardware or software failures that cause early termination or frequent instance restarts can occur without warning and can take considerable time to resolve. Your application should be able to handle such failures.
Here are some good strategies for avoiding downtime due to instance restarts:
- Reduce the amount of time it takes for your instances restart or for new ones to start.
- For long-running computations, periodically create checkpoints so that you can resume from that state.
- Your app should be "stateless" so that nothing is stored on the instance.
- Use queues for performing asynchronous task execution.
- If you configure your instances to manual scaling:
- Use load balancing across multiple instances.
- Configure more instances than required to handle normal traffic.
- Write fall-back logic that uses cached results when a manual scaling instance is unavailable.
Learn more about instances at How Instances are Managed.
Every App Engine application includes a
default service. You must
deploy the initial version of your app to the
default service before you can
create and deploy additional services to your app.
The default service can be optionally specified
app.yaml with the setting
Requests sent to your app using your Cloud project are sent to the
default service, for example,
https://PROJECT_ID.REGION_ID.r.appspot.com. To learn
more about targeting your other services, see Communicating Between
Optional configuration files
The following configuration files control optional features that apply to all of the services in an individual app. See the following topics for details about each of the optional features:
Data and file storage considerations
You also have the option to use an external or third-party database if that database is supported by your language and accessible from your App Engine instance.For details about storing files in Google Cloud or externally, see Understanding Data and File Storage.
You can also choose how you want to serve your static content. You can serve your app's static content directly from that app in App Engine, host your static content on a Google Cloud option like Cloud Storage, or use a third-party content delivery network (CDN). For more information about serving static content, see Serving Static Files.