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 capped at 512 MB per instance, whatever instance class you configure for the service
- Only the Python and Java runtimes are supported; every other language has to run in the Flexible Environment
Which App Engine environment can truly scale to zero instances?
- Standard Environment — instances start in seconds and shed capacity to zero when idle
- Flexible Environment — it runs on managed VMs that also scale down to nothing
- Both environments scale down to zero once traffic stops arriving entirely
- Neither — App Engine always keeps at least one instance running
For most new projects, what is the recommended alternative to App Engine?
- GKE Autopilot, for orchestrating many services across a fully managed cluster
- Compute Engine, where you manage the VM and its operating system
- Cloud Run, which takes the same workloads in a container with no sandbox
- App Engine Flexible, which keeps the same platform on managed VMs
What happens to an old App Engine version when a new one is deployed?
- It is deleted automatically once the new version takes all traffic
- It is archived to a Cloud Storage bucket and has to be redeployed to come back
- It continues to exist and can receive a percentage of traffic at any time
- It is moved to a separate staging environment where you validate it before production
Why does App Engine Flexible cost more than Standard for low-traffic applications?
- Flexible runs on more expensive dedicated hardware than the machines sitting behind Standard
- Flexible always keeps at least one instance running and never scales all the way down to zero at any point
- Flexible requires a dedicated external load balancer for every service that Standard does not provision
- Flexible charges a higher per-request rate than Standard does for exactly the same traffic
You got correct