# Render Changelog Last generated: 2026-06-07 Source: https://render.com/changelog ## Tooling releases ### Render CLI - Version: v2.20.0 - Date: 2026-06-05 - URL: https://github.com/render-oss/cli/releases ### Python SDK - Version: v0.7.0 (Beta) - Date: 2026-06-03 - URL: https://github.com/render-oss/sdk/releases/tag/python/v0.7.0 ### TypeScript SDK - Version: v0.6.0 (Beta) - Date: 2026-06-03 - URL: https://github.com/render-oss/sdk/releases/tag/typescript/v0.6.0 ## Core changelog feed Displaying the 25 most recent entries. ### Authenticate Render services with AWS using OIDC - Date: 2026-06-05 - Change type: Early Access - URL: https://render.com/changelog/authenticate-render-services-with-aws-using-oidc 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](https://render.com/docs/oidc). ### Reduced median build time for Node.js services by 25% - Date: 2026-06-04 - Change type: Improved - URL: https://render.com/changelog/reduced-median-build-time-for-node-js-services-by-25-percent 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%: ![Median Node.js build times by week](https://cdn.sanity.io/images/hvk0tap5/production/2b3779b70a703ee5c93dddea18042652024958dd-1620x928.png?w=450) 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. ### SSH into an ephemeral service instance - Date: 2026-06-02 - Change type: New - URL: https://render.com/changelog/ssh-into-an-ephemeral-service-instance 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](https://render.com/docs/cli), provide the `--ephemeral` option to the `render ssh` command: ```shell render ssh srv-abc123 --ephemeral ``` 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: ```shell render ssh srv-abc123 --ephemeral --plan starter ``` As with all instances, ephemeral SSH instances are billed according to their instance type, prorated by the second. [See pricing.](https://render.com/pricing#services) Learn more in the [documentation](https://render.com/docs/ssh#starting-an-ephemeral-shell-instance). ### Add dedicated outbound IPs to your workspace - Date: 2026-05-19 - Change type: New - URL: https://render.com/changelog/add-dedicated-outbound-ips-to-your-workspace **Pro** workspaces and higher can now create sets of **dedicated IPs** to send outbound service traffic through static, reserved addresses:
![A dedicated IP set in the Render Dashboard](https://cdn.sanity.io/images/hvk0tap5/production/62daac556ae87244e9c2798a2041dbb7ad6c2c7b-1024x372.png?w=450)
Use dedicated IPs to simplify allowlisting your Render services with external providers. Each dedicated IP set includes three IPv4 addresses in a single region. You can scope a set to your entire workspace or to specific environments. Services outside a set’s scope continue to use Render’s shared [outbound IP ranges](https://render.com/docs/outbound-ip-addresses). Render bills your workspace $100/month for each IP set. Get started with dedicated IPs in the [documentation](https://render.com/docs/dedicated-ips). ### Change your service's backing repo or image in the Render Dashboard - Date: 2026-05-11 - Change type: Improved - URL: https://render.com/changelog/change-your-services-backing-repo-or-image-in-the-render-dashboard You can now change an existing service's backing Git repository or Docker image in the Render Dashboard. Previously, these changes required the Render API. 1. In the [Render Dashboard](https://dashboard.render.com), open your service's **Settings** page. 2. Under **Build > Source**, click **Edit**: ![Editing a service's build source in the Render Dashboard](https://cdn.sanity.io/images/hvk0tap5/production/54b5420d9876365084c609bdccc1b89b5e008e90-1314x384.png?w=450) The **Update Source** dialog appears. 3. Select a new build source. 4. If you're using a Git repo, confirm the **Runtime**, **Build Command**, and **Start Command** to use: ![Selecting runtime, build command, and start command](https://cdn.sanity.io/images/hvk0tap5/production/b61d806fa688d0381f7f05d674a860ff792421f3-1338x1246.png?w=450) (For static sites, you specify your content's **Publish Directory** instead of a start command.) 5. Submit your changes. Render automatically triggers a deploy using the new backing source. Note that you cannot change an existing service's _type_ (between web service, static site, and so on). ### Reduced median build time for Python services by 27% - Date: 2026-04-30 - Change type: Improved - URL: https://render.com/changelog/reduced-median-python-service-build-time-by-27-percent In recent weeks, we've gradually rolled out a number of build optimizations for Render's Python native runtime, including: - Tuning chunk size and parallelism for build image uploads - On-disk caching of commonly used Python versions - Sharing universal layers across build images Together, these optimizations have reduced median build time for Python services by 27%: ![Median Python build times by week](https://cdn.sanity.io/images/hvk0tap5/production/583a24d985f22197a4a7454502c45cf991ef28dc-1740x928.png?w=450) Before these optimizations (week of March 16), median build time was 76 seconds, consistent with prior weeks. After all optimizations landed (week of April 13), it dropped to 55 seconds (a conservative 27% reduction). Build times in the weeks since have remained in this range. ### Updated plans for Render workspaces - Date: 2026-04-23 - Change type: Adjusted - URL: https://render.com/changelog/updated-plans-for-render-workspaces We've rolled out new workspace plans to make Render’s pricing more scalable for modern, fast-growing teams. Each new workspace plan corresponds to a legacy plan: - **Hobby** (free) replaces the legacy Hobby plan. - **Pro** ($25/month flat) replaces Professional ($19 per member/month). - **Scale** ($499/month flat) replaces Organization ($29 per member/month). - **Enterprise** (custom) remains the same. These new plans: * **Remove seat fees**. Our new **Pro** and **Scale** plans move to a flat subscription with unlimited team members included. * **Add self-serve compliance.** The **Pro** plan includes SOC 2 and ISO 27001 reports, plus audit logs. The **Scale** plan adds SSO, SCIM, advanced RBAC, HIPAA-enabled workspaces, and multi-workspace management. * **Refine usage-based pricing**. Each workspace plan includes baseline usage for: * Custom domains ($0.25/month for each additional domain) * Build pipeline minutes ($5 for each additional 1000 minutes) * Bandwidth ($0.15 for each additional GB) * The new **Hobby** and **Pro** plans include less bandwidth than their legacy counterparts, because legacy plans subsidized bandwidth usage with seat fees. Bandwidth overages are now billed per GB instead of in 100 GB increments. There are no changes to Render's existing compute pricing. **Timeline:** 1. Starting today, all newly created workspaces use a new plan. 2. Existing workspaces can [opt in](https://render.com/docs/new-workspace-plans#moving-to-a-new-plan) to any new plan between now and August 1, 2026. 3. On August 1, any remaining workspaces on a legacy plan will automatically move to the corresponding new plan. **For more information on new workspace plans:** - See the [blog post](https://render.com/blog/better-pricing-for-fast-growing-teams) for a broader summary of these updates. - See the [pricing page](https://render.com/pricing) to compare the new plans at a glance. - See the [docs](https://render.com/docs/new-workspace-plans) for full details on plan changes and opting in your workspace. ### Default Node.js version updated to 24.14.1 - Date: 2026-04-21 - Change type: Improved - URL: https://render.com/changelog/default-node-js-version-updated-to-24-14-1 Newly created Node.js services now use Node.js 24.14.1 by default. You can always [specify a different version](https://render.com/docs/node-version). *Existing* Node.js services keep their original default version to prevent breaking changes. ### Create new services from the Render CLI - Date: 2026-04-16 - Change type: Improved - URL: https://render.com/changelog/create-new-services-from-the-render-cli You (and your agents) can now create new services directly from the terminal using the [Render CLI's](https://render.com/docs/cli) `services create` command: ```bash render services create \ --name hello-world \ --type web_service \ --runtime node \ --region virginia \ --plan free \ --repo https://github.com/render-examples/express-hello-world \ --branch main \ --build-command "yarn" \ --start-command "node app.js" \ --output json ``` As shown, you provide your service's initial configuration (service type, runtime, region, etc.) as individual options to this command. For all supported options, run `render help services create` or see the generated [command reference](https://render.com/docs/cli-reference#services-create). Get started with the Render CLI in the [docs.](https://render.com/docs/cli) ### Automatic Go version updates - Date: 2026-04-16 - Change type: Improved - URL: https://render.com/changelog/automatic-go-version-updates Render's native Go environment now automatically updates to the latest stable Go 1.x version, usually within 24 hours of a new release. After an update, your service starts using the new version with its next deploy. Previously, we handled Go version updates manually, which meant delays between a new Go release and availability on Render. This is now fully automated. If you need to pin to a specific Go version, you can deploy using a Docker image. Learn more about [supported languages and versions](https://render.com/docs/language-support) in the docs. ### Render Workflows now in public beta - Date: 2026-04-07 - Change type: New - URL: https://render.com/changelog/render-workflows-now-in-public-beta [Render Workflows](https://render.com/workflows) is now in public beta, with SDK support for TypeScript and Python. Define durable tasks and chain them into long-running background processes for agent logic, data pipelines, billing flows, and more. ![Diagram illustrating chained task runs](https://cdn.sanity.io/images/hvk0tap5/production/d7936cd6ff7265563fff1edc300a637becaa5883-1467x510.png?w=450) Deploy your task definitions as a Workflow service, trigger runs from your app (or via API/Dashboard), and let Render handle queuing, retries, state management, and parallel execution. Workflows run on Render’s private network with unified logs and metrics so you can debug runs in one place. Explore examples in the [Workflows Playground](https://render.com/workflows/playground?example=hello-world&lang=typescript) or get started with `render workflows init` in the Render CLI. Learn more in the [announcement post](https://render.com/blog/durability-as-code-introducing-render-workflows) and [documentation](https://render.com/docs/workflows). ### Audit log updates: Added the EndShellEvent type, plus metadata for source IP and user agent - Date: 2026-03-25 - Change type: Improved - URL: https://render.com/changelog/audit-log-updates-added-the-endshellevent-type-plus-metadata-for-source-ip-and-user-agent Workspace audit logs now include the `EndShellEvent` event type, which indicates that a workspace member closed an active [dashboard shell or SSH](https://render.com/docs/ssh) session to a Render service. Audit logs already included `StartShellEvent`, which is logged when a shell session starts. Audit log events also now include `source_ip` and `user_agent` properties in their metadata field whenever these values are available: ```json { "source_ip": "192.0.2.0", "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)…", } ``` Learn more about audit logs in the [docs](https://render.com/docs/audit-logs). ### Free web services now remain active while receiving WebSocket messages - Date: 2026-02-24 - Change type: Adjusted - URL: https://render.com/changelog/free-web-services-now-remain-active-while-receiving-websocket-messages Free web services now spin down after going 15 minutes without receiving _either_ of the following: - An incoming HTTP request - An incoming WebSocket message from an existing connection Previously, only incoming HTTP requests delayed spindown. This meant that a service could spin down even while actively receiving WebSocket traffic. Learn more about free web services in the [docs](https://render.com/docs/free#free-web-services). ### Updated version defaults: Python to 3.14.3, uv to 0.10.2 - Date: 2026-02-11 - Change type: Improved - URL: https://render.com/changelog/updated-version-defaults-python-to-3-14-3-uv-to-0-10-2 Newly created Python services now use Python 3.14.3 and uv version 0.10.2 by default. You can always specify a different version of both [Python](https://docs.render.com/python-version) and [uv](https://render.com/docs/uv-version). *Existing* Python services keep their original default versions to prevent breaking changes. ### Render CLI v2.8.0 - Date: 2026-02-10 - Change type: New - URL: https://render.com/changelog/render-cli-v2-8-0 **New command:** `render workspaces` By default, `render workspaces` lists your available workspaces in an interactive menu. Optionally, you can also list workspaces in plaintext, JSON, or YAML format. For example, the following command lists workspaces in YAML: ```shell render workspaces -o yaml ``` --- **Non-interactive mode for `render psql`** You can now pass queries directly through `render psql` and print the response in plaintext, JSON, or YAML. For example: ```shell render psql my-database -c "SELECT id, name FROM projects LIMIT 5;" -o json ``` --- **Show latest available version** The `render --version` command now informs you if a new version of the Render CLI is available. --- For more details, see the release on [GitHub](https://github.com/render-oss/cli/releases/tag/v2.8.0). Get started with the Render CLI in the [docs](https://render.com/docs/cli). ### Blueprints now support custom filenames and paths - Date: 2026-02-09 - Change type: Improved - URL: https://render.com/changelog/blueprints-now-support-custom-filenames-and-paths Blueprints (Render's [infrastructure-as-code model](https://render.com/docs/infrastructure-as-code)) now support custom filenames and paths for YAML configuration files. Previously, Blueprints required a file named `render.yaml` in your repository's root directory. You can specify a custom path when creating a new Blueprint in the [Render Dashboard](https://dashboard.render.com/): [image: Setting a Blueprint file path in the Render Dashboard] You can also update an existing Blueprint's file path from its **Settings** page. If you don't set a custom path, Render defaults to using `render.yaml` in your repository root. Learn more in the [documentation](https://render.com/docs/infrastructure-as-code#setup). ### Service events no longer erroneously report scaling down to zero instances - Date: 2026-02-06 - Change type: Fixed - URL: https://render.com/changelog/service-events-no-longer-erroneously-report-scaling-down-to-zero-instances In rare cases, Render would erroneously emit an **Autoscaler starting to scale down to 0 instances** event for services with autoscaling enabled. These events were triggered by momentary latency in scaling metrics, and they did *not* modify the instance count of the affected service. This behavior is now resolved. ### Validate Blueprint files using the Render CLI or API - Date: 2026-01-28 - Change type: New - URL: https://render.com/changelog/validate-blueprint-files-using-the-render-cli-or-api The Render CLI and API now support validation of `render.yaml` files used with [Render Blueprints](https://render.com/docs/infrastructure-as-code). This enables you to quickly verify that Blueprint changes are valid in your local dev environment or as part of CI. - **CLI:** Run `render blueprints validate render.yaml` - Requires version 2.7.1 or later of the CLI. Learn how to [upgrade](https://render.com/docs/cli#1-install-or-upgrade). - **API:** Provide your `render.yaml` file to the new [Validate Blueprint](https://api-docs.render.com/reference/validate-blueprint) endpoint. - New to the Render API? [Start here.](https://render.com/docs/api) These additions complement existing IDE support for Blueprint validation. Learn more in the [documentation](https://render.com/docs/blueprint-spec#validating-blueprints). ### Default Node.js version updated to 22.22.0 - Date: 2026-01-15 - Change type: Improved - URL: https://render.com/changelog/default-node-js-version-updated-to-22-22-0 Newly created Node.js services now use Node.js 22.22.0 by default. You can always [specify a different version](https://render.com/docs/node-version). *Existing* Node.js services keep their original default version to prevent breaking changes. ### Improved logs UX in the Render dashboard and CLI - Date: 2025-12-17 - Change type: Improved - URL: https://render.com/changelog/improved-logs-ux-in-the-render-dashboard-and-cli We've made several improvements to the Render dashboard to make logs easier to consume: - Expanded logs container to view more log lines at once - Click individual log lines to open a detail view - Toggle live tail mode - Light and dark mode support to match your selected dashboard theme [image: Expand errors, open lines in detail view, toggle live tail mode, and more.] Additionally, the `render logs` CLI command now supports paginated infinite scroll, making it easier to navigate extensive log histories. [image: Traverse long log histories with infinite scroll.] Learn more about using the [Render logs UI](https://render.com/docs/logging) and the [Render CLI](https://render.com/docs/cli). ### Autonomously debug builds with Jules by Google Labs - Date: 2025-12-10 - Change type: New - URL: https://render.com/changelog/autonomously-debug-builds-with-jules-by-google-labs 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](https://dashboard.render.com/jules)) and paste it into the appropriate field on the Jules integrations page: [image: Adding your Render API key to Jules] With the integration enabled, Jules monitors [pull request previews](https://render.com/docs/service-previews#pull-request-previews-git-backed) on your service repos and asynchronously plans and commits fixes for build failures. Learn more in the [documentation](https://render.com/docs/llm-support#jules-integration). ### Default Bun version updated to 1.3.4 - Date: 2025-12-09 - Change type: Improved - URL: https://render.com/changelog/default-bun-version-updated-to-1-3-4 Newly created services now use Bun [1.3.4](https://bun.sh/blog/bun-v1.3.4) by default. You can always [specify a different version](https://docs.render.com/bun-version). *Existing* services keep their original default Bun version to prevent breaking changes. ### Rotate Postgres credentials with enhanced user management - Date: 2025-11-21 - Change type: Improved - URL: https://render.com/changelog/rotate-postgres-credentials-with-enhanced-user-management 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: [image: Creating a new managed PostgreSQL user in the Render Dashboard] 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](https://render.com/docs/postgresql-credentials). ### Webhooks for completed actions now include the action's result - Date: 2025-11-14 - Change type: Improved - URL: https://render.com/changelog/webhooks-for-completed-actions-now-include-the-actions-result 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](https://render.com/docs/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](https://render.com/docs/webhooks). ### PostgreSQL 18 is now available for Render Postgres databases - Date: 2025-11-13 - Change type: New - URL: https://render.com/changelog/postgresql-18-is-now-available-for-render-postgres-databases 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](https://dashboard.render.com): [image: Upgrading a Render Postgres database 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](https://www.postgresql.org/docs/release/18.0/). Learn more about database upgrades in the [documentation](https://render.com/docs/postgresql-upgrading).