Instance tiers

PandaStack uses a single list of 10 instance tiers for compute sizing. The exact same list — slug, vCPU, RAM, and monthly price — is used for both container apps and databases. Databases additionally carry a disk (GiB) value; container apps ignore the disk column.

Tier table

Tier slug	Label	vCPU	RAM (GB)	DB disk (GiB)	$/mo	Free?
free-tier	Free	0.25	0.5	1	0	yes
standard-tier	Standard	1	2	10	25.55	no
c1-compute-tier	C1-Compute	2	4	20	65.70	no
c1-2xcompute-tier	C1-2XCompute	4	8	40	131.40	no
c2-compute-tier	C2-Compute	6	12	60	138.70	no
c2-2xcompute-tier	C2-2XCompute	8	16	80	277.40	no
m1-memory-tier	M1-Memory	1	4	20	58.40	no
m1-2xmemory-tier	M1-2XMemory	2	8	40	116.80	no
m2-memory-tier	M2-Memory	2	12	40	124.10	no
m2-2xmemory-tier	M2-2XMemory	4	24	80	248.20	no

The DB disk column applies to databases only. This table shows database prices — managed databases carry a premium over container apps with the same specs (backups, PITR, the connection proxy and monitoring ride along). The container-app tier list shares the slugs, vCPU and RAM but bills at lower rates (e.g. Standard container $18.25/mo vs Standard database $25.55/mo); see the pricing page for both tables.

Tier families

The paid tiers fall into three families, each with a base tier and a 2X variant that doubles vCPU, RAM, and disk (and roughly doubles the price):

• Standard — a balanced 1 vCPU / 2 GB tier for general workloads.
• C-series (compute-optimized) — c1 and c2, favoring vCPU. Each has a base and a 2X variant.
• M-series (memory-optimized) — m1 and m2, favoring RAM. Each has a base and a 2X variant.

The -tier suffix matters

Every tier slug carries the -tier suffix, and that suffix is load-bearing:

• The slug must exactly match the Helm value-file name (panda-container-build/helm/<key>.yaml) and the builder allowlist.
• A key missing the suffix silently falls back to free-tier resources — a paid customer would end up running on free-tier compute. Always use the full slug (for example c1-compute-tier, not c1-compute).

For databases, the disk (GiB) value must stay in lockstep with the worker’s tier-resource definition (kubeblocks.TierResources().DiskGi).

Free tier behavior

The free-tier (0.25 vCPU / 0.5 GB / 1 GiB disk, $0/mo) is the only free option and behaves differently from paid tiers:

• Containers on the free tier scale to zero after idle and cold-start on the next request. Paid tiers are always-on.
• Databases on the free tier are single-zone standalone only (1 replica) and are auto-deleted 30 days after creation (suspended at 30 days, purged 14 days later).

Multi-zone / High Availability databases (replicaset, 3 replicas) require a paid tier. See Free-tier lifecycle and Plans & limits.

Choosing a tier

• Container apps pick a tier at create time in the dashboard (or via the API). The tier sets the pod’s CPU/memory request and cost.
• Databases pick the same tier list plus a disk size derived from the tier. See Database tiers & scaling.

Selecting a paid tier requires a paid organization — the paid-status check (isOrgPaid) gates the create path. See how paid status is determined.

Related

• Plans & limits — resource counts and feature gates.
• Usage & metering — how tier cost becomes a bill.
• Container apps
• Database tiers & scaling