Render Renamed Every Compute Plan to 2c-4g Style IDs: An IaC Compatibility Checklist Before You Touch Anything

On August 26, 2026, Render renamed every compute plan it sells. pro became 2c-4g. pro_plus became 4c-8g. pro_ultra — the 8-CPU, 32 GB workhorse — became 8c-32g. The official line, printed in bold in the changelog entry, is "No action is required": the API, CLI, SDK, and Blueprints all keep accepting the legacy IDs.

That promise is almost certainly true for your running services. It is not the same promise as "nothing in your infrastructure-as-code needs attention." Between the Terraform provider that validates plan names against a hardcoded list, the three different spellings of the same plan across Render's own surfaces, and one quiet case where a legacy ID now buys you different specs than it used to, there is a real compatibility checklist hiding behind "no action required." This post is that checklist: what changed, where it can bite IaC-managed fleets, and the six steps that prove your setup is clean — whether you are staying on Render, planning an exit, or running both side by side.

What Render changed on August 26 (and what it promised)​

Two things shipped together. First, the catalog grew: memory-optimized plans at each 2+ CPU tier (2 CPU can now pair with 4, 8, or 16 GB instead of only 4 GB) and a new 12-CPU tier reaching 12c-96g for heavy workloads — Render's changelog names agent platforms explicitly. If you want the cost angle on the new memory tiers, our companion analysis works the repricing line by line; this post is about the identifiers, not the invoice.

Second, every existing plan got a spec-based ID. The mapping for web, private, worker, and cron services is:

(Per-service-type tables differ slightly at the top end — check the compute plans doc for your service type rather than assuming the web-service table. Postgres and Key Value have their own plan families, so don't blanket-replace across database configs.)

The compatibility promise has two halves. The reassuring half: legacy IDs keep working everywhere — API, CLI, SDK, Blueprints. The half that creates work: Render "recommends updating to the latest versions of Render clients and integrations, including the CLI and Terraform provider," and it renamed the concept itself — "compute plan" replaces "instance type" across the dashboard, API, CLI, and docs. A rename with a compatibility shim is still a rename, and every shim has edges. The next two sections map the edges before the checklist tells you what to do about them.

One plan, three spellings: why your inventory must grep all of them​

Here is the detail that turns a casual find-and-replace into a bug factory: Render's surfaces never agreed on one spelling of the legacy names, and now there are three spellings of every plan in the wild.

• The API, SDK, and Terraform provider use the underscore form: pro_plus, pro_max, pro_ultra.
• Blueprints (render.yaml) document the space form: plan: pro plus, plan: pro max, plan: pro ultra.
• Everything new uses the spec form: 4c-8g, 4c-16g, 8c-32g.

So a fleet managed half in Terraform and half in Blueprints can contain pro_plus and pro plus referring to the identical 4-CPU/8-GB plan, and a naive sed 's/pro_plus/4c-8g/' fixes one file while leaving the other untouched — worse, a regex written for the underscore form silently matches nothing in render.yaml, reporting success while changing zero lines. Any inventory that only searches one spelling undercounts by construction.

Start with a search that covers all three forms across every IaC surface at once:

rg -n --no-heading -i 'pro[ _]?(plus|max|ultra)|standard|starter|instance[_-]?type|[0-9.]+c-[0-9]+' \
  --glob '*.tf' --glob '*.yaml' --glob '*.yml' --glob '*.sh' --glob '*.py' --glob '*.ts' .

That one command answers the only question that matters at this stage: where do plan identifiers live in my setup? Expect hits in Terraform resources (plan = "starter" in render_web_service blocks), Blueprint files (plan: standard), deploy scripts that call the API, and — the one teams forget — CI jobs that assert on plan names in render CLI output. Write the list down; the checklist below consumes it. (Skim past prose matches for everyday words like "standard" — the --glob flags already confine the search to IaC-shaped files.)

Where "no action required" quietly isn't true​

The changelog's bold promise covers the steady state: existing services keep running, and old IDs keep being accepted. Four cases fall outside that steady state, and each has a concrete detection command.

1. Workflow tasks on starter/standard were silently remapped to flex. This is the one genuine behavior change. Render Workflows discontinued the starter and standard task plans in favor of a new flex plan (up to 1 CPU, up to 4 GB, billed on actual usage), and any task still declaring starter or standard now automatically runs on flex instead. Same declaration, different specs, different billing model — that is not a rename, it is a migration performed on your behalf. If you run Render Workflows, find every task plan declaration first:

rg -n --no-heading 'plan\s*[:=]\s*\S*(starter|standard|flex)' --glob '*.ts' --glob '*.py' .

2. Old client versions may reject the new IDs. Render's "update to the latest" recommendation exists because clients validate. The Terraform provider's docs enumerate the legacy plan values, and any version predating the rename cannot know that 2c-8g is a legal plan — feed it a new ID and the failure mode is a validation error at plan time, not a graceful API call. The same applies to pinned CLI versions in CI images and vendored SDK copies. Detection is version archaeology:

terraform version
render --version
rg -n -A3 'render-oss/render' --glob '*.tf' .

3. Normalization causes diff noise after upgrades. Once clients learn both spellings, the next question is which spelling they write back. If your config says pro and the upgraded provider (or the API itself) normalizes state to 2c-4g, terraform plan can report a perpetual diff on a service whose specs never changed — or, depending on provider behavior, silently rewrite state on the next apply. This is cosmetic until it trains your team to ignore plan output, at which point it is a process problem. You detect it by running terraform plan immediately after each client upgrade, before changing a single ID, and reading the diff instead of assuming it is empty.

4. "Instance type" is gone as a concept. Dashboards, CLI output, API docs, and error strings now say "compute plan." Anything that parses those strings — a deploy script grepping render services output, a cost report keying off an API field name, a Datadog monitor matching an error message — can break without any plan ID appearing in the diff. The inventory grep in the previous section already includes instance[_-]?type for exactly this reason; treat every hit as guilty until proven decorative.

None of these contradicts the changelog. "The old IDs still work" and "upgrading your toolchain around the rename needs a test plan" are both true, and confusing the first for the second is how teams end up debugging a Monday-morning deploy failure against a weeks-old changelog entry.

The compatibility checklist (do this in order)​

Here it is: six steps, each with a pass criterion. Run them in staging (or a preview environment) before production, and run them whether you plan to adopt the new IDs or keep the legacy ones forever — steps 1–3 validate the world as it is, steps 4–6 only apply if you migrate.

Step 1 — Inventory every plan reference. Run the multi-spelling grep from above across the whole repo, including CI configs and scripts directories. Pass criterion: a written list of every file containing a plan ID or the phrase "instance type," tagged by surface (Terraform / Blueprint / script / assertion).

Step 2 — Pin, then upgrade clients one at a time. Record current versions of the Terraform provider, Render CLI, and any SDK, then upgrade exactly one client. Pass criterion: you can name the before/after version of the single client you changed; nothing else moved.

Step 3 — Assert an unchanged service after each upgrade. With zero config edits, run terraform plan (expect: empty, or a normalization-only diff you can explain line by line), redeploy one Blueprint preview environment (expect: same specs in the dashboard; only the displayed ID spelling may change), and re-run any script that parses CLI/API output (expect: identical behavior). Pass criterion: specs, cost, and automation behavior are byte-for-byte what they were before the upgrade — the API records a plan change but only applies it on the next successful deploy, so confirm applied state, not just recorded state.

Step 4 — Adopt the new IDs deliberately, if at all. There is no deadline, so treat this as a normal refactor: one service type at a time, legacy and spec IDs never mixed in the same file, memory-optimized tiers (2c-8g vs 2c-4g) chosen on measured memory headroom rather than vibes. Pass criterion: each changed service shows the same-or-intended specs in the dashboard after deploy, and the monthly estimate moves only where you intended it to.

Step 5 — Re-run the inventory to prove zero legacy strings. Same grep as step 1. Pass criterion: zero hits for legacy spellings in active configs (docs and comments referencing the old names get updated or explicitly marked historical).

Step 6 — Record the mapping for exit or coexistence. Whether your end state is "all Render," "all self-hosted," or "Render for previews, own fleet for production," write the Rosetta Stone now while both spellings are fresh: Render plan → CPU/RAM → your own tier name. Pass criterion: a table (a README section is fine) that lets a future migration map 4c-8g to the equivalent row in your own catalog without re-deriving specs from a changelog.

The design lesson for your own platform API​

Render handled the substance well — spec-based IDs really are more legible than marketing tiers, and the compatibility shim gives everyone breathing room. The friction all comes from one design choice made years ago: the display name was the identifier, in three mutually inconsistent spellings, validated by clients that each embedded their own copy of the vocabulary. A stable machine ID (plan_01H...) with Pro Plus as a purely cosmetic label would have made this a dashboard copy change instead of a four-surface migration with a Terraform-provider advisory attached.

If you run a platform API — or plan to — the rule is one sentence: identifiers are forever, names are marketing, and no client should ever validate against a hardcoded list of either. Version the catalog behind the API, let clients discover plans instead of enumerating them, and when you must rename, ship the alias table as data, not as a paragraph in a changelog.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.