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.
You should use the appengine-web.xml file for configuring your app only
if you are migrating an existing app from the App Engine Java 8 runtime to the
latest supported Java version and you want to use the legacy bundled services.
If you are using an appengine-web.xml in your project, the app.yaml is
automatically generated for you at deployment.
App Engine Java applications use a configuration file, named appengine-web.xml,
to specify information about your app and to identify which files in the app's
WAR file are static files (like images) and which are resource files used by
the application.
Syntax
An App Engine Java app must have a file named appengine-web.xml in its
WAR, in the directory WEB-INF/. This is an XML file whose root element is
.
You can find the Document Type Definition and schema specifications for the
appengine-web.xml in the SDK's docs/ directory.
Element
Description
Not required if you deploy your app using Google Cloud SDK-based
tooling, such as the gcloud app deploy command, IntelliJ
or Eclipse plugins, Maven or Gradle plugins. The
Google Cloud SDK-based tooling ignore this element and
get the project ID from the gcloud config project property. Note that
although you can override the project ID using the gcloud
command line tool, this sets a machine-wide project ID, which may cause
confusion if you are developing multiple projects.
The element contains the
application's project ID. This is the project ID you register when you
create your project in the Google Cloud console.
Optional and only for second-generation runtimes.
Overrides the default entrypoint which is the process command
line that boots the Java application. By default, the generated
entrypoint for a F4 instance class (memory settings are calculated
from the instance class) is equivalent to the following configuration:
You can modify the configuration to add extra JVM process flags or define your own process to boot.
Notice that the application is deployed in the /workspace directory,
while the runtime JARs are located under /base/java_runtime directory.
Optional.
It's possible to reduce request latency by configuring your
application to asynchronously write HTTP session data to the
datastore:
enabled="true"/>
With async session persistence turned on, App Engine will
submit a Task Queue task to write session data to the datastore before
writing the data to memcache.
By default the task will be submitted to the `default` queue. If you'd
like to use a different queue, add the `queue-name` attribute:
enabled="true"queue-name="myqueue"/>
Session data is always written synchronously to memcache. If a
request tries to read the session data when memcache is not available
(or the session data has been flushed), it will fail over to Datastore,
which might not yet have the most recent session data. This
means that asynchronous session persistence can cause your application
to see stale session data. However, for most applications the latency
benefit far outweighs the risk.
Default. Uses scattered auto IDs that are large well-distributed
integers that are small enough to be represented by 64-bit floats.
legacy
The legacy option will be deprecated in a future release and will
eventually be removed. For more information, see the blog post announcing this
change.
Optional. For a full explanation, see the automatic scaling
section.
Optional. For a full explanation, see the basic scaling section.
Optional.
The appengine-web.xml file can define environment variables
that are set when the application is running.
name="DEFAULT_ENCODING"value="UTF-8"/>
To avoid conflicts with your local environment, the development server
does not set environment variables based on this file, and requires
that the local environment have these variables already set to
matching values.
exportDEFAULT_ENCODING="UTF-8"
dev_appserverwar
When deployed to App Engine, the environment is created with
these variables already set.
Optional.
Before an application can receive email, the
application must be configured to enable the service.
You enable the service for a Java app by including an
section in the
appengine-web.xml file.
When using manual scaling, the B1, B2, B4, B4_1G, and B8
instance classes are available.
Default: B2 is assigned if you do not specify a
instance class along with the manual_scaling element.
Note: If instance-class
is set to F2 or higher, you can optimize your instances by setting
max-concurrent-requests
to a value higher than 10, which is the default.
To find the optimal value, gradually increase it and monitor the performance of your
application.
Optional. For a full explanation, see the manual scaling section.
Optional.
App Engine uses a "precompilation" process with the Java bytecode of
an app to enhance the performance of the app in the Java runtime
environment. Precompiled code functions identically to the original
bytecode.
If for some reason you prefer that your app not use precompilation,
you can turn it off by adding the following to your
appengine-web.xml file:
false
Note: Modules are now named
Services
and services are still declared in appengine-web.xml
files as modules, for example:
service_name.
Required if creating a service. Optional for the default service.
Each service and each version must have a name. A name can contain
numbers, letters, and hyphens. It cannot be longer than 63 characters,
start or end with a hyphen, and contain the
string `-dot`. Choose a unique name for each service and each
version. Don't reuse names between services and versions.
Optional.
The is a directory in your application
that contains the static files for your application. When a request
for a static file is made, the for your
application is prepended to the request path. This gives the path of
an application file containing the content that is being requested.
The default is /.
For example, the following would map the URL path
/index.html to the application file path
/static/index.html:
/static
Optional. The files listed in the
element are accessible by the
application code using the filesystem. These files are stored on the
application servers with the app as opposed to how static files are
stored and served.
The element can contain the
following elements:
An element designates the files as
resource files and available to your application code. These files
are only available to your code on a read-only basis and not for
traffic serving.
Including and excluding files.
Files and directories matching
patterns will not be uploaded or available to your application
code. However, these files and directories will still be
accessible to your application when running on the local
Development Server. For more information, see
Including and excluding files.
Example:
path="/**.xml"/>
path="/feeds/**.xml"/>
This example demonstrates how to designate all .xml
files as resource files except those in the feeds/
directory and all of its subdirectories.
App Engine resource files are read using java.io.File or
javax.servlet.ServletContext.getResource/getResourceAsStream.
They are not accessible via Class.getResourceAsStream().
To use the latest supported Java version, you must specify this entry with the value
java21.
Currently, defining a service as:
service_name
is supported only by gcloud app
commands.
Optional. The element lets you specify a
user-managed service account
as the identity for the version. The specified service account will be
used when accessing other Google Cloud services and executing tasks.
Optional.
App Engine includes an implementation of sessions, using the servlet session interface.
The implementation stores session data in Datastore for
persistence, and also uses memcache for speed. As with most other servlet
containers, the session attributes that are set with `session.setAttribute()`
during the request are persisted at the end of the request.
This feature is off by default. To turn it on, add the following to
appengine-web.xml:
Example:
true
The implementation creates Datastore entities of the kind
_ah_SESSION, and memcache entries using keys with a
prefix of _ahs. You can delete these entities using the
Dataflow template.
Note: Because App Engine stores session data in
Datastore and memcache, all values stored in the session must
implement the java.io.Serializable interface.
Optional.
By default, any user can access any URL using either HTTP or HTTPS.
You can configure an app to require HTTPS for certain URLs in the
deployment descriptor. See Deployment
Descriptor: Secure URLs.
If you want to disallow the use of HTTPS for the application, put the
following in the appengine-web.xml file:
false
There is no way to disallow HTTPS for some URL paths and not others in the Java
runtime environment.
Optional.
When certain errors occur, App Engine serves a generic error
page. You can configure your app to serve a custom static file instead
of these generic error pages, so long as the custom error data is less
than 10 kilobytes. You can set up different static files to be served
for each supported error code by specifying the files in your app's
appengine-web.xml file. To serve custom error pages, add a
section to your
appengine-web.xml, as ins this example:
Warning: Make sure that the path to the error
response file does not overlap with static file handler paths.
Each file entry indicates a static file that should be
served in place of the generic error response. The
error-code indicates which error code should cause the
associated file to be served. Supported error codes are as follows:
Optional.
The element specifies patterns that
match file paths to include and exclude from the list of static files,
overriding or amending the default behavior. Static file are served
from dedicated servers and caches that are separate from the
application servers and are useful for serving static content such as
images, CSS stylesheets or JavaScript files.
The element can contain the
following elements:
An element overrides the default
behavior of including all non-JSP files. The
element can specify HTTP
headers to use when responding to request for the specified
resources. For more information, see
Including and excluding
files.
You can override the default static cache expiration by specifying
the expiration attribute on the include element.
The value is a string of numbers and units, separated by spaces, where units can
be d for days, h for hours, m for minutes, and s for seconds. For
example, "4d 5h" sets cache expiration to 4 days and 5 hours after the file is
first requested.
For more information,
see Cache
expiration.
Files and directories matching
patterns will not be uploaded when you deploy your app to
App Engine. However, these files and directories will still
be accessible to your application when running on the local
Development Server. For more information, see
Including and excluding
files.
Optional. You can configure an HTTP connector for improving CPU and
memory utilization.
name="appengine.use.httpconnector"value="true"/>
Optional. You can configure the underlying runtime to work
on EE8 or EE10 using the following system property. For more
information regarding EE support, see Upgrade to Java 21.
name="appengine.use.EE10"value="true"/>
Starting in Java 21, you can configure your
Java web server to use virtual threads. For example:
The default value is native, which means that standard
Java network classes use the standard Java HTTP(S) transport.
To use this setting, you must enable billing for your app, or you
will get exceptions, which are documented in
Issue requests.
If you set url-stream-handler to
urlfetch,
URL.openConnection
and related methods will use URL Fetch for http and https transport.
urlfetch
The element contains the version
identifier for the latest version of the app's code. The version
identifier can contain lowercase letters, digits, and hyphens. It
cannot begin with the prefix "ah-" and the names "default" and
"latest" are reserved and cannot be used.
Version names should begin with a letter, to distinguish them from
numeric instances which are always specified by a number. This avoids
the ambiguity with URLs like 123.my-module.uc.r.appspot.com,
which can be interpreted two ways: If version "123" exists, the target
will be version "123" of the given module. If that version does not
exist, the target will be instance number 123 of the default version
of the
module.
Optional. Default: true. Warmup requests are enabled by default for
Java applications.
With warmup requests enabled, the App Engine infrastructure issues `GET`
requests to /_ah/warmup, initializing
servlets, ServletContextListeners, and
custom warmup servlets,
which allow you to initialize your application's code as it requires.
You might need to implement your own handler for
/_ah/warmup depending on which of these methods you
choose.
To disable warmup requests, specify false for this
element:
false
Optional.
Configures your application to use a Serverless VPC Access
connector, enabling the application to send requests to internal
resources in your VPC network. Specify the fully-qualified name of a
connector in the element:
Optional. Automatic scaling is assumed by default with a default
instance class of F1 unless specified otherwise.
The automatic_scaling element sets minimum and maximum
levels for number of instances, latency, and concurrent connections
for a module.
This element can contain the following elements:
Optional. Specify a value from 0.5 to 0.95.
This parameter specifies
the CPU usage threshold at which new instances will be
started to handle traffic, enabling you to balance between
performance and cost, with lower values increasing performance and
increasing cost, and higher values decreasing performance but
also decreasing cost. For example, a value of 0.7 means that new
instances will be started after CPU usage reaches 70 percent.
Optional. Specify a value from 0.5 to 0.95.
Used with max-concurrent-requests to specify when
a new instance is started due to concurrent requests. When the
number of concurrent requests reaches a value equal to
max-concurrent-requests times
target-throughput-utilization, the scheduler starts
a new instance.
Optional. The maximum number of instances for App Engine to create
for this application version. This is useful to limit the costs of a
module. Specify a value between 0 and 2147483647.
Optional. The minimum number of instances for App Engine to create
for this module version. These instances serve traffic when
requests arrive, and continue to serve traffic even when
additional instances are started up as required to handle traffic.
Specify a value from 0 to 1000. You can set
the parameter to the value 0 to allow scaling to 0 instances to
lower costs when no requests are being served. Note that you are
charged for the number of instances specified whether they are
receiving traffic or not.
Optional. The number of concurrent requests an automatic scaling
instance can accept before the scheduler spawns a new instance
(Default: 10, Maximum: 80).
You might experience increased API latency if this setting is too
high. Note that the scheduler might spawn a new instance before
the actual maximum number of requests is reached.
Note: If instance-class
is set to F2 or higher, you can optimize your instances by setting
max-concurrent-requests to a value higher than 10, which is the default.
To find the optimal value, gradually increase it and monitor the performance of your
application.
The maximum number of idle instances that App Engine should
maintain for this version. The default value is "automatic."
Keep the following in mind:
A high maximum reduces the number of idle instances more
gradually when load levels return to normal after a spike. This
helps your application maintain steady performance through
fluctuations in request load, but also raises the number of idle
instances (and consequent running costs) during such periods of
heavy load.
A low maximum keeps running costs lower, but can degrade
performance in the face of volatile load levels.
Note: When settling back to normal levels after a
load spike, the number of idle instances can temporarily exceed
your specified maximum. However, you will not be charged for more
instances than the maximum number you've specified.
The maximum amount of time that App Engine should allow a request
to wait in the pending queue before starting additional instances
to handle requests so that pending latency is reduced.
A low maximum means App Engine will start new instances sooner
for pending requests, improving performance but raising running
costs.
A high maximum means users might wait longer for their requests
to be served, if there are pending requests and no idle
instances to serve them, but your application will cost less to
run.
The number of instances to be kept running
and ready to serve traffic.This setting only applies to the
version that receives most of the traffic. Keep the following in
mind:
A low minimum helps keep your running costs down during idle
periods, but means that fewer instances might be immediately
available to respond to a sudden load spike.
A high minimum allows you to prime the application for rapid
spikes in request load. App Engine keeps the minimum number of
instances running to serve incoming requests. You are charged
for instances, whether or not they are handling
requests. For this feature to function properly, you
must make sure that
warmup requests are enabled and that your application
handles warmup requests.
If you set a minimum number of idle instances, pending latency
will have less effect on your application's performance.
Because App Engine keeps idle instances in reserve, it is
unlikely that requests will enter the pending queue except in
exceptionally high load spikes. You will need to test your
application and expected traffic volume to determine the ideal
number of instances to keep in reserve.
The minimum amount of time in seconds that App Engine should allow
a request to wait in the pending queue before starting a new
instance to handle it. Specify a value from 0.01 to 15.
A low minimum means requests must spend less time in the pending
queue when all existing instances are active. This improves
performance but increases the cost of running your application.
A high minimum means requests will remain pending longer if all
existing instances are active. This lowers running costs but
increases the time users must wait for their requests to be
served.
Much of the work done during a deployment occurs locally in a preparation step
called staging, where JAR files are assembled, JSPs are compiled, and so forth.
You can optionally configure certain parts of the staging
behavior using staging elements in the application configuration file. Most
applications will deploy successfully without manually configuring staging
behavior. If your app doesn't deploy, you may need to configure staging
using the options shown below.
Element
Description
Optional. Most applications do not need to change default behavior.
The staging element allows you to specify a particular staging
configuration if needed for deployment.
This element can contain the following elements:
Optional. Split large jar files (> 10 Megabytes) into smaller
fragments.
(Default: true).
Specifies a comma-separated list of file suffixes.
If enable-jar-splitting is enabled, all files that
match the suffixes will be excluded from all JARs.
Do not jar classes generated from JSPs.
(Default: false).
Jar the contents of WEB-INF/classes.
(Default: true).
Delete the JSP source files after compilation.
(Default: true).
Input encoding of source files for compilation.
(Default: utf-8).
For example:
false
Staging option defaults
The defaults for staging options are different depending on whether you use
Google Cloud SDK-based tooling, such as the gcloud CLI, or the
Google Cloud SDK-based
Maven,
Gradle,
Eclipse, or IntelliJ plugins.
Staging element
App Engine SDK-based defaults -
Google Cloud SDK-based defaults
enable-jar-splitting
false
true
jar-splitting-excludes
NA
NA
disable-jar-jsps
false
false
enable-jar-classes
false
true. This can impact class loading order, so if your app depends on a certain order using the former false default, you can set this to false.
delete-jsps
false
true
compile-encoding
utf-8
utf-8
Include and exclude syntax
Path patterns are specified using zero or more and
elements. In a pattern, '*' represents zero or more
of any character in a file or directory name, and ** represents zero or more
directories in a path. Files and directories matching
patterns will not be uploaded when you deploy your app to App Engine. However,
these files and directories will still be accessible to your application when
running on the local Development Server.
An element overrides the default behavior of including
all files. An element applies after all
patterns (as well as the default if no explicit
is provided).
The following example demonstrates how to designate all .png files as static
files (except those in the data/ directory and all of its subdirectories):
By default, static files are served using a MIME type selected based on the
filename extension. You can associate custom MIME types with filename
extensions for static files using mime-mapping elements in web.xml.
URLFetch timeout
You can set a deadline for each
URLFetch request. By default, the deadline for a fetch is 5 seconds.
You can change this default by including the following setting in your
appengine-web.xml configuration file. Specify the timeout in seconds:
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-06-10 UTC."],[[["The `appengine-web.xml` file, located in the `WEB-INF/` directory of a WAR file, is essential for configuring App Engine Java applications, including settings for static files, resource files, and non-default services."],["`appengine-web.xml` includes elements like `\u003capplication\u003e` (project ID), `\u003capp-engine-apis\u003e` (legacy services), `\u003centrypoint\u003e` (custom entry point), and numerous others, to manage various aspects of application behavior such as scaling, environment variables, and session management."],["Scaling configurations in `appengine-web.xml` are defined through elements like `\u003cautomatic-scaling\u003e`, `\u003cbasic-scaling\u003e`, and `\u003cmanual-scaling\u003e`, each allowing control over instance management, CPU utilization, request handling, and idle behavior."],["Staging elements within `appengine-web.xml` enable customization of the deployment preparation process, including splitting large JAR files, handling JSP compilation, and managing the inclusion or exclusion of specific files, with different defaults depending on whether the App Engine SDK or Google Cloud SDK is used."],["Static files are managed with `\u003cstatic-files\u003e` and `\u003cresource-files\u003e`, through include and exclude rules using `*` and `**` wildcards, and mime-types that can be defined in `web.xml`."]]],[]]