Referencia de app.yaml de App Engine

Opcional. Si usas un tiempo de ejecución que admite buildpacks, puedes definir variables de entorno de compilación en el archivo app.yaml.

Para obtener más información, consulta Usar variables de entorno de compilación.

Opcional. Define un periodo de caché predeterminado global para todos los controladores de archivos estáticos de una aplicación. También puedes configurar una duración de la caché para controladores de archivos estáticos específicos. El valor es una cadena de números y unidades, separados por espacios, donde las unidades pueden ser d para días, h para horas, m para minutos y s para segundos. Por ejemplo, "4d 5h" establece la caducidad de la caché en 4 días y 5 horas después de que se solicite el archivo por primera vez. Si se omite, el servidor de producción establece la caducidad en 10 minutos.

runtime: go111

default_expiration: "4d 5h"

handlers:
  # ...

Para obtener más información, consulta Vencimiento de la caché.

Opcional. Anula el comportamiento de inicio predeterminado ejecutando el comando entrypoint cuando se inicia la aplicación. Para que tu aplicación reciba solicitudes HTTP, el elemento entrypoint debe contener un comando que inicie un servidor web que escuche en el puerto 8080.

Opcional. Puedes definir variables de entorno en el archivo app.yaml para que estén disponibles en tu aplicación. Asegúrate de que la clave de las variables de entorno coincida con la expresión "[a-zA-Z_][a-zA-Z0-9_]*" (empieza por una letra o "_" seguida de cualquier carácter alfanumérico o "_").

Las variables de entorno que tienen el prefijo GAE están reservadas para el uso del sistema y no se permiten en el archivo app.yaml.

env_variables:
  MY_VAR: "my value"

Después, puedes obtener estos valores con os.Getenv:

import "os"
//...
if v := os.Getenv("MY_VAR"); v != "" {
  //...
}

Consulta también la lista de variables de entorno de tiempo de ejecución que no se pueden sobrescribir.

Opcional. Se usa para configurar páginas de error personalizadas que se devuelven para diferentes tipos de error.

Este elemento puede contener los siguientes elementos:

error_code

Opcional. El elemento error_code puede ser uno de los siguientes:

over_quota

Indica que la aplicación ha superado una cuota de recursos

timeout

Se publica si se alcanza una fecha límite antes de que tu aplicación envíe una respuesta.

El código de error es opcional. Si no se especifica, el archivo proporcionado es la respuesta de error predeterminada de tu aplicación.

file

Cada entrada de archivo indica un archivo estático que se debe servir en lugar de la respuesta de error genérica. Si especifica un elemento file sin el elemento error_code correspondiente, el archivo estático será la página de error predeterminada de su aplicación. Los datos de error personalizados deben tener un tamaño inferior a 10 kilobytes.

error_handlers:
  - file: default_error.html

  - error_code: over_quota
    file: over_quota.html

Opcional. Una lista de patrones de URL y descripciones sobre cómo se deben procesar. App Engine puede gestionar URLs ejecutando código de aplicación o sirviendo archivos estáticos subidos con el código, como imágenes, CSS o JavaScript.

Consulta la sintaxis de los controladores y los subelementos.

Opcional. Las aplicaciones deben habilitar esos servicios para poder recibir solicitudes entrantes. Puedes habilitar el servicio en una aplicación Go 1.11 incluyendo una sección inbound_services en el archivo app.yaml.

warmup

Habilita las solicitudes de preparación. Consulta Configurar solicitudes de preparación.

inbound_services:
- warmup

Opcional. La clase de instancia de este servicio.

Están disponibles los siguientes valores en función del escalado de tu servicio:

Escalado automático

F1, F2, F4, F4_1G

Predeterminado: F1

También puedes usar el elemento automatic_scaling para cambiar los ajustes predeterminados del escalado automático, como el número mínimo y máximo de instancias, la latencia y las conexiones simultáneas.

Nota: Si instance_class tiene el valor F2 o superior, puede optimizar sus instancias definiendo max_concurrent_requests con un valor superior al valor predeterminado de 10. Para determinar el valor óptimo, auméntalo gradualmente y monitoriza el rendimiento de tu aplicación.

Escalado básico y manual

B1, B2, B4, B4_1G, B8

Predeterminado: B2

Las clases de instancia básicas y manuales requieren que especifiques el elemento basic_scaling o el elemento manual_scaling.

