Changelog

Now in public beta, use Render Sandboxes to spin up isolated, ephemeral compute environments for executing untrusted code, such as agent-generated apps and scripts.

Create and manage sandboxes programmatically using the Render CLI or the TypeScript and Python SDKs.

Each sandbox provides:

• Isolated runtime: Run commands and manage files in a contained environment with its own filesystem.
• Configurable compute: Choose from four compute plans with up to 8 CPU and 16 GB of RAM.
• Indefinite execution: Run sandboxes for as long as you need. Configure separate timeouts for automatic suspension and termination, or disable both to run indefinitely.
• Network controls: Restrict outbound traffic to specific HTTPS destinations, or block it entirely.
• Reusable snapshots: Capture filesystem state or running processes, then restore that state in new sandboxes.

To create your first sandbox and execute a command:

1. Install the latest version of the Render CLI.

2. Spin up a sandbox with:

   Copy your new sandbox's ID from the command's output.

3. Replace sbx-abc123 with your sandbox's ID in the following commands:

Get started with Render Sandboxes in the documentation.

Docker-based service previews and preview environments now use the build cache from their base service’s most recent successful build. Previously, each preview’s first build started with an empty cache.

This optimization has reduced median first-build time for Docker-based previews by 45%:

Before this change (September 6 to October 28), median first-build time was 73 seconds. Since the optimization landed on October 29, the highest observed weekly median is 40 seconds.

Learn more about service previews and preview environments.

On November 18, 2026, Render will begin supporting separate service previews and preview environments for each pull request in a GitHub PR stack:

Currently, Render creates previews only for PRs that directly target your service's linked branch. This means that only the bottom PR in a stack can generate previews.

Beginning November 18, Render will apply your existing preview mode to all PRs in a stack:

• Automatic: Render will create previews for each PR in the stack, except for any that include [skip preview] in their title.
• Manual: Render will create previews only for PRs in the stack that include [render preview] in their title.

Each preview creates new resources that are billed according to their compute plans and other specs. If you use automatic previews, this change might increase your preview-related costs.

• Learn more about previews in the documentation for service previews and preview environments.
• To enable previews for stacked PRs sooner, reach out to our support team in the Render Dashboard.

Newly created services that use Node.js or Bun now default to the following versions:

• Node.js 24.22.1
• Bun 1.4.4

You can always specify a different version of Node.js or Bun.

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

Render now supports canary builds for Bun. Canary builds let you preview upcoming Bun features before they reach a stable release.

To use canary builds, do one of the following:

• Set your service's BUN_VERSION environment variable to canary.
• Add a .bun-version file to the root of your repo with the single line: canary.

Don't use Bun canary builds for production services. Canary builds are untested pre-releases. Learn more about setting your Bun version.

Render now supports two additional compute plans for Key Value instances:

• 3 GB RAM with up to 3,000 simultaneous connections
• 50 GB RAM with up to 50,000 simultaneous connections

We've also reduced pricing for existing Key Value compute plans that provide at least 1 GB RAM. The reduced pricing takes effect for all applicable Key Value instances starting October 1.

View all available plans and their latest pricing on the pricing page. Learn more about Render Key Value in the docs.

You can now manage your workflow services using Blueprints, Render's infrastructure-as-code model.

Define workflows alongside other service types in your Blueprint YAML. Here's an example:

Workflows support most of the same configuration fields as other service types, with exceptions noted in the Blueprint YAML Reference. Notably, you don't provide a plan field for workflows, because you instead specify compute plans per task directly in your code.

Note the following:

• Workflows do not yet support preview environments, which skip replicating any workflows present in your Blueprint (other services are replicated as usual).
• Render rejects a Blueprint that would create a workflow with the same name as an existing Blueprint-managed workflow in your workspace.

Learn more about Render Workflows in the documentation.

Services now have a new Deploys page in the Render Dashboard.

The Deploys page features:

• Your service's deploy history, without a date cutoff.
• A Live badge indicating the current deploy.
• Status of in-progress deploys.
• A banner flagging when auto-deploys are disabled.

Previously, deploys were only visible on the Events page, interspersed with other events, and capped at a 90-day history. The Events page continues to show all service events, including deploys.

Cron jobs also have new Builds and Runs pages that separate build and run history.

Learn more in the documentation.

Render Workflows uses a new default compute plan for task runs: flex.

The flex compute plan provides up to 1 CPU and 4 GB of RAM. Task runs on flex are billed only for the CPU and RAM they actually use, resulting in significantly lower costs for computationally inexpensive runs.

The flex compute plan replaces the starter and standard compute plans for Render Workflows. Tasks that previously used starter or standard now automatically use flex instead.

For tasks with higher resource requirements, you can assign a different compute plan in your task's definition:

Learn more about compute plans for Render Workflows in the documentation.