App Engine

Google App Engine General Questions

How do I sign into my Google App Engine account?

For normal Google Accounts, including Gmail users, you can log into your App Engine account by visiting:

For users with accounts through Google Apps:

  • https://appengine.google.com/a/<DOMAIN.COM>
  • Where <DOMAIN.COM> is the domain that your account is associated with.

How do I create a Cloud project for App Engine?

New applications are automatically created with a Cloud project, which is required if your App Engine app needs to work with other Cloud products or use other Google APIs. However, older legacy App Engine apps were not created with a Cloud project. To create a Cloud project for these older legacy apps, you can use the App Engine Admin console's Application Settings page. This page has a Cloud Integration section with a Create button you can use to create a Cloud project for your app; it also creates a default Google Cloud Storage bucket for your optional use.

What languages are supported by Google App Engine?

Currently, Google App Engine supports Java, Python, PHP, and Go. Additionally, your website templates can include JavaScript along with your HTML which, among other things, allows you to write AJAX-enabled web applications.

What type of certifications has App Engine received?

Google App Engine successfully completed the audit process for the SAS70 Type II, SSAE 16 Type II, ISO 27001, and ISAE 3402 Type II standards.

What are my rights to the projects I create?

Between Google and App Engine customers, the customer owns all intellectual property rights to their stored data and their application and project code. Google owns all intellectual property rights to App Engine and Google Cloud Platform's services and software.

For more information, including the definitions of these terms, see the Google Cloud Terms of Service.

What frameworks does Google App Engine Support?


App Engine's Java runtime works with many popular Java frameworks including Struts 2 and Spring MVC. App Engine also supports several popular JVM-compatible languages such as JRuby and Scala. All frameworks must operate inside the restrictions of App Engine's sandbox and only use the JRE classes in the JRE class white list.


App Engine can run most Python web frameworks out-of-the box with few or no modifications. For your convenience, Django is included with the Google App Engine SDK and is also available in the runtime when you deploy your application to the production environment. A GitHub example is available that shows how to use a Python Flask skeleton with Google App Engine. More information is available in the documentation on third-party libraries.


The Go runtime for App Engine includes almost all of the standard library, including the net/http package, which is sufficient for writing complete web apps. Many third-party libraries also work on App Engine without any modification.

Managed VMs

You can use Managed VM's to create a custom runtime and install a different framework in your software stack.

Can I still develop a Google App Engine app if I don't have an account?

Absolutely! Even if you don't yet have a Google App Engine account you can always download our SDK and start developing.

How many applications can I create with Google App Engine?

Each account can host 25 free applications and an unlimited number of paid applications Google App Engine. You can delete your existing applications via the Admin Console if you want to create more, but you will not be able to re-register an application ID.

How can I disable one of my existing applications?

You can disable, and subsequently re-enable, your application in the "Application Settings" page in the Admin Console. You can also permenantly delete your application. For more information see the Admin Console FAQ.

What type of content is allowed on Google App Engine?

Please see our Terms of Service if you have questions on what kind of content is allowed with Google App Engine.

How do I read the system usage charts in the admin console for my app?

Your Google App Engine dashboard in the Admin Console has six graphs that give you a quick visual reference of your system usage. The information displayed in these graphs gives you a snapshot of resource consumption per second over a period of up to 30 days. Here are a list of the graphs you will see in the Admin Console:

  • Total Requests: The number of URIs requested from your application every second, including dynamic, static, and cached requests.
  • Total Errors: The number of errors generated by your application every second.
Requests by Type (Queries/Second)
  • Static Requests.
  • Dynamic Requests.
  • Cached Requests (served from the cache).

The average number of milliseconds your application takes to service a request (latency measure), including only dynamic requests. Includes the time it takes to process the request, but not the time it takes to deliver the request to the client.

Loading Latency

The average number of milliseconds your application takes to respond to its first request (latency measure). This will include loading and initializing the app. Includes the time it takes to process the request, but not the time it takes to deliver the request to the client.

Error Details
  • Total Errors: The number of errors generated by your application every second.
  • Quota Denials: The number of times a request to your application was denied due to exceeding quotas; see Quotas for a complete overview.
  • DoS API Denials: The number of requests detected (and blocked by App Engine) as DoS attacks against your application.
Traffic (Bytes/Second)
  • Sent: The number of bytes sent by your application every second, summed across all requests.
  • Received: The number of bytes that are received by your application every second, summed across all requests.
  • Total CPU: The amount of CPU megacycles your application uses every second.
  • API Calls CPU: The amount of CPU megacycles your application uses every second to call Google APIs.
Milliseconds Used/Second

