GKE Autopilot vs Standard: Which Mode Should Your Cluster Use

Once you decide to run a backend on Google Kubernetes Engine, the next question is the mode. Autopilot hands node management to Google and bills you for what your Pods request. Standard gives you node pools to size and tune, and bills you for the VMs. The choice changes your bill, what workloads you are allowed to run, and how much of the cluster you have to look after.

This guide compares the two modes for a typical backend with several services and a database, and shows how Encore deploys the same code to either one without hand-written manifests.

Autopilot vs Standard at a glance

Each option is covered below, starting with Encore.

Deploying services to GKE Autopilot or Standard with Encore

Encore combines an open source infrastructure SDK for TypeScript and Go with a platform that provisions and deploys into your own AWS or GCP account. In a GCP environment you can choose GKE Autopilot or a Standard cluster with managed node pools, with nodes in private subnets. Each service becomes a Kubernetes Deployment with its own service account, and Encore creates the Service and Ingress resources that connect it to Google Cloud Load Balancing with managed TLS certificates.

What you write is the service:

// reports/reports.ts
import { api } from "encore.dev/api";
import { CronJob } from "encore.dev/cron";
import { SQLDatabase } from "encore.dev/storage/sqldb";

// Cloud SQL for PostgreSQL on GCP, a local Postgres under encore run.
const db = new SQLDatabase("reports", { migrations: "./migrations" });

export const daily = api(
  { expose: true, method: "GET", path: "/reports/daily" },
  async (): Promise<{ day: string; signups: number }> => {
    const row = await db.queryRow<{ day: string; signups: number }>`
      SELECT day::text, signups FROM daily_stats ORDER BY day DESC LIMIT 1`;
    return row ?? { day: "", signups: 0 };
  },
);

// Recomputes yesterday's numbers. Safe to run twice because of the upsert.
export const rollup = api({}, async (): Promise<void> => {
  await db.exec`
    INSERT INTO daily_stats (day, signups)
    SELECT current_date - 1, count(*) FROM signups
    WHERE created_at >= current_date - 1 AND created_at < current_date
    ON CONFLICT (day) DO UPDATE SET signups = EXCLUDED.signups`;
});

const _ = new CronJob("daily-rollup", {
  title: "Roll up yesterday's signups",
  schedule: "0 2 * * *",
  endpoint: rollup,
});

The migration in reports/migrations creates the signups and daily_stats tables the queries use:

-- reports/migrations/1_create_tables.up.sql
CREATE TABLE signups (
    id BIGSERIAL PRIMARY KEY,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE daily_stats (
    day DATE PRIMARY KEY,
    signups INTEGER NOT NULL
);

On deploy, this becomes a Deployment on the cluster mode you picked, a database on the environment's Cloud SQL instance, and a cron schedule that calls rollup every night. encore run starts Postgres locally so the endpoints and migrations can be tested there. Cron jobs do not run locally, but rollup is a normal endpoint you can call by hand while developing.

The cluster mode is an environment setting, so a team can keep staging on Autopilot and run production on Standard with tuned node pools, or the other way around, with no change to the service code.

GKE Autopilot: pay for Pods, not nodes

In Autopilot, Google provisions and manages nodes based on your workloads. General-purpose Pods are billed per second for the CPU, memory and ephemeral storage they request, per GKE pricing, with no charge for unused node capacity or system Pods. Workloads that select specific hardware, such as GPUs, switch to node-based billing with an Autopilot premium.

Autopilot trades away control: it enforces security defaults that block privileged containers and most host access, adjusts resource requests that fall below its minimums, and limits which DaemonSets and node settings you can use. Most application backends never hit those rules, though security agents, custom CNI plugins and some observability tools do.

GKE Standard: node pools you own

In Standard mode, you create node pools, choose machine types and configure autoscaling. You pay for the Compute Engine VMs per second with a one-minute minimum, whether your Pods fill them or not, and committed use discounts apply to those VMs.

That suits large steady workloads that pack nodes well, and anything needing privileged access or specific kernel settings. It also means you handle bin packing, node pool upgrades and capacity planning, or you pay for headroom you do not use.

Good to know

The mode is fixed when the cluster is created, so switching means a new cluster and moving workloads. Standard clusters can also run individual workloads on Autopilot through compute classes, which narrows the gap for mixed clusters.

How to choose

Pick Encore when you want to run on GKE in your own GCP project, with Cloud SQL, Pub/Sub, secrets and cron created from the same code as the services.

Pick Autopilot for most application backends, especially small or uneven ones, where paying for Pod requests and not managing nodes outweighs the restrictions. Pick Standard when you need privileged workloads, specific machine types, or large steady workloads where packing your own nodes is cheaper.

Related guides

• Do you need Kubernetes?
• Kubernetes cost
• How to deploy to GCP in 2026
• Google Cloud pricing