Render Changelog

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.19.0 or later of the Render CLI, provide the --ephemeral option to the render ssh command:

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 --size option to the render ssh command:

render ssh srv-abc123 --ephemeral --size starter

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.

Pro workspaces and higher can now create sets of dedicated IPs to send outbound service traffic through static, reserved addresses:

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.

Render bills your workspace $100/month for each IP set. Get started with dedicated IPs in the documentation.

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, open your service's Settings page.

2. Under Build > Source, click Edit:

   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:

   (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).

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%:

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.

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 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 for a broader summary of these updates.
• See the pricing page to compare the new plans at a glance.
• See the docs for full details on plan changes and opting in your workspace.

Newly created Node.js services now use Node.js 24.14.1 by default. You can always specify a different version.

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

You (and your agents) can now create new services directly from the terminal using the Render CLI's services create command:

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.

Get started with the Render CLI in the docs.

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 in the docs.

Render 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.

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 or get started with render workflows init in the Render CLI. Learn more in the announcement post and documentation.

Workspace audit logs now include the EndShellEvent event type, which indicates that a workspace member closed an active dashboard shell or 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:

{
  "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.

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.

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 and uv.

Existing Python services keep their original default versions to prevent breaking changes.

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:

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:

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. Get started with the Render CLI in the docs.

Blueprints (Render's infrastructure-as-code model) 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:

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.

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.

The Render CLI and API now support validation of render.yaml files used with Render Blueprints. 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.

• API: Provide your render.yaml file to the new Validate Blueprint endpoint. New to the Render API? Start here.

These additions complement existing IDE support for Blueprint validation. Learn more in the documentation.

Newly created Node.js services now use Node.js 22.22.0 by default. You can always specify a different version.

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

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

Additionally, the render logs CLI command now supports paginated infinite scroll, making it easier to navigate extensive log histories.

Learn more about using the Render logs UI and the Render CLI.