What changed
On August 26–27, 2026, Render expanded its service compute catalog with more than 15 new CPU/RAM combinations. At every tier with two or more CPUs, customers can choose higher-memory options independently of CPU count; for example, four CPUs can now be paired with 8GB, 16GB or 32GB of RAM. Render also added 12-CPU web-service, private-service and background-worker plans with 24GB, 48GB or 96GB of RAM. At the same time it replaced descriptive plan names with spec-based IDs such as `4c-32g`, while keeping legacy IDs backward compatible across the API, CLI, SDK, Blueprints and Terraform integrations.
Why it matters
Memory-heavy application economics do not always scale with CPU. Agent harnesses can hold long-lived session state, retrieval systems keep indexes or embeddings resident, and databases or workers may need large heaps without saturating processors. Previously, getting more memory could force teams into a higher CPU tier they did not need. Render’s new catalog makes RAM a more independent cost/sizing decision and raises the ceiling for stateful application workloads without requiring a move to another hosting model.
RAM can now scale independently at the same CPU tier
Render’s expanded catalog adds multiple memory ratios at 2, 4 and 8 CPUs, including 2c-8g, 2c-16g, 4c-32g, 8c-16g and 8c-64g options for supported service types. That lets teams tune for memory pressure without automatically stepping up processor count.
The top long-running service tier reaches 12 CPUs and 96GB
Web services, private services and background workers can use new 12-CPU plans with 24GB, 48GB or 96GB RAM. Render explicitly cites agent platforms and other memory-intensive workloads as a motivation. Cron jobs also receive additional memory-heavy combinations, although their plan matrix differs from continuously running services.
Existing deployments do not need a naming migration
Render renamed 'instance types' to 'compute plans' and introduced spec-based IDs. Existing legacy identifiers such as `standard`, `pro` and `pro_ultra` remain valid in tooling and map to identical existing specifications and prices. Teams can adopt the new IDs gradually; the entirely new memory configurations have only the new spec-based identifiers.
The economic benefit depends on the new-plan prices
Render says existing plans keep their prices unchanged. The significance of the new choices is that a workload can select a different resource ratio rather than overprovisioning CPU solely for RAM. Builders should compare the new plan’s actual monthly rate with their current tier and with horizontal scaling; more memory on one instance may reduce CPU waste but can also increase failure concentration.