https://render.com Render 2025-12-13T03:53:58.790Z https://github.com/jpmonette/feed Changelog for Render https://cdn.sanity.io/images/hvk0tap5/production/0ea63c1b6854bd803489557afb4ea54b85239418-128x128.png?fit=max&auto=format All rights reserved 2025, Render <![CDATA[Autonomously debug builds with Jules by Google Labs]]> https://render.com/changelog/autonomously-debug-builds-with-jules-by-google-labs 2025-12-10T00:00:00.000Z You can now integrate your Render workspace with Jules—Google Labs' asynchronous coding agent—to autonomously debug your Render builds.

To configure the integration, create an API key in the Render Dashboard (dashboard.render.com/jules) and paste it into the appropriate field on the Jules integrations page:

With the integration enabled, Jules monitors pull request previews on your service repos and asynchronously plans and commits fixes for build failures.

Learn more in the documentation.

]]> <![CDATA[Default Bun version updated to 1.3.4]]> https://render.com/changelog/default-bun-version-updated-to-1-3-4 2025-12-09T00:00:00.000Z Newly created services now use Bun 1.3.4 by default. You can always specify a different version.

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

]]> <![CDATA[Rotate Postgres credentials with enhanced user management]]> https://render.com/changelog/rotate-postgres-credentials-with-enhanced-user-management 2025-11-21T00:00:00.000Z Render Postgres databases now support self-serve credential rotation via managed creation and deletion of PostgreSQL users.

Add and delete users from your database's page in the Render Dashboard, or via the Render API:

A newly created user becomes your database's new "default" user, used in the database's connection URLs shown in the Render Dashboard. Blueprint-managed services that dynamically reference your database's connection string will update to use the new default credentials on your next Blueprint sync.

Learn more about PostgreSQL users and credential rotations in the documentation.

]]> <![CDATA[Webhooks for completed actions now include the action's result]]> https://render.com/changelog/webhooks-for-completed-actions-now-include-the-actions-result 2025-11-14T00:00:00.000Z The following webhook event types now include a status field in their payload, enabling you to quickly respond to the result of the corresponding action:

  • Build Ended
  • Deploy Ended
  • Cron Job Run Ended
  • Job Run Ended (for one-off jobs)

For a completed action, this field's value is one of succeeded, failed, or canceled. You can use this value in CI to terminate a workflow if a build or deploy fails.

Additionally, the Server Unhealthy event type has been removed in favor of Server Failed, which surfaces runtime failures for your service with significantly less "notification noise".

Learn more about webhooks in the documentation.

]]> <![CDATA[PostgreSQL 18 is now available for Render Postgres databases]]> https://render.com/changelog/postgresql-18-is-now-available-for-render-postgres-databases 2025-11-13T00:00:00.000Z Render Postgres databases now support PostgreSQL version 18. This is now the default version for newly created databases (you can specify a different version at creation time).

You can upgrade an existing database in-place from its Info page in the Render Dashboard:

Note that your database will be temporarily unavailable during the upgrade. The process usually takes less than one hour.

Learn more about PostgreSQL 18 in the release notes. Learn more about database upgrades in the documentation.

]]> <![CDATA[Adopting new outbound IP ranges for all regions]]> https://render.com/changelog/adopting-new-outbound-ip-ranges-for-all-regions 2025-11-07T00:00:00.000Z As announced in September, Render is now in the process of moving all outbound traffic to use the new IP ranges introduced on October 27th:

Each region has its own set of new ranges and original IPs. As part of this change, outbound traffic will no longer use the original IPs. These IPs will be retired fully by December 1st.

As of today, this switchover is complete for the following regions:

  • Ohio
  • Virginia
  • Singapore

The Oregon region is scheduled for November 10, and Frankfurt has yet to be scheduled. Subscribe to Render's status page for future updates.

If you use outbound IPs to allow access to an external system, you must add the new IP ranges to that system's access rules. You can safely remove all of the original IPs from your access rules starting December 1st.

Learn more about outbound IPs in the documentation.

]]> <![CDATA[Automatically increase your database storage when running low]]> https://render.com/changelog/automatically-increase-your-database-storage-when-running-low 2025-11-06T00:00:00.000Z You can now enable storage autoscaling for Render Postgres databases. When enabled, Render detects when your database is over 90% full and automatically increases its storage by 50% (rounded up to the nearest multiple of 5 GB).

For example, a 50 GB database that's using over 45 GB will automatically increase its storage to 75 GB. This increase is permanent.

Enable storage autoscaling with the following steps:

  1. From your database's Info page in the Render Dashboard, scroll down to the Postgres Instance section and click Update.
  2. Scroll down to the Enable Storage Autoscaling field and toggle the switch.
  3. Click Save Changes.

Learn more about storage autoscaling in the documentation.

]]> <![CDATA[Blueprints now support projects and environments]]> https://render.com/changelog/blueprints-now-support-projects-and-environments 2025-10-27T00:00:00.000Z Blueprints (Render's infrastructure-as-code model) now enable you to define projects and environments in your workspace, and to assign resources to those environments:

Your render.yaml file now supports two new top-level fields:

  • projects: an array of project definitions, each with one or more environments and their associated resources
  • ungrouped: an object for defining resources that belong to no environment

If you define a resource under one of these new fields, do not duplicate it in your file's top-level services / databases / envVarGroups fields. These fields remain supported, and resources in them keep their currently assigned environment (if any).

Learn more about Blueprint support for projects and environments in the documentation.

]]> <![CDATA[Web service edge caching now supports all file types]]> https://render.com/changelog/web-service-edge-caching-now-supports-all-file-types 2025-10-17T00:00:00.000Z Edge caching for web services now includes the option to cache response data for all file types—not just for a predefined list of common static file types (like images and PDFs).

You choose which set of Cacheable File Types to allow when you enable edge caching:

Caching all file types increases the risk of caching dynamic content. To prevent this, make sure to set proper Cache-Control headers for all of your service's dynamic responses before enabling this option.

Learn more about edge caching in the documentation.

]]> <![CDATA[Enterprise orgs can set inbound IP rules for web services and static sites]]> https://render.com/changelog/enterprise-orgs-can-set-inbound-ip-rules-for-web-services-and-static-sites 2025-10-02T00:00:00.000Z Enterprise orgs on Render can now set inbound IP rules for the following:

  • Individual web services and static sites
  • An entire environment
  • An entire workspace

IP rules are allowlists of IP ranges specified using CIDR notation. Add rules from your service or environment's settings in the Render Dashboard:

Requests to your service from a disallowed IP receive a 403 Forbidden response.

All plan types support setting inbound IP rules for individual Render Postgres and Key Value datastores (this is existing functionality).

Learn more about IP rules in the documentation.

]]>