Google App Engine

Google’s original platform as a service: describe your app in an app.yaml, run one deploy command, and Google runs and scales the instances.

What it is: Platform as a service (PaaS)
Type: Managed service on Google Cloud
Made by: Google Cloud
License: Proprietary
Facts checked: 12 October 2026

What it is

An App Engine app belongs to one Google Cloud project and holds one or more services. Each gcloud app deploy creates a new version of a service, and each version runs on as many instances as its traffic needs. You can move all traffic to a version, split traffic between versions, or reach any version directly at its own URL, which makes rollbacks and canary tests a routing change rather than a redeploy.

There are two environments. The standard environment runs your code in a sandbox on a Google-maintained runtime for Go, Java, Node.js, PHP, Python or Ruby. Instances start in seconds, a service can scale to zero, and you pay per instance hour after a daily free allowance. The flexible environment runs your app as a Docker container on Compute Engine VMs: any language, background processes, WebSockets and SSH, but instances take minutes to start, at least one is always running, and you pay for vCPU, memory and disk.

Google now steers new work elsewhere. Its documentation calls Cloud Run “a newer and better alternative to App Engine” and recommends Cloud Run to new Google Cloud users. Cloud Run runs on much of the same infrastructure as the standard environment, and Google publishes a guide for migrating to it.

Why teams pick it

The standard environment scales to zero and has a daily free tier: 28 instance hours of the F classes and 9 of the B classes, then $0.05 an hour for the smallest class
Versions and traffic splitting are built in, so you can deploy with --no-promote, test the version at its own URL, then shift traffic
Deploys and instance starts take seconds in the standard environment, and Google patches the runtime in place
Services in one app act like microservices that share the project’s other Google Cloud resources

Watch out for

Google recommends Cloud Run instead for new projects, and each standard runtime has end-of-support, deprecation and decommission dates you must upgrade around
The standard sandbox only lets you write to /tmp and has no background processes, WebSockets or SSH; automatically scaled requests time out after 10 minutes
The flexible environment never scales below one instance, takes minutes to start and deploy, has no free tier, and its VMs may be restarted weekly for patching
Projects created after March 2025 cap standard services at 20 instances by default unless you raise max_instances

Alternatives

What all platform as a service (paas) have in common →

AWS Elastic BeanstalkAWSUpload your code and Elastic Beanstalk builds the AWS setup to run it (EC2 instances, a load balancer, an Auto Scaling group) in your own account, where you can still see and change every piece.

Azure App ServiceAzureAzure’s platform for web apps and APIs: you rent a pool of VMs called an App Service plan, and every app you put in it runs on those VMs without you managing them.

Cloud FoundryOpen sourceAn open-source PaaS you run yourself: `cf push` uploads your code, a buildpack stages it into a droplet, and Diego keeps the requested number of instances running behind the Gorouter.

DokkuOpen sourceA Heroku-like PaaS on one server of your own: `git push` to it, and Dokku builds the app with buildpacks or a Dockerfile and runs it in Docker containers behind nginx.

Fly.ioCommercialFly.io turns your Docker image into fast-booting Firecracker microVMs on its own servers in regions around the world, and routes each user to the nearest one.

HerokuCommercialThe platform that defined PaaS: `git push` your code, and Heroku builds it with a buildpack and runs it on managed containers called dynos behind its own HTTP router.

RenderCommercialRender builds and deploys web services, background workers, cron jobs and managed Postgres and Key Value stores from your Git repo, all described in one `render.yaml` file if you like.

How it fits with other technologies

What Google App Engine uses

app.yaml for a Python service in the standard environment · yaml

# Deploy a new version without sending it traffic:
#   gcloud app deploy --version v2 --no-promote
runtime: python314
instance_class: F2
automatic_scaling:
  min_instances: 0
  max_instances: 20
  target_cpu_utilization: 0.65
handlers:
  - url: /static
    static_dir: static
  - url: /.*
    script: auto
    secure: always

See it in a real stack

No architecture uses Google App Engine yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2008–2025

In 2008 putting a web app online meant renting servers and setting up load balancing, scaling and a database yourself. On April 7, 2008, at an event called Campfire One, Google launched a preview of App Engine, which let developers run web apps on Google’s own infrastructure. Product manager Paul McDonald described the goal as making it easy to start a new web app and then easy to scale it to millions of users. The preview offered automatic scaling and load balancing, a datastore built on Bigtable and GFS, and Google APIs for sign-in and email, for the first 10,000 developers who signed up.

The first version was strict. Apps had to be written in Python, could not write to the filesystem, could only run in response to a web request, and had to respond within a few seconds. Those rules let Google spread requests over many servers and start and stop them freely. App Engine left preview on November 7, 2011, three and a half years after Campfire One, with more than 300,000 active apps and a 99.95% SLA for paid apps on its High Replication Datastore.

Many apps needed more than the sandbox allowed, so Google added a second environment that runs Docker containers on Compute Engine VMs; it reached general availability in March 2017 with the pitch “Any language. Any framework. Any library.” In April 2019 Google announced Cloud Run, which runs any container and scales to zero. Google now describes Cloud Run as building on more than a decade of running App Engine and recommends it to new users.

Why it’s built this way

A sandbox instead of a server: Limiting what an app could do (no local writes, no subprocesses, short requests) let App Engine route any request to any server and start or stop servers to match traffic, without the app noticing.
Free to start: The 2008 preview gave every app 500 MB of storage, 200 million megacycles of CPU a day and 10 GB of bandwidth a day, which Google estimated at about 5 million page views a month, and promised those quotas would stay free. The team summed up its philosophy as “easy to use, easy to scale, and free to get started.”
A second, container-based environment: The flexible environment accepted any Docker image, so developers could bring languages the standard runtimes lacked, and the same container could also run on Google Container Engine, Compute Engine or their own servers.

Timeline

2008
Preview launches at Campfire One: Python only, for the first 10,000 developers
2011
Leaves preview with release 1.6.0 and a 99.95% SLA for paid apps
2017
Flexible environment, running Docker containers on Compute Engine VMs, becomes generally available
2019
Google announces Cloud Run and second-generation App Engine runtimes
2025
New projects get a default limit of 20 instances per standard service

Sources10 · facts checked 12 October 2026

Improve this page on GitHub