The number of milliseconds per second your app is handling a request.

  • Total: Count of live instances.
  • Active: Count of live instances currently in use.
  • Billed: Count of live instances that have enabled billing.
Memory Usage (MB)

Combined memory usage of your app's instances.

Memcache Operations/Second

The rate of memcache key operations. For batch requests, each item in the batch counts as a key operation.

Memcache Traffic (Bytes/Second)
  • Sent: The volume of data sent to memcache.
  • Total: The combined values of sent and received.
  • Received: The volume of data received from memcache.
Memcache Compute Units/Second

A metric that approximates the resource cost of memcache as a function of the characteristics of each request (value size, read vs. mutation, etc.).

Memcache Total Cache Size (MB)
The cache is shared by all modules and versions in an app. This chart is not available if you've used the module and filter menus to display information for a specific module and/or version.

How is the current load report in my application's admin console generated?

The current load gives a breakdown of the number of requests for each URI requested from your application as well as some CPU stats for the URI. The request parameters are omitted from the path.

The leftmost column lists the URI path, starting with the most popular URI by total requests, which is listed under the "Requests" column. The number of requests is reset every Midnight PST. The "Req/Sec" column lists the short-term request rate of each URI.

The current load table provides two data points for CPU usage, "Avg CPU (API)" and "% CPU". The "Avg CPU (API)" displays the average amount of CPU a request to that URI has consumed over the past hour, measured in megacycles. The "% CPU" column shows the percentage of CPU that URI has consumed since midnight PST with respect to the other URIs in your application.

How do you generate the list of URIs showing the most errors in my application's admin console?

If any error occurs when attempting to load a URI, our system records that error. We then show the URIs that record the most errors in the past 24 hrs in the admin console. In addition to showing the total number of errors, we include the percentage of errors as the ratio of errors at the URI to total requests of that URI.

Applications who have not included a favicon.ico file may notice the URI /favicon.ico on the list of errorful URIs. Favicon.ico is a file that is requested by a user's web browser when it attempts to load the page. Favicon.ico is your website's icon, and is typically displayed in the user's browser URL bar, next to the web address of your site.

For your application, favicon.ico should be a static image. You can upload a favicon.ico file with your application, and in your app.yaml file configure your application to serve the image when the url /favicon.ico is requested. Below are example entries in appengine-web.xml (Java) and app.yaml (Python and Go). In the Python/Go example, favicon.ico is located in static/images. For simplicity, the same file is located in the root (war) directory in the Java example.


- url: /favicon\.ico
  static_files: static/images/favicon.ico
  upload: static/images/favicon\.ico


  <include path="/favicon.ico" />

What is GQL?

GQL is a query language that is used with the App Engine datastore. You can use it to query for entities in both the Python runtime environment as well as the datastore viewer in the Admin Console. It uses a SQL-like syntax to retrieve entire entities from your application's datastore and includes the ability to filter on properties, specify the sorting order of the results, and limit the number of entities returned. The full GQL language reference can be found here.

Is GQL available for Java?

GQL is not included in the Java SDK, however it can be used through the Cloud Datastore API. We recommend that Java developers use JDO or JPA instead of GQL because they are type-safe. Using JDO/JPA allows the developer to find out about mistakes in the IDE rather than at runtime, and allows less room for SQL injection attacks.

Why do my queries need to be covered by indexes, and how do I include them?

If you run a query that filters on multiple entity properties or orders results by multiple properties, you will need an index for that query. You must have an index for every query of that kind that you run with your application. The datastore index for a query maintains and updates a list of keys sorted in the manner that the query specifies to allow speedy access to the data in your datastore. A full explanation of datastore indexes can be found in our documentation (Java | Python | Go).

When you develop your application with Google App Engine SDK, every query you run automatically gets indexed when necessary. If you thoroughly test your application before uploading it to your website, all of the indexes your application will need will be included in your application's datastore-indexes.xml (Java) or index.yaml (Python or Go) files. You may manually add indexes if you find a query that was not covered by your development testing. For more information on how to write indexes for your application, see the index documentation.

Why were my indexes marked as Error?

They may be exploding indexes (Python | Java | Go), or may have encountered other similar problems when writing particular entities in your datastore. You can vacuum and re-attempt to build them by following the instructions in Queries (Python | Java | Go) and Indexes (Python | Java).

Why do my indexes stay Building or Deleting for long periods of time?

Even if you don't have many entities of the corresponding kind(s), the time indexes take to build or delete can vary widely depending on the total amount of data in your datastore, indexes currently building for other apps, and datastore load due to user requests, among other factors. In some cases, index jobs can take hours or even days to complete.

Even so, we can sometimes help with indexes that seem to be stuck. If you think this has happened to your indexes, feel free to ask us on the group.

