How Requests are Routed

This page describes how HTTP requests from users reach the appropriate version of a service. Requests can be routed two ways:

  • App Engine's default address routing rules apply to requests with a URL that ends at the domain level.
  • Alternatively, you can use a dispatch file that routes specific URL patterns according to your own rules.

These options apply only to deployed applications. When you are testing locally, the routing behavior depends on the particular runtime and development environment that you're using.

Requests and domains

App Engine determines that an incoming request is intended for your application using the domain name of the request. A request whose domain name is is routed to the application whose ID is your_app_id. Every application gets an domain name for free.

The domains also support subdomains of the form, where subdomain can be any string allowed in one part of a domain name (not .). Requests sent to any subdomain in this way are routed to your application.

You can set up a custom top-level domain using Google Apps. With Google Apps, you assign subdomains of your business's domain to various applications, such as Google Mail or Sites. You can also associate an App Engine application with a subdomain. For convenience, you can set up a Google Apps domain when you register your application ID, or later from the Cloud Platform Console. For more information, see Using Custom Domains and SSL.

Requests for these URLs all go to the version of your application that you have selected as the default version in the Cloud Platform Console. Each version of your application also has its own URL, so you can deploy and test a new version before making it the default version. The version-specific URL uses the version identifier from your app's configuration file in addition to the domain name, in this pattern: You can also use subdomains with the version-specific URL:

The domain name used for the request is included in the request data passed to the application. If you want your app to respond differently depending on the domain name used to access it (such as to redirect to an official domain), you can check the request data, such as the Host request header, for the domain from within the application code and respond accordingly.

Routing via URL

You can target an HTTP request with varying degrees of specificity. In the following examples, can be replaced with your app's custom domain if you have one. The URL substrings "version", "service", and "app-id" represent application and service attributes that you have defined.

These two address forms are guaranteed to reach their target (if it exists). They will never be intercepted and rerouted by a pattern in the dispatch file:

Sends the request to an available instance of the named service and version.

These address forms have a default routing behavior. Note that the default routing is overridden if there is a matching pattern in the dispatch file:

Sends the request to an available instance of the default version of the named service.
Sends the request to an available instance of the given version of the default service.
Sends the request to an available instance of the default version of the default service.

Default service

The default service is defined by explicitly giving a service the name "default," or by not including the name parameter in the service's config file. Requests that specify no service or an invalid service are routed to the default service. You can designate a default version for a service, when appropriate, in the Google Cloud Platform Console versions tab.

Soft routing

If a request matches the app-id.appspot portion of the hostname, but includes a service or version that does not exist, then the request is routed to the default version of the default service. Soft routing does not apply to custom domains; requests to them will return a 404 if the hostname is invalid.

Routing with a dispatch file

For certain URLs (described above), you can create a dispatch file that overrides the routing rules. This lets you send incoming requests to a specific service based on the path or hostname in the URL. For example, say that you want to route mobile requests like to a mobile frontend, route worker requests like to a static backend, and serve all static content from the default service.

To do this you can create a custom routing with a dispatch.yaml file. The file can be placed in your project directory at the top level, or in the directory that defines the default service.

  # Default service serves the typical web resources and all static resources.
  - url: "*/favicon.ico"
    service: default

  # Default service serves simple hostname request.
  - url: ""
    service: default

  # Send all mobile traffic to the mobile frontend.
  - url: "*/mobile/*"
    service: mobile-frontend

  # Send all work to the one static backend.
  - url: "*/work/*"
    service: static-backend

The dispatch file can contain up to 20 routing rules. When specifying the URL string, neither the hostname nor the path can be longer than 100 characters.

As you can see, dispatch.yaml includes support for glob characters; however, YAML syntax requires that you include such expressions in quotes to denote they are strings. Glob characters can be used only before the hostname and at the end of the path. If you prefer general routing rules that match many possible requests, you could specify the following:

# Send any path that begins with “” to the mobile-frontend service.
- url: "*"
  service: mobile-frontend

# Send any domain/sub-domain with a path that starts with “work” to the static backend service.
- url: "*/work*"
  service: static-backend

You can also write expressions that are more strict:

# Matches the path "/fun", but not "/fun2" or "/fun/other"
- url: "*/fun"
  service: mobile-frontend

# Matches the hostname '', but not '
- url: "*"
  service: static-backend

Send feedback about...

App Engine flexible environment for Node.js docs