Render Changelog

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.