In the past, index jobs sometimes slowed down because worker shards were too large to be completed within the lease period. We initially addressed this by increasing the lease period. Later, we started splitting individual tablets into shards.

How do I authenticate users of my application?

The Users service (Java | Python | Go) allows you to authenticate users who have a Google Accounts, user account on your own Google Apps domain, or an OpenID. (Note that the support for OpenID is experimental.) You choose one of these forms of authentication for your app. Please read our article on how to configure your application to authenticate against a Google Apps domain.

If your app uses Google Accounts, when your application requests a user sign in, the user is directed to a Google sign-in page to enter a username and password, or to create a new account. If your app uses OpenID and requests a sign-in, the user is directed to /_ah/login_required to provide an OpenID and password. After successfully signing in, the user is then returned to your website, and the user information is available to your application through the Users property.

Are there any third-party libraries not supported by Google App Engine?


For a list of compatible and incompatible libraries and frameworks, please see The JRE Class White List.


A small percentage of native C python modules, and subsets of native C python modules are not available with Google App Engine. A full list detailing native C Python module support can be found here. The disabled modules fall in to the following categories:

  • Libraries that maintain databases on disk are not enabled in Python for Google App Engine
  • The system does not allow you to invoke subprocesses, as a result some os module methods are disabled
  • Threading is not available
  • For security reasons, most C-based modules are disabled
  • Other features that are limited:
    • marshal is disabled
    • cPickle is aliased to pickle
    • System calls have been disabled

Please keep in mind that third party packages which use any of the above features will not function with Google App Engine (packages such as MySQL, PostgreSQL, etc).


The majority of pure Go packages work on Google App Engine. A package may not work because of one of these reasons:

  • The package imports syscall or unsafe.
  • The package uses cgo or assembly.
  • The package requires functions in packages that are locked down, such as writing to disk, or direct network access.

Why did my app get disabled?

An app may be disabled if it fails to abide by our Terms and Conditions. Additionally, if an application is found to be using an inordinate amount of system resources due to a bug or other issue leading to inefficient resource usage, we may disable the app so that the developer can fix the development issues using our development SDK before re-enabling the application on Google App Engine.

Why is my app over quota?

App Engine places quota limits on the amount of each system resource that an application can consume in a day. All applications have a default quota configuration, the "free quotas", which should allow for roughly 5 million pageviews a month for an efficient application. You can read more about system quotas in the quota documentation.

As your application grows, it may need a higher resource allocation than the default quota configuration provides. You can purchase additional computing resources by enabling billing for your application. Billing enables developers to raise the limits on all system resources and pay for even higher limits on CPU, bandwidth, storage, and email usage.

How do I report an application that is in violation of your Terms and Conditions?

To report an application that is in violation of the Google App Engine Terms and Condition, please contact us. We will determine if the application is in violation, and if necessary, contact the application's developer over the violation.

Should I use the SDK for serving external requests?

The dev_appserver is designed for local testing and disallows external connections by default. You can override this using the -a <hostname> flag when running it, but doing so is not recommended because the SDK has not been hardened for security and may contain vulnerabilities.

How do I serve compressed content?

Google App Engine does its best to serve gzipped content to browsers that support it. Taking advantage of this scheme is automatic and requires no modifications to applications.

We use a combination of request headers (Accept-Encoding, User-Agent) and response headers (Content-Type) to determine whether or not the end-user can take advantage of gzipped content. This approach avoids some well-known bugs with gzipped content in popular browsers. To force gzipped content to be served, clients may supply 'gzip' as the value of both the Accept-Encoding and User-Agent request headers. Content will never be gzipped if no Accept-Encoding header is present.

This is covered further in the runtime environment documentation (Java | Python | Go).

Does Google App Engine support SSL (HTTPS)?

Google App Engine allows you to serve SSL (HTTPS) traffic through your appspot.com domain. Simply add the 'secure' parameter to your app.yaml handler for the URLs through which you wish to support secure traffic. For complete information on how to configure your application for secure traffic, please see the docs on app configuration (Java | Python | Go).

You can also serve SSL (HTTPS) traffic using a custom domain, if you serve your application through Google Apps. However, SSL is not currently supported on naked domains (see below.)

Note: After April 2013 Google does not issue SSL certificates for double-wildcard domains hosted at appspot.com (i.e. *.*.appspot.com). If you rely on such URLs for HTTPS access to your application, change any application logic to use "-dot-" instead of ".". For example, to access version v1 of application myapp use https://v1-dot-myapp.appspot.com. The certificate will not match if you use https://v1.myapp.appspot.com, and an error occurs for any User-Agent that expects the URL and certificate to match exactly.

