App Engine
App Engine is Google Cloud's original platform-as-a-service, first released in 2008. You upload application code with a configuration file and App Engine runs it, scales it, and manages the underlying infrastructure — no server configuration, no OS management, no container builds.
Standard vs Flexible Environments
The Standard Environment runs code in a Google-managed sandbox with language-specific runtimes (Python, Java, Go, Node.js, PHP, Ruby). Instances start in seconds, scale to zero, and have a generous free tier. The sandbox means a read-only filesystem apart from an in-memory /tmp that counts against instance memory (use Cloud Storage for anything durable), no arbitrary system packages, and no background work you can rely on outside a request under automatic scaling.
The Flexible Environment runs code in Docker containers on Compute Engine VMs that App Engine manages. It supports any language with full OS access. The trade-off: instances take minutes to start, there is always a minimum of one running instance (no true scale-to-zero), and cost is higher.
Services, Versions, and Traffic Splitting
An App Engine application consists of one or more services. Each service maintains multiple named versions that coexist simultaneously. Traffic splits across versions by percentage — rollback means moving 100% back to the previous version, which was never removed.
Scaling Modes and Limits
Standard supports three scaling modes; Flexible supports automatic only. Automatic starts and stops instances based on load and scales to zero — the default for stateless web apps. Basic starts an instance on the first request and stops it after an idle period — cheapest for very low traffic. Manual runs a fixed instance count that never scales — used for daemons, long-running threads, and workloads that cannot tolerate cold starts.
Instance class sets memory and CPU per instance: F1 (384 MB) through F4_1G (3 GB) for automatic scaling, B1 through B8 for basic and manual. Pick the smallest class that handles peak per-instance load.
Request timeout differs by mode. Automatic scaling caps HTTP requests at 10 minutes; basic and manual allow up to 24 hours. If a request needs to outlive that limit, pass the work to Cloud Tasks or a Pub/Sub-triggered function.
App Engine vs Cloud Run for New Projects
For most new workloads, Cloud Run is the better choice. It offers a modern container-based deployment model, equivalent scaling, comparable economics, and no sandbox constraints. App Engine remains the right choice for existing applications running well, for teams with deep App Engine expertise, or when relying on App Engine-specific features like the Task Queue API.
Keep App Engine for existing applications running well, App Engine-specific features, or teams with deep App Engine expertise.
Choose Cloud Run for new projects. It handles the same workloads with a modern deployment model, easier local development, and no sandbox restrictions.
- Choosing Flexible when Standard would work — the always-on minimum instance cost adds up for low-traffic applications.
- Storing session state or uploads in the local filesystem — instances are ephemeral; use Cloud Storage for files and Memorystore for sessions.
- Not setting
max_instancesin app.yaml — a traffic spike can launch far more instances than expected. - Running long background work inside a request handler — Standard cuts off long requests; use Cloud Tasks or a Pub/Sub-triggered function instead.
- Starting a new project on App Engine in 2026 — Cloud Run is the better default for most new workloads.
- For new projects: evaluate Cloud Run first.
- Use Standard for stateless web apps when sandbox constraints are acceptable.
- Externalize all state to Cloud Storage, Memorystore, or Firestore.
- Use traffic splitting for safe gradual deployments.
- Set
max_instancesin app.yaml to limit billing surprises.
Knowledge Check
What restrictions does the App Engine Standard Environment sandbox impose?
- Only outbound network connections are restricted, and only to ports below 1024 on hosts outside Google
- A read-only filesystem apart from an in-memory /tmp, and no arbitrary system packages
- Memory is limited to 512 MB per instance
- Only Python and Java runtimes are supported
Which App Engine environment can truly scale to zero instances?
- Standard Environment
- Flexible Environment
- Both environments scale to zero equally well
- Neither — App Engine always keeps at least one instance running
For most new projects, what is the recommended alternative to App Engine?
- GKE Autopilot
- Compute Engine
- Cloud Run
- App Engine Flexible
What happens to an old App Engine version when a new one is deployed?
- It is automatically deleted to free up resources
- It is archived to Cloud Storage
- It continues to exist and can receive a percentage of traffic at any time
- It is moved to a separate staging environment for validation before any production traffic reaches it
Why does App Engine Flexible cost more than Standard for low-traffic applications?
- Flexible uses more expensive dedicated hardware
- Flexible always keeps at least one instance running — there is no true scale-to-zero
- Flexible requires a dedicated external load balancer for every service that Standard does not provision
- Flexible charges a higher per-request rate than Standard
You got correct