Changelog

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.

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.

Paid Render Key Value instances now support three different disk persistence modes:

• Journal + Snapshot: Append writes to a journal and periodically save full snapshots.
  • This matches the behavior of all paid Key Value instances before this release.
• Snapshot only: Disable journaling while continuing to save periodic snapshots.
• Off: Disable all disk-backed persistence.

Reducing persistence can improve write performance for loss-tolerant use cases, such as a shared cache.

You specify your instance's persistence mode on creation:

You can change your instance's persistence mode in the Render Dashboard or using the Render API. Note the following:

• Changing your persistence mode requires a restart, during which your Key Value instance is unavailable for a few seconds.
• If you change your mode to or from Off, all data in your instance is lost after the restart.

Learn more about Key Value persistence modes in the documentation.

In recent weeks, we've gradually rolled out a number of optimizations for Dockerfile-based service builds on Render. These optimizations include:

• Tuning chunk size and parallelism for build image uploads
• Speeding up build scheduling on Render infrastructure
• Parallelizing generated image upload with export to build cache
• Storing build cache in Render's own image registry with automatic pruning

Together, these optimizations have reduced median build time for Docker-based services by 60%:

Before these optimizations (week of March 15), median build time was 87 seconds, consistent with prior weeks. After all optimizations landed, the highest weekly median observed has been 32 seconds (a conservative 60% reduction). Build times remain in this range.

Now in beta, Pro workspaces and higher can configure OpenID Connect (OIDC) to authenticate their Render services with AWS. This enables your services to securely access AWS resources at runtime using automatically rotated credentials.

The setup flow looks like this:

1. Add Render as an OIDC identity provider in AWS IAM.
2. Create or update IAM roles that trust the Render OIDC provider.
3. Add an AWS_ROLE_ARN environment variable to each Render service with the IAM role ARN it should assume.
4. Redeploy each service. Render starts issuing and rotating OIDC credentials automatically.

Get started in the documentation.

In recent weeks, we've gradually rolled out a number of build optimizations for Render's Node.js native runtime, including:

• Tuning chunk size and parallelism for build image uploads
• Caching of commonly used Node.js versions
• Sharing universal layers across build images
• Speeding up build scheduling on Render infrastructure

Together, these optimizations have reduced median build time for Node.js services by 25%:

Before these optimizations (week of March 22), median build time was 42 seconds, consistent with prior weeks. After all optimizations landed, the highest weekly median observed has been 31 seconds (a conservative 25% reduction). Build times remain in this range.

You can now SSH into an ephemeral instance of your service, which Render spins up specifically for your SSH session. This enables you to inspect your service's runtime environment and execute one-off commands without affecting your production instances.

Previously, all SSH sessions connected to one of a service's running instances (except for cron jobs). This remains the default behavior.

Using version 2.20.0 or later of the Render CLI, provide the --ephemeral option to the render ssh command:

Render creates an ephemeral instance using the same build artifact as your running instances. It does not execute your service's start command after spinning up.

By default, the ephemeral instance uses the same instance type as the service's other instances. To use a different instance type, provide the --plan option to the render ssh command:

As with all instances, ephemeral SSH instances are billed according to their instance type, prorated by the second. See pricing.

Learn more in the documentation.