Can I Use Strict-Transport-Security Headers in a Custom Domain?

You cannot use Strict-Transport-Security headers unless your domain is whitelisted. To place your domain in the whitelist, contact agl@chromium.org.

Can I use SSL (HTTPS) on App Engine with my Google Apps domain?

You can serve SSL through your custom domain.

Do tools like appcfg use SSL (HTTPS)?

The SDK tools which use login (appcfg, remote_api, appengine_rpc) all use SSL when communicating your email address and password. In addition, appcfg uses SSL when connecting to the Admin Console.

The Python and Go SDKs have the ability to validate the SSL certificate over the remote connection. To do this you must have the ssl Python module installed on your system. If you are using Python 2.5, you can install the module from http://pypi.python.org/pypi/ssl/. If there is an error validating the SSL certificate, the tools will raise an InvalidCertificateException explaining what went wrong.

The Java SDK also enables SSL by default. If an error is encountered while validating the SSL certificate it will throw a javax.net.ssl.SSLHandshakeException.

I'd like to map my app to a naked domain (such as http://example.com).

A "naked domain" lets users access your app directly at the domain name (http://example.com), without requiring a subdomain such as http://www.example.com or http://myapp.example.com. You can set up your App Engine app with a naked domain in the Google Developers Console. Select your project, then choose App Engine > Settings > Custom Domains and follow the instructions.

Naked domains are not supported if you are serving your App Engine app through Google Apps. In that case, you can redirect requests for the naked domain (example.com) to a specific subdomain (such as www.example.com) by following the directions at Options for customizing web addresses. As a consequence, SSL is not currently supported on naked domains.

Static IP Addresses and App Engine apps

App Engine does not currently provide a way to map static IP addresses to an application. In order to optimize the network path between an end user and an App Engine application, end users on different ISPs or geographic locations might use different IP addresses to access the same App Engine application. DNS might return different IP addresses to access App Engine over time or from different network locations.

Outbound services, such as URL Fetch and the Mail API, make use of a large pool of IP addresses. The IP address ranges in this pool are subject to routine changes. In fact, two sequential API calls from the same application may appear to originate from two different IP addresses.

App Engine's current range of outgoing IP addresses are encoded in the sender policy framework (SPF) record of _cloud-netblocks.googleusercontent.com. You may need to recursively perform DNS SPF lookups to resolve the entire list of IP ranges. Start by resolving _cloud-netblocks.googleusercontent.com as follows:

nslookup -q=TXT _cloud-netblocks.googleusercontent.com

The response returned from this will contain all of the current _cloud-netblocks for App Engine. (Keep in mind that these results are not static: Google may introduce new _cloud-netblocksN entries at any time.) For example, this query could return the following:

Non-authoritative answer:
_cloud-netblocks.googleusercontent.com	text = "v=spf1 include:_cloud-netblocks1.googleusercontent.com include:_cloud-netblocks2.googleusercontent.com include:_cloud-netblocks3.googleusercontent.com ?all

From this query response, you would then query each of the returned _cloud-netblocksN listed in the response. Using the previous example response with the three _cloud-netblocksN entries, you would do the following three queries to find all the IP ranges:

nslookup -q=TXT _cloud-netblocks1.googleusercontent.com
nslookup -q=TXT _cloud-netblocks2.googleusercontent.com
nslookup -q=TXT _cloud-netblocks3.googleusercontent.com

The SFP records returned from the query of each of those above entries will be IP ranges that you can use for App Engine outgoing traffic. For example, the query of _cloud-netblocks1 above could return the following:

Non-authoritative answer:
_cloud-netblocks1.googleusercontent.com	text = "v=spf1 ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ?all"

From this example, we see that both the and IP ranges can be used for App Engine traffic.

Note that using static IP address filtering is not considered a safe and effective means of protection. For example, an attacker could set up a malicious App Engine app which could share the same IP address range as your application. Instead, we suggest that you take a defense in depth approach using OAuth and Certs.

How do I define cron jobs for my application?

Please consult the language specific documentation for information on defining cron jobs for your application (Java | Python | Go).

What are task queues?

Task queues provide a mechanism for dynamically adding new requests to be fulfilled at a later point in time. If an app needs to execute some background work, it can use the Task Queue API to organize that work into small, discrete units called Tasks. Tasks are inserted into one or more Queues. App Engine automatically detects new Tasks and executes them when system resources permit. For more details, see the documentation for the Task Queue API (Java | Python | Go).

How do I prevent users/subnets from accessing my app?

App Engine provides a DoS Protection Service that enables you to blacklist IP addresses or subnets. For more details, see the documentation for the DoS Protection Service (Java | Python | Go).