Google App Engine

by [Google Cloud]

Google Cloud’s managed PaaS for building and running web applications and services (Google’s description).

See https://cloud.google.com/appengine

Google now steers new users to Cloud Run

Google’s environments page recommends Cloud Run for new users as “the preferred alternative over App Engine”, citing lower prices and access to capabilities such as GPUs, and suggests evaluating it for new or modernised projects. No App Engine deprecation notice appears in the docs (checked 2026-10-05); both environments remain supported with automatic security patches.

Summary

Google App Engine (GAE) is a fully managed PaaS on Google Cloud that lets you deploy web applications without managing servers. It provides two environments — Standard and Flexible — enabling everything from fast, opinionated runtimes for common languages to custom Docker-based environments for full control. App Engine manages scaling, health checks, logging, and many integrations with other Google Cloud services, (opinion: suited to web backends, mobile APIs and microservices that need quick deployment and automatic scaling).

Features

  • Two environments: Standard (preconfigured runtimes, sandboxed) and Flexible (custom runtimes via Docker, runs on Compute Engine VMs).
  • Service / Version / Instance model: multiple services (microservices), multiple versions per service, traffic splitting between versions.
  • Auto-scaling, basic-scaling, and manual-scaling options to match workload patterns.
  • app.yaml (and service-level YAMLs) for per-service configuration: runtime, handlers, instance_class, env_variables, health checks.
  • Built-in scheduled tasks (cron), background work (task queues / Cloud Tasks), and cron.yaml/dispatch.yaml for routing.
  • Integration with Cloud SQL, Firestore, Memorystore, Cloud Storage, Pub/Sub, and Cloud IAM.
  • Managed SSL for custom domains, custom domain mapping, and automatic certificate renewal.
  • Built-in logging and monitoring via Cloud Logging and Cloud Monitoring (formerly Stackdriver).
  • Traffic splitting and gradual rollout / canary deployments with percentage-based routing.
  • Local development SDK emulator and deployment tooling (gcloud app deploy).

Claimed strengths (vendor positioning; opinion)

  • Deployment without managing servers: App Engine handles instance provisioning, health and scaling.
  • Release control: multiple versions can run concurrently with traffic splitting.
  • Standard environment scales to zero (see table below); free-tier quotas exist (not re-verified).
  • Integrations with Cloud SQL, Firestore, Pub/Sub and IAM.
  • Standard for managed runtimes; Flexible for custom binaries or long-running processes.

Pricing (high-level)

  • Pay-as-you-go model: charges based on resources consumed (instance hours, CPU/memory in Flexible, outgoing network, storage, and API usage).
  • Standard environment: includes a free quota (daily free instance-hours, bandwidth, API calls). Beyond free quotas, billing depends on instance class and usage (details: pricing page).
  • Flexible environment: billed for underlying Compute Engine VM resources (vCPU, memory, persistent disk) and networking.
  • Many integrations (Cloud SQL, Memorystore, etc.) are billed separately under their respective services.
  • For up-to-date pricing and free-tier details, consult: https://cloud.google.com/appengine/pricing

Practical usage examples

  • Mobile backend API: deploy a Node.js/Go/Python API to App Engine Standard with autoscaling, backed by Cloud Firestore.
  • Microservices: split a larger app into services (auth-service, api-service, web-frontend). Deploy versions independently and use traffic splitting for progressive rollouts.
  • Canary/Blue-Green deploys: deploy new version alongside stable version and shift 10% of traffic to the new one to validate behavior before full cutover.
  • Scheduled batch jobs: use cron configuration to trigger app handlers for nightly reports or cleanup tasks; use Cloud Tasks for background processing.
  • Legacy or custom binaries: use Flexible environment with a custom Dockerfile when you need native dependencies, longer request timeouts, or SSH access for debugging.

Example app.yaml (minimal)

runtime: <supported-runtime-id>   # pick a current runtime from the docs  
service: api  
instance_class: F2  
env_variables:  
  ENV: production  
handlers:  
- url: /static  
  static_dir: static  
- url: /.*  
  script: auto  

Notes:

  • The exact instance classes, runtime names, and YAML fields evolve; always check the runtime docs for the language you use.
  • Some classic files from older App Engine usage (cron.yaml, queue.yaml) may be replaced by Cloud Scheduler and Cloud Tasks (carried over from the draft, not verified).

Standard vs Flexible (Google docs, 2026-10-05)

StandardFlexible
Startupsecondsminutes
Scale to zeroyesno (minimum one instance)
Max request timeoutruntime-dependent60 minutes
SSH, background processes, WebSocketsnoyes

AI features

None found in the App Engine documentation as of 2026-10-05.

When to choose App Engine

  • Opinion: Standard fits low-operations HTTP workloads with bursty traffic.
  • Opinion: Flexible fits apps that require native extensions, custom OS libraries, long-lived connections, or fine-grained VM control.

Related: Cloud Run, Cloud Functions, Cloud SQL, Cloud CDN.

Sources

Fetched 2026-10-05.

Open items

  • Current list of supported runtimes and instance classes not retrieved (the sample app.yaml uses a placeholder).
  • Statements on cron/task-queue replacement by Cloud Scheduler and Cloud Tasks are carried over from the draft.