Opcional. La ruta o el nombre de paquete completo del paquete principal. Este ajuste solo se aplica si tu aplicación usa el modo de módulo Go.

Debes declarar la ruta al paquete principal si tu package main no está en el mismo directorio que tu app.yaml. El elemento main admite rutas de archivo relativas a app.yaml o nombres de paquete completos. Por ejemplo, si tu aplicación tiene esta estructura de directorios:

myapp/
├── app.yaml
├── go.mod
├── cmd
│   └── web
│       └── main.go
└── pkg
    └── users
        └── users.go

En ese caso, debes usar una de estas opciones:

main: ./cmd/web

o

main: example.com/myapp/cmd/web

Obligatorio. Nombre del entorno de ejecución que usa tu aplicación. Por ejemplo, para especificar Go 1.11, usa lo siguiente:

runtime: go111

Obligatorio si se crea un servicio. Opcional para el servicio default. Cada servicio y cada versión deben tener un nombre. El nombre puede contener números, letras y guiones. La longitud combinada de VERSION-dot-SERVICE-dot-PROJECT_ID, donde VERSION es el nombre de tu versión, SERVICE es el nombre de tu servicio y PROJECT_ID es el ID de tu proyecto, no puede superar los 63 caracteres ni empezar o terminar con un guion. Elige un nombre único para cada servicio y cada versión. No reutilices nombres entre servicios y versiones.

service: service-name

Opcional. El elemento service_account te permite especificar una cuenta de servicio gestionada por el usuario como identidad de la versión. La cuenta de servicio especificada se usa al acceder a otros Google Cloud servicios y ejecutar tareas.

service_account: [SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com

Opcional. Configura tu aplicación para que use un conector de acceso a VPC sin servidor, lo que permite que la aplicación envíe solicitudes a recursos internos de tu red de VPC. Para obtener más información, consulta Conectarse a una red VPC.

name

Literal de cadena. Especifica el nombre completo de tu conector de acceso a VPC sin servidor entre comillas:

"projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME"

egress_setting

Opcional. El valor predeterminado es private-ranges-only. El elemento egress_setting puede ser uno de los siguientes:

private-ranges-only

Predeterminado. Las solicitudes a direcciones IP internas se envían a través del conector de Acceso a VPC sin servidor a la red de VPC conectada. Las solicitudes a direcciones IP externas se envían a Internet público.

all-traffic

Todas las solicitudes se envían a través del conector de Acceso a VPC sin servidor a la red de VPC conectada.

vpc_access_connector:
  name: "projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME"
  egress_setting: all-traffic

Opcional. Describe la acción que se lleva a cabo cuando se especifica el elemento login para un controlador y el usuario no ha iniciado sesión. Tiene dos valores posibles:

redirect

Predeterminado. Se redirige al usuario a la página de inicio de sesión de Google o a /_ah/login_required si se usa la autenticación OpenID. Se redirige al usuario a la URL de la aplicación después de iniciar sesión o crear una cuenta.

unauthorized

La solicitud se rechaza con el código de estado HTTP 401 y un mensaje de error.

Si una aplicación necesita un comportamiento diferente, la propia aplicación puede implementar la gestión de los inicios de sesión de los usuarios. Consulta más información sobre la API Users.

En el siguiente ejemplo, se requiere un inicio de sesión para el directorio /profile/ y un inicio de sesión de administrador para el directorio /admin/:

Puedes configurar un controlador para que rechace el acceso a URLs protegidas cuando el usuario no haya iniciado sesión, en lugar de redirigirlo a la página de inicio de sesión, añadiendo auth_fail_action: unauthorized a la configuración del controlador:

Opcional. Puedes definir encabezados HTTP para las respuestas de tus controladores de archivos estáticos o de directorios. Si necesitas definir encabezados HTTP en tus controladores script, debes hacerlo en el código de tu aplicación. Para obtener información sobre qué encabezados de respuesta influyen en el almacenamiento en caché, consulta Almacenamiento en caché de contenido estático.

handlers:
- url: /images
  static_dir: static/images
  http_headers:
    X-Foo-Header: foo
    X-Bar-Header: bar value
    vary: Accept-Encoding
  # ...

Compatibilidad con CORS

Uno de los usos importantes de esta función es admitir el uso compartido de recursos entre dominios (CORS), como acceder a archivos alojados en otra aplicación de App Engine.

Por ejemplo, puedes tener una aplicación de juego mygame.uc.r.appspot.com que acceda a recursos alojados en myassets.uc.r.appspot.com. Sin embargo, si mygame intenta hacer una llamada de JavaScript XMLHttpRequest a myassets, no se completará a menos que el controlador de myassets devuelva un encabezado de respuesta Access-Control-Allow-Origin: que contenga el valor http://mygame.uc.r.appspot.com.

A continuación, se explica cómo hacer que el controlador de archivos estáticos devuelva ese valor de encabezado de respuesta obligatorio:

handlers:
- url: /images
  static_dir: static/images
  http_headers:
    Access-Control-Allow-Origin: https://mygame.uc.r.appspot.com
  # ...

Nota: Si quieres permitir que todos los usuarios accedan a tus recursos, puedes usar el comodín '*' en lugar de https://mygame.uc.r.appspot.com.

Opcional. Determina si el controlador de URLs requiere que el usuario haya iniciado sesión.

Este elemento tiene tres valores posibles:

optional

Predeterminado. No requiere que el usuario haya iniciado sesión.

required

Si el usuario ha iniciado sesión, el controlador continúa con normalidad. De lo contrario, se lleva a cabo la acción indicada en auth_fail_action.

admin

Al igual que con required, realiza auth_fail_action si el usuario no ha iniciado sesión. Además, si el usuario no es administrador de la aplicación, se le mostrará un mensaje de error independientemente del valor de auth_fail_action. En cambio, si el usuario es un administrador, el controlador continúa.

Cuando un controlador de URLs con un ajuste login distinto de optional coincide con una URL, el controlador comprueba primero si el usuario ha iniciado sesión en la aplicación con su opción de autenticación. Si no es así, de forma predeterminada, se redirige al usuario a la página de inicio de sesión. También puedes usar auth_fail_action para configurar la aplicación de forma que rechace las solicitudes de un controlador de los usuarios que no estén autenticados correctamente, en lugar de redirigirlos a la página de inicio de sesión.

Nota: La restricción de inicio de sesión admin también se cumple en las solicitudes internas para las que App Engine define los X-Appengine encabezados especiales adecuados. Por ejemplo, las tareas programadas cron cumplen la restricción admin porque App Engine define un encabezado HTTP X-Appengine-Cron: true en las solicitudes correspondientes. Sin embargo, las solicitudes no cumplirían la restricción de inicio de sesión required, ya que las tareas programadas de cron no se ejecutan como ningún usuario.

Opcional. Si se especifica, todos los archivos que sirva este controlador se servirán con el tipo MIME especificado. Si no se especifica, el tipo MIME de un archivo se derivará de la extensión del nombre de archivo. Si se sube el mismo archivo con varias extensiones, la extensión resultante puede depender del orden en el que se hayan subido los archivos.

Para obtener más información sobre los tipos de medios MIME posibles, consulta el sitio web de tipos de medios MIME de IANA.

Opcional. redirect_http_response_code se usa con el ajuste secure para definir el código de respuesta HTTP que se devuelve al realizar una redirección necesaria según la configuración del ajuste secure. El elemento redirect_http_response_code puede tener los siguientes valores:

301

Código de respuesta

Movido permanentemente.

302

Se ha encontrado el código de respuesta.

303

Consulta el código de respuesta See Other.

307

Código de respuesta de redirección temporal.

handlers:
- url: /youraccount/.*
  script: auto
  secure: always
  redirect_http_response_code: 301

Cuando se redirige la solicitud de un usuario, el código de estado HTTP se asignará al valor del parámetro redirect_http_response_code. Si el parámetro no está presente, se devolverá 302.

Opcional. Especifica que las solicitudes al controlador concreto deben dirigirse a tu aplicación. El único valor aceptado para el elemento script es auto, ya que todo el tráfico se sirve mediante el comando de punto de entrada. Para usar controladores estáticos, al menos uno de tus controladores debe contener la línea script: auto o definir un elemento entrypoint para que la implementación se realice correctamente.

handlers:
- url: /images
  static_dir: static/images

- url: /.*
  secure: always
  redirect_http_response_code: 301
  script: auto

optional

Las solicitudes HTTP y HTTPS con URLs que coincidan con el controlador se completarán sin redirecciones. La aplicación puede examinar la solicitud para determinar qué protocolo se ha usado y responder en consecuencia. Este es el valor predeterminado cuando no se proporciona secure para un controlador.

never

Las solicitudes de una URL que coincida con este controlador y que use HTTPS se redirigen automáticamente a la URL HTTP equivalente. Cuando la solicitud HTTPS de un usuario se redirige para que sea una solicitud HTTP, los parámetros de consulta se eliminan de la solicitud. De esta forma, se evita que un usuario envíe por error datos de consulta a través de una conexión no segura que estaba destinada a una conexión segura.

always

Las solicitudes de una URL que coincida con este controlador y que no use HTTPS se redirigen automáticamente a la URL HTTPS con la misma ruta. Los parámetros de consulta se conservan en la redirección.

handlers:
- url: /youraccount/.*
  script: auto
  secure: always

Para orientar sus anuncios a una versión específica de su aplicación mediante el REGION_ID.r.appspot.com dominio, sustituya los puntos que suelen separar los componentes del subdominio de la URL por la cadena "-dot-". Por ejemplo:
https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com

Para usar dominios personalizados con HTTPS, primero debes activar y configurar certificados SSL para ese dominio.

El inicio y el cierre de sesión de las cuentas de Google siempre se realizan mediante una conexión segura, independientemente de cómo se configuren las URLs de la aplicación.

Opcional. Ruta al directorio que contiene los archivos estáticos, desde el directorio raíz de la aplicación. Todo lo que haya después del final del patrón url coincidente se añade a static_dir para formar la ruta completa al archivo solicitado.

Cada archivo del directorio estático se sirve con el tipo MIME que corresponde a la extensión de su nombre de archivo, a menos que se anule con el ajuste mime_type del directorio. Todos los archivos del directorio indicado se suben como archivos estáticos y ninguno de ellos se puede ejecutar como secuencia de comandos.

handlers:
# All URLs beginning with /stylesheets are treated as paths to
# static files in the stylesheets/ directory.
- url: /stylesheets
  static_dir: stylesheets
  # ...

Opcional. Un controlador de patrones de archivos estáticos asocia un patrón de URL con rutas a archivos estáticos subidos con la aplicación. La expresión regular del patrón de URL puede definir agrupaciones de expresiones regulares que se utilicen en la creación de la ruta del archivo. Puedes usarlo en lugar de static_dir para asignar archivos específicos de una estructura de directorios sin asignar todo el directorio.

handlers:
# All URLs ending in .gif .png or .jpg are treated as paths to
# static files in the static/ directory. The URL pattern is a
# regular expression, with a grouping that is inserted into the
# path to the file.
- url: /(.*\.(gif|png|jpg))$
  static_files: static/\1
  upload: static/.*\.(gif|png|jpg)$
  # ...

Los archivos estáticos no pueden ser los mismos que los archivos de código de la aplicación.

Opcional. Una expresión regular que coincida con las rutas de archivo de todos los archivos a los que hará referencia este controlador. Esto es necesario porque el controlador no puede determinar qué archivos del directorio de tu aplicación corresponden a los patrones url y static_files. Los archivos estáticos se suben y se gestionan por separado de los archivos de la aplicación. En el ejemplo anterior, se podría usar el siguiente patrón upload: archives/(.*)/items/(.*)

Elemento obligatorio en handlers. El patrón de URL, como una expresión regular. La expresión puede contener agrupaciones a las que se puede hacer referencia en la ruta de archivo de la secuencia de comandos con referencias inversas de expresiones regulares. Por ejemplo, /profile/(.*)/(.*) coincidiría con la URL /profile/edit/manager y usaría edit y manager como primer y segundo grupo, respectivamente.

El patrón de URL tiene algunas diferencias de comportamiento cuando se usa con los siguientes elementos:

static_dir

Usa un prefijo de URL. El patrón de expresión regular no debe contener agrupaciones cuando se utilice con el elemento static_dir. Todas las URLs que empiecen por este prefijo se gestionarán con este controlador, usando la parte de la URL que va después del prefijo como parte de la ruta del archivo.

static_files

Un controlador de patrones de archivos estáticos asocia un patrón de URL con rutas a archivos estáticos subidos con la aplicación. La expresión regular del patrón de URL puede definir agrupaciones de expresiones regulares que se usarán en la creación de la ruta del archivo. Puedes usarlo en lugar de static_dir para asignar archivos específicos de una estructura de directorios sin asignar todo el directorio.

Opcional. Solo se aplica a las aplicaciones que usan una clase instance de F1 o superior.

Especifica este elemento para cambiar la configuración predeterminada del escalado automático, como los niveles mínimo y máximo del número de instancias, la latencia y las conexiones simultáneas de un servicio.

Este elemento puede contener los siguientes elementos:

max_instances

Opcional. Especifica un valor entre 0 y 2147483647. Si es cero, se inhabilita el ajuste.

Este parámetro especifica el número máximo de instancias que App Engine puede crear para esta versión del módulo. Esto resulta útil para limitar los costes de un módulo.

min_instances

Opcional. El número mínimo de instancias que App Engine debe crear para esta versión del módulo. Estas instancias sirven tráfico cuando llegan solicitudes y siguen sirviendo tráfico incluso cuando se inician instancias adicionales según sea necesario para gestionar el tráfico.

Especifica un valor entre 0 y 1000. Puede asignar el valor 0 al parámetro para permitir que se escale a 0 instancias y, de este modo, reducir los costes cuando no se sirvan solicitudes. Ten en cuenta que se te cobrará por el número de instancias especificadas, independientemente de si reciben tráfico o no.

max_idle_instances

Opcional. El número máximo de instancias inactivas que App Engine debe mantener para esta versión. Especifica un valor entre 1 y 1000. Si no se especifica ningún valor, se utiliza automatic de forma predeterminada, lo que significa que App Engine gestionará el número de instancias inactivas. Ten en cuenta lo siguiente:

• Un valor máximo alto reduce el número de instancias inactivas de forma más gradual cuando los niveles de carga vuelven a la normalidad después de un pico. De esta forma, tu aplicación mantiene un rendimiento constante durante las fluctuaciones de la carga de solicitudes, pero también aumenta el número de instancias inactivas (y los costes de ejecución correspondientes) durante esos periodos de carga elevada.
• Si el máximo es bajo, los costes de funcionamiento serán menores, pero el rendimiento puede verse afectado si los niveles de carga son volátiles.

Nota: Cuando se vuelve a los niveles normales después de un pico de carga, el número de instancias inactivas puede superar temporalmente el máximo especificado. Sin embargo, no se te cobrarán más instancias que el número máximo que hayas especificado.

min_idle_instances

Opcional: Número de instancias adicionales que se mantendrán en ejecución y listas para servir tráfico para esta versión.

App Engine calcula el número de instancias necesarias para gestionar el tráfico actual de tu aplicación en función de los ajustes de escalado, como target_cpu_utilization y target_throughput_utilization. El ajuste min_idle_instances especifica el número de instancias que se van a ejecutar además del número calculado. Por ejemplo, si App Engine calcula que se necesitan 5 instancias para atender el tráfico y min_idle_instances se define como 2, App Engine ejecutará 7 instancias (5, calculadas en función del tráfico, más 2 adicionales por min_idle_instances).

Ten en cuenta que se te cobrará por el número de instancias especificadas, independientemente de si reciben tráfico o no. Ten en cuenta lo siguiente:

• Un mínimo bajo ayuda a mantener bajos los costes de funcionamiento durante los periodos de inactividad, pero significa que es posible que haya menos instancias disponibles de inmediato para responder a un pico de carga repentino.

• Un mínimo alto te permite preparar la aplicación para picos rápidos en la carga de solicitudes. App Engine mantiene en ejecución el número mínimo de instancias para atender las solicitudes entrantes. Se te cobra por el número de instancias especificadas, independientemente de si gestionan solicitudes o no.

  Si defines un número mínimo de instancias inactivas, la latencia pendiente afectará menos al rendimiento de tu aplicación.

target_cpu_utilization

Opcional. Especifica un valor entre 0,5 y 0,95. El valor predeterminado es 0.6.

Este parámetro especifica el umbral de uso de la CPU en el que se iniciarán nuevas instancias para gestionar el tráfico, lo que te permite encontrar el equilibrio entre el rendimiento y el coste. Los valores más bajos aumentan el rendimiento y el coste, mientras que los valores más altos disminuyen el rendimiento y el coste. Por ejemplo, un valor de 0,7 significa que las nuevas instancias se iniciarán cuando el uso de la CPU alcance el 70 %.

target_throughput_utilization

Opcional. Especifica un valor entre 0,5 y 0,95. El valor predeterminado es 0.6.

Se usa con max_concurrent_requests para especificar cuándo se inicia una nueva instancia debido a solicitudes simultáneas. Cuando el número de solicitudes simultáneas alcanza un valor igual a max_concurrent_requests veces target_throughput_utilization, el programador intenta iniciar una instancia nueva.

max_concurrent_requests

Opcional. Número de solicitudes simultáneas que puede aceptar una instancia de escalado automático antes de que el programador genere una nueva instancia (valor predeterminado: 10; valor máximo: 1000).

Se usa con target_throughput_utilization para especificar cuándo se inicia una nueva instancia debido a solicitudes simultáneas. Cuando el número de solicitudes simultáneas alcanza un valor igual a max_concurrent_requests veces target_throughput_utilization, el programador intenta iniciar una instancia nueva.

Te recomendamos que no definas max_concurrent_requests en un valor inferior a 10 a menos que necesites un solo subproceso. Si el valor es inferior a 10, es probable que se creen más instancias de las que necesitas para una aplicación segura para subprocesos, lo que puede generar costes innecesarios.

Si este ajuste es demasiado alto, es posible que la latencia de la API aumente. Ten en cuenta que el programador puede generar una nueva instancia antes de que se alcance el número máximo real de solicitudes.

max_pending_latency

Tiempo máximo que debe permitir App Engine que espere una solicitud en la cola pendiente antes de iniciar instancias adicionales para gestionar las solicitudes, de forma que se reduzca la latencia pendiente. Cuando se alcanza este umbral, se envía una señal para aumentar la escala, lo que provoca un incremento en el número de instancias. Si no se especifica ningún valor, se utiliza automatic de forma predeterminada. Esto significa que las solicitudes pueden permanecer en la cola pendiente hasta 10 segundos, el límite de tiempo de solicitud pendiente máximo, antes de que se activen los nuevos inicios de instancia.

Un valor máximo bajo significa que App Engine iniciará nuevas instancias antes para las solicitudes pendientes, lo que mejorará el rendimiento, pero aumentará los costes de ejecución.

Si el valor máximo es alto, es posible que los usuarios tengan que esperar más para que se atiendan sus solicitudes (si hay solicitudes pendientes y no hay instancias inactivas para atenderlas), pero el coste de ejecutar la aplicación será menor.

min_pending_latency

Elemento opcional que puedes definir para especificar el tiempo mínimo que debe esperar una solicitud en la cola pendiente antes de iniciar una nueva instancia para gestionarla. Si especifica un valor, puede reducir los costes de ejecución, pero aumentará el tiempo que los usuarios deben esperar para que se atiendan sus solicitudes.

En el caso de las aplicaciones gratuitas, el valor predeterminado es 500ms. En el caso de las aplicaciones de pago, el valor predeterminado es 0.

Este elemento funciona junto con el elemento max_pending_latency para determinar cuándo crea App Engine nuevas instancias. Si hay solicitudes pendientes en la cola:

• Si es inferior al valor min_pending_latency que especifiques, App Engine no creará instancias nuevas.
• Si se supera este límite, App Engine intentará crear una instancia.max_pending_latency
• Entre la hora especificada por min_pending_latency y max_pending_latency, App Engine intentará reutilizar una instancia. Si ninguna instancia puede procesar la solicitud antes de max_pending_latency, App Engine creará una nueva instancia.

automatic_scaling:
  target_cpu_utilization: 0.65
  min_instances: 5
  max_instances: 100
  min_pending_latency: 30ms
  max_pending_latency: automatic
  max_concurrent_requests: 50

Las aplicaciones que usen una clase instance de B1 o una versión posterior deben especificar este elemento o manual_scaling.

Este elemento permite el escalado básico de las clases de instancia B1 y superiores, y puede contener los siguientes elementos:

max_instances

Obligatorio. El número máximo de instancias que App Engine puede crear para esta versión del servicio. Esto resulta útil para limitar los costes de un servicio.

idle_timeout

Opcional. La instancia se cerrará al cabo de este tiempo después de recibir su última solicitud. El valor predeterminado es 5 minutos (5m).

basic_scaling:
  max_instances: 11
  idle_timeout: 10m

Las aplicaciones que usen una clase instance de B1 o una versión posterior deben especificar este elemento o basic_scaling.

Este elemento permite escalar manualmente las clases de instancia B1 y superiores, y puede contener el siguiente elemento:

instances

Número de instancias que se asignarán al servicio al inicio.

manual_scaling:
  instances: 5