Changelog

We're introducing new compute plans for Render services, including memory-optimized plans with higher ratios of RAM to CPU and a new 12-CPU tier for web services, private services, and background workers.

To support the expanded catalog, we're also changing compute plan IDs to a spec-based format that includes the relevant specs. For example a web service compute plan with 4 CPU and 32GB RAM now carries the ID 4c-32g. This convention allows you to more easily intuit the specs of compute plans as we add additional options.

No action is needed to continue using your current compute plan(s). While you will see the IDs for plans change in the Render Dashboard and documentation, you can continue to use old plan IDs with the Render API, SDK, CLI, and Blueprints. To avoid any issues when you start using the new plan IDs, we recommend updating to the latest versions of Render clients and integrations, including the CLI and Terraform provider.

You can see the mapping of old plan names to new plan IDs in the Render Dashboard.

What’s new:

• Increase memory without increasing CPU. At each 2+ CPU tier (2 CPU, 4 CPU, 8 CPU, etc.) we are adding multiple plans with more RAM. For example, at 2 CPU you can now choose between web service plans with 4 GB, 8GB, and 16 GB RAM.
• 12-CPU plans for heavy workloads. For customers running agent platforms or other heavy workloads, we are adding a set of 12-CPU plans with up to 96GB RAM.
• New compute plan IDs. To keep plan IDs intuitive as we add more options, we are replacing legacy IDs (Pro Plus, Pro Ultra, etc) with simple spec-based IDs. For example, the 2 CPU 4 GB web service plan now has an ID of 2c-4g. The Render API, CLI, SDK, and Blueprints will remain backward compatible with legacy plan IDs. No action is required.
• "Compute plan" replaces "instance type" across the dashboard, API, CLI, and docs.

Render service builds now run on nodes with faster CPU and disk. These improvements have reduced the median build time for a Render service by 40%, with this reduction reflected across all runtimes:

Before this rollout (week of July 13), median build time was 38 seconds, consistent with prior weeks. Since July 27 (the first full week post-rollout), the highest observed weekly median is 21 seconds, a conservative 40% reduction. Build times remain in this range.

This global build improvement follows recent single-runtime improvements for Node.js, Python, and Docker.

Render’s managed OpenID Connect (OIDC) authentication now supports Anthropic and OpenAI in addition to AWS.

Render services can authenticate to both providers without storing long-lived API keys. Render instead issues short-lived identity tokens for each service and automatically rotates them as needed.

To configure either provider, connect Render as an identity provider, map the appropriate service account, and add the required environment variables to your Render service. After you redeploy, Render automatically makes the service’s OIDC token available at runtime.

Managed OIDC requires a Pro workspace or higher. Get started in the documentation.

The Render MCP server now supports OAuth-based authentication for Claude Code, Codex, and Cursor:

The MCP server continues to support API key authentication for other applications and non-interactive environments, such as CI/CD.

See setup instructions for each supported tool in the documentation.

The Render MCP server now includes a trigger_deploy tool that enables you (and your agents) to kick off a new deploy of an existing service. This can be helpful for retrying a deploy after a transient failure or forcing a clean rebuild by clearing the build cache.

Get started with the Render MCP server and learn about all of its capabilities in the documentation.

Newly created services now use Bun 1.3.14 by default. You can always specify a different version.

Existing services keep their original default Bun version to prevent breaking changes.

OpenID Connect (OIDC) authentication for AWS is now generally available for Pro workspaces and higher.

Render services can use OIDC to assume an AWS IAM role at runtime, giving them secure access to AWS resources without long-lived credentials. Render automatically issues and rotates the temporary credentials used by each service.

To configure OIDC for AWS, connect Render as an identity provider in AWS IAM, create the appropriate trust relationships, and assign an IAM role to each service using the AWS_ROLE_ARN environment variable.

Get started in the documentation.

Paid Render Postgres databases now support connection pooling using PgBouncer at no additional cost. Enable connection pooling if your database needs to handle more concurrent client connections than its instance type allows:

Render runs PgBouncer on the same underlying host as your database to minimize the latency introduced by the additional hop.

Enable connection pooling from your database's Info page in the Render Dashboard:

You can also enable connection pooling using Blueprints or the Render API.

Enabling connection pooling requires a database restart. After the restart, update your clients to use your database's new connection pool URL (port 6432) instead of its direct connection URL (port 5432).

Learn more in the documentation.

You (and your agents) can now create, update, delete, suspend, and resume Render Postgres and Key Value instances using version 2.21.0 or later of the Render CLI.

Use render kv commands to manage Key Value instances:

Use render pg commands to manage Postgres databases:

Run render kv --help or render pg --help for a list of supported commands, or see the full generated command reference.

With these additions, the Render CLI now provides management capabilities for every Render service type.

Get started with the Render CLI in the docs.