Render Release Notes

We're always looking for ways to reduce costs for our customers, and today we're passing along savings across several of our Key Value compute plans.

Starting October 1, 2026, all Key Value plans 1GB or higher will cost 20-45% less. We are also adding two new plans, 3GB and 50GB, to fill the gaps between our existing plans, allowing you to scale vertically more efficiently.

You can view all of the new plans and updated pricing on our Pricing Page.

If you already have a paid Key Value service running on Render, no action is needed to take advantage of the new pricing — it applies automatically to existing services starting October 1, 2026.

Key Value compute plans

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.

By default, Render rebuilds your code every time you deploy, even if the code hasn't changed from the previous build. But if you're deploying the same commit to staging then promoting to production, or running multiple services from one repository, you shouldn't have to wait for Render to rebuild identical code.

You can now save time and compute by reusing builds across multiple Render services. Reusing builds also ensures that the correct artifact is promoted between dev, staging, and production environments.

Starting today, we are rolling this feature out in Private Beta to select customers. To request access, fill out this form, and our product team will be in touch when we're ready to onboard you.

When to reuse builds

If you run two or more services on Render built from the same repository or image (a web service and its workers, multiple services within a monorepo, or the same service deployed across staging and production) reusing builds can usually save you time and money. The benefit increases with the number of services sharing a build and the time each build takes.

Reusing builds when promoting between environments also ensures that those environments don't drift apart because of changes in build-time variables or in how dependencies resolve.

How it works

Define a Build Source once by specifying a repository, branch, and build command, and Render produces one immutable build artifact. Any linked service across development, staging, and production can deploy that exact artifact with no rebuild.

For services linked to a Build Source, build-time and runtime variables are now scoped separately, so runtime secrets aren’t available during the build unless you explicitly pass them as build-time variables. This separation makes it safer to promote the same build across environments instead of rebuilding it with a different set of credentials.

What’s supported during Private Beta

Currently, you can reuse builds for web services, private services, and background workers. This allows you to:

• Link multiple services to a single Build Source, so the same commit builds once rather than once per service
• Deploy the same build across linked services, so production runs the exact artifact you verified in staging
• Automatically deploy the latest build from a Build Source or manually deploy a specific build
• Create and manage Build Sources through the REST API and Blueprints, and view Build Sources, linked services, and related logs in the Render Dashboard

See the documentation for current limitations.

What's next

During Beta, we plan to add cron job support, a fuller Dashboard experience, and CLI and Terraform support.

How to join Private Beta

Capacity is limited during this phase. To request access, fill out this form. We'll review your request and reach out when we are ready to onboard your team.

Once approved, you’ll:

• Work directly with the Render Engineering team as you implement Build Reuse and share feedback
• Review and influence design details across the REST API, Blueprints, and Render Dashboard before they’re finalized
• Get early visibility into related features as they’re introduced during Private Beta

Your use case and feedback will help shape Build Reuse as we work toward General Availability.

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:

services:
  - type: workflow
    name: my-workflow
    runtime: python
    region: oregon
    repo: https://github.com/render-examples/render-workflows-examples-python
    branch: main
    rootDir: hello-world
    buildCommand: pip install -r requirements.txt
    startCommand: python main.py

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.

When you push code, a short list of questions follows. Which commit is serving traffic? Did the deploy go through? If it didn't, what went wrong? Every Render service has a new Deploys page built to answer exactly those.

Deploys

Deploys is the page you land on when you open a service, and Events now sits under Monitoring, still showing every service event including deploys.

The page carries your last 30 deploys regardless of age, so a service last deployed three years ago still has a history worth reading. A Live badge marks the deploy serving traffic right now, which is not always the newest one. If a later deploy failed or is still building, the badge stays on the deploy actually serving traffic.

Click any deploy to open its details. A Notices panel collects the context for that one: "Exited with status 1 while building your code," a health check that never passed, whatever applies, in a single place.

Roll back and Render tells you up front that auto-deploy is going off. Manually deploy a specific commit and auto-deploy goes off as well. The Deploys page carries a banner afterward, and so does Events. The banner links straight into deploy settings when you want it back on.

Cron jobs get Builds and Runs as separate pages, which keeps build history and run history apart.

See it in action

Speed came from the layer underneath

Render service builds now run on nodes with faster CPU and disk, and median service build time fell from 38 seconds to 21 seconds over the summer, a 40% reduction in the median measured across all runtimes. The changelog entry has the week by week numbers and the per-runtime breakdown.

More on the path from code to production

Faster builds and the Deploys page are aimed at the same thing: making it simpler to get code to production, and simpler to see what happened when you did. There is more coming on that path. Read the docs on deploys to get started!

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:

const myTask = task(
  {
    name: 'myTask',
    plan: '2c-4g' //highlight-line
  },
  function myTask(ctx: TaskContext, a: number): number {
    return a * a
  }
)

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

The Render CLI now automatically collects usage telemetry to help us understand common use cases and improve user experience. Telemetry is enabled by default in version 2.26.0 or later.

Telemetry includes the following:

• Commands run (e.g., render services list)
• Command performance and completion status
• CLI version
• System information
• Execution context

The Render CLI does not collect sensitive user data, such as command arguments, environment variable values, passwords, or the contents of your files.

You can disable telemetry at any time by setting either the RENDER_CLI_DISABLE_ANALYTICS or DO_NOT_TRACK environment variables. For example:

export DO_NOT_TRACK=1

Learn more in the documentation.

An agent harness holding hours of session state or a retrieval pipeline keeping embeddings in memory needs a much higher ratio of RAM to CPU than typical request/response services. Deploying these workloads on long-running, stateful compute shouldn't mean overpaying for CPU to get the memory you need.

Today, we're adding over 15 new memory-optimized compute plans for Render services. These plans are designed specifically to help you run agents and other memory-intensive workloads efficiently.

More memory at every scale

Our new compute plans let you increase a service's memory independently of its CPU. At every 2+ CPU tier, there are now multiple memory options. For example, at 4 CPU you can choose between 8GB, 16GB, and 32GB of RAM.

You can see the full range of compute plans on our pricing page or in the Render Dashboard.

High-CPU plans

We're also introducing a 12-CPU tier for web services, private services, and background workers, with up to 96GB of RAM. These plans are built for workloads that need headroom to scale vertically.

For example, self-hosted agent platforms like OpenClaw often run many concurrent sessions on a single deployment, each holding its own state and often driving its own headless browser. Scaling up to make the agent more productive means giving it more resources on a single instance.

New, intuitive plan IDs

With more options to choose from, we are updating the naming convention for compute plans to make them more intuitive. Now, each plan has an ID referencing the relevant specs for the plan. For example the 4 CPU, 32GB RAM web service plan has an ID of 4c-32g. In practice, you only need to use this ID if you are setting your plan type through a Blueprint or using the Render CLI, API, or SDK.

Render Blueprints and the Render API, SDK, and CLI remain backward compatible with legacy compute plan values like standard, pro plus, and pro ultra. You can optionally update your code to use the new plan IDs, but no changes are required. To avoid any issues when you start using the new plan IDs, we recommend updating to the latest versions of Render clients and integrations, including the CLI and Terraform provider.

Choosing the right plan

If you're not sure whether to move one or more services to a higher memory plan, your service metrics are the best guide. The Render Dashboard shows CPU and memory usage for every service, so you can see which resource your workload actually runs out of.

If memory climbs while CPU stays flat, a memory-optimized plan gives your service the headroom it needs without stepping up a full CPU tier. A 2c-4g service pushing its memory limit, for example, can move to 2c-16g for four times the RAM with no change in CPU.

Alternatively, if one of your services is consistently only using a fraction of the CPU available to it, you may be able to reduce your costs by moving to a plan with the same RAM but lower CPU.

Whichever way you scale, it's worth sizing for your spikes rather than your average. Sustained memory pressure near a plan's limit risks out-of-memory restarts, so pick the memory option that covers your peaks with room to spare. The same logic applies if your service is CPU-bound, with request queues backing up or task throughput flattening out: move up a CPU tier, then choose the memory option that matches your footprint.

You can change a service's compute plan at any time. And if you'd like help choosing, our support team is available through the Render Dashboard.

We're introducing new compute plans for Render services, including memory-optimized plans with higher ratios of RAM to CPU and a new 12-CPU tier for web services, private services, and background workers.

To support the expanded catalog, we're also changing compute plan IDs to a spec-based format that includes the relevant specs. For example a web service compute plan with 4 CPU and 32GB RAM now carries the ID 4c-32g. This convention allows you to more easily intuit the specs of compute plans as we add additional options.

No action is needed to continue using your current compute plan(s). While you will see the IDs for plans change in the Render Dashboard and documentation, you can continue to use old plan IDs with the Render API, SDK, CLI, and Blueprints. To avoid any issues when you start using the new plan IDs, we recommend updating to the latest versions of Render clients and integrations, including the CLI and Terraform provider.

You can see the mapping of old plan names to new plan IDs in the Render Dashboard.

What’s new

• Increase memory without increasing CPU. At each 2+ CPU tier (2 CPU, 4 CPU, 8 CPU, etc.) we are adding multiple plans with more RAM. For example, at 2 CPU you can now choose between web service plans with 4 GB, 8GB, and 16 GB RAM.
• 12-CPU plans for heavy workloads. For customers running agent platforms or other heavy workloads, we are adding a set of 12-CPU plans with up to 96GB RAM.
• New compute plan IDs. To keep plan IDs intuitive as we add more options, we are replacing legacy IDs (Pro Plus, Pro Ultra, etc) with simple spec-based IDs. For example, the 2 CPU 4 GB web service plan now has an ID of 2c-4g. The Render API, CLI, SDK, and Blueprints will remain backward compatible with legacy plan IDs. No action is required.

"Compute plan" replaces "instance type" across the dashboard, API, CLI, and docs.

Today we’re making it easier to connect your coding agents to Render—and giving them more capabilities once they’re connected.

Our hosted MCP server now supports OAuth, so you can sign in through your browser instead of creating and copying a personal access token. We’ve also added MCP tools for triggering deploys and changing service plans, expanded our library from 3 skills to more than 20, and added full lifecycle management for Render resources to the CLI.

Render is available natively where many coding agents already run, including Cursor, Claude Code, Claude Desktop, Codex, and ChatGPT. Visit render.com/agents to get started.

Why this matters

Coding agents are already good at working inside a repository. They can explain a codebase, implement a feature, and open a pull request. But their work often stops at the edge of the repo because deploying, debugging, querying data, and managing infrastructure require access to the platform running the code.

MCP, the Render CLI, and Render Skills fill in that missing context. Together, they give agents a way to understand your infrastructure, take action on Render, and follow Render-specific best practices.

Connect with OAuth

Previously, connecting an AI tool to Render’s hosted MCP server required creating an API key and adding it to the tool’s configuration. That works, but it adds setup friction and requires you to handle a long-lived credential.

With OAuth, you connect the MCP server, sign in to Render in your browser, and authorize access to your account. That’s it.

API key authentication is still supported. It remains useful for CI jobs, unattended agents, and remote environments where a browser-based sign-in flow doesn’t make sense.

See setup instructions for each supported AI tool.

New MCP tools

We’ve added two more ways for agents to operate your Render services:

• Trigger deploys. Ask your agent to redeploy a service, optionally clearing the build cache. This is useful after changing an environment variable, diagnosing a stale build, or rolling forward a fix.
• Update service plans. An agent can inspect CPU and memory metrics, recommend a different compute plan, and apply the change after you approve it.

These tools build on existing support for creating services and datastores, querying Postgres, and analyzing logs and metrics. Instead of switching between your editor, terminal, and dashboard, you can describe the outcome you want and let your agent assemble the necessary steps.

From 3 Render skills to more than 20

MCP gives an agent access to Render. Skills help it use that access well.

Our expanded skills library covers services, deploys, debugging, monitoring, Postgres, Key Value, and the Render CLI. A supported coding agent can load the relevant guidance when it needs to deploy an application, investigate a failed build, query a database, or choose the right Render resource for a workload.

Install Render for your coding agent, or browse the complete skills library on GitHub.

Full lifecycle management in the CLI

The Render CLI can now manage the full lifecycle of your infrastructure across services, static sites, Postgres, and Key Value. You can create, inspect, update, suspend, resume, query, and delete resources without leaving the terminal.

Every operation supports non-interactive use and structured JSON or YAML output. That makes the same commands useful to a person at the terminal, an agent working on your behalf, or a script running in CI.

For example, you can create managed datastores for a feature branch:

render pg create \
  --name pr-482-db \
  --region oregon \
  --plan basic_256mb \
  --version 17 \
  --confirm --output json

render kv create \
  --name pr-482-cache \
  --region oregon \
  --plan starter \
  --memory-policy cache \
  --confirm --output json

See the CLI command reference for all supported resources and operations.

What this unlocks

Consider a disposable full-stack environment for a pull request. An agent can create a web service, Postgres database, and Key Value instance; deploy the feature branch; run tests against real managed infrastructure; inspect logs and metrics; and remove the environment after the PR merges.

While you can configure this to automatically happen for every PR using Blueprints, an agent can do it too.

A request can be as simple as:

Developer: Create an isolated Render environment for PR #482, run the integration suite, and remove it after merge.
Agent: I’ll provision a web service, Postgres database, and Key Value instance from the PR branch. I’ll return the environment URL, report any test or deployment failures, and ask before deleting resources.
Developer: Go ahead.
Agent: The environment is live and all 126 tests passed. I’ll monitor the PR and remove the three resources after it merges.

The same lifecycle can be scripted with the CLI:

# Deploy the branch as an isolated web service.
render services create \
  --name pr-482-api \
  --type web_service \
  --repo https://github.com/acme/example-app \
  --branch feature/checkout \
  --runtime node \
  --build-command "npm ci && npm run build" \
  --start-command "npm start" \
  --plan starter \
  --output json

# Remove the environment after the PR merges.
render services delete pr-482-api --confirm
render pg delete pr-482-db --confirm
render kv delete pr-482-cache --confirm

Disposable environments are just one example. These capabilities also support deployment debugging, scheduled data operations, automated recovery, and service-plan changes based on live metrics.

Get started

Visit render.com/agents to install Render for Cursor, Claude Code, Claude Desktop, Codex, or ChatGPT. You’ll get setup instructions for the hosted MCP server and access to Render skills for your tool.

What’s next

We’re continuing to make Render a platform where agents can move beyond writing code and help operate the software they build.

Next, we’re working on granular, scoped access for agents along with policy and guardrails that let you define exactly what an agent is allowed to do.

Coding agents are pretty good at writing code. But without the right tools and guardrails, they can still struggle with deploying that code, querying a database, and operating your infrastructure.

Render is closing that gap. We’ve just shipped several updates that expand what your coding agent can do. You’ll also find faster builds, stronger security, and more control over your data.

Build with agents

Connect to Render's MCP server with OAuth

You can now sign in to Render's MCP server from your browser instead of using a personal API key. API-key authentication remains available for other tools and non-interactive environments.

Connect to Render's MCP server →

Deploy and troubleshoot through MCP

Render's MCP server can create services, query Render Postgres databases, inspect logs and metrics, trigger deploys, and clear the build cache. Your coding agent can use these actions to move from setup through troubleshooting without leaving its workflow.

See supported MCP actions →

Manage more infrastructure with the Render CLI

The Render CLI can manage services, Render Postgres databases, and Render Key Value instances. It can also return JSON or YAML, which makes its output easier to use in scripts and agent workflows. Explore the Render CLI →

Give your coding agent Render-specific skills

Render now offers more than 20 official skills for Claude Code, Cursor, and Codex. They give coding agents Render-specific guidance for deploying, configuring, debugging, monitoring, and scaling your applications.

Add Render skills to your coding agent →

Build faster

Faster Docker and Node.js builds

Median Dockerfile build times have dropped by about 60%, from roughly 80 seconds to 30 seconds. Median Node.js native-runtime build times have dropped by about 25%, from roughly 40 seconds to 30 seconds.

Start an ephemeral SSH instance

You can start a short-lived instance of your service to inspect its runtime or run one-off commands without connecting to production. The instance uses the same build as your service, then shuts down when you exit the shell.

Start an ephemeral shell instance →

Build safely

Use short-lived credentials with Anthropic, OpenAI, and AWS

Pro workspaces and higher can use OpenID Connect (OIDC) to authenticate Render services with Anthropic, OpenAI, and AWS. OIDC replaces long-lived provider credentials with short-lived tokens that rotate automatically.

Configure OIDC on Render →

Connect more identity providers through SCIM

Render now supports more standard SCIM fields, reducing setup failures and synchronization loops with identity providers. SCIM is available for Scale workspaces and higher.

Set up SCIM member management →

Stream logs to Coralogix

You can stream workspace logs to Coralogix for centralized analysis and alerting alongside the rest of your observability data.

Send Render logs to Coralogix →

Build with more control

Choose how Render Key Value persists data

Paid Render Key Value instances now support three persistence modes: Journal and Snapshot, Snapshot only, and Off. You can choose the mode that best balances data durability and write performance for your workload.

Choose a persistence mode →

Add connection pooling to Render Postgres

Paid Render Postgres databases include managed PgBouncer at no additional cost. Connection pooling helps your database support more clients without requiring you to operate a separate pooler. Configure Render Postgres connection pooling →

Use wal2json and pg_repack

Render Postgres supports the wal2json extension for JSON logical decoding and the pg_repack extension for removing table and index bloat with minimal locking. Manage Render Postgres extensions →

More for agent builders

Deploy Nanobot

Nanobot is a lightweight, self-hostable agent with a browser chat interface, tools, and persistent memory. You can now deploy it to Render directly from the Nanobot GitHub repo.

Deploy Nanobot →

Build reliable infrastructure for agents

Learn how queues, safe retries, and durable workflows help agents preserve progress and recover from failures.

Read the infrastructure guide →

Watch the 2026 keynote

Watch Anurag Goel’s keynote on AI agents, application-defined compute, and what’s next for building in the cloud.

Watch the keynote →

When we launched Render Workflows in beta, we expected to learn and adjust. Your feedback showed that pricing was too high for many workloads, and workspace-wide concurrency limits made it hard to scale.

On September 1, as part of making Workflows generally available, we're updating our pricing to address that feedback. We’re introducing a new workflow-specific compute plan, Flex, that bills only for the resources your tasks actively use. We’re also replacing the workspace-wide concurrency limit with dramatically higher per-workflow resource limits and introducing billing for temporary task state retention.

Based on our data, the vast majority of workloads will cost less under the new model.

Pricing based on active compute

A new workflow-specific compute plan, Flex, will replace both Starter and Standard. The Flex plan will provide up to 1 CPU and 4 GB RAM per task (double the RAM of Standard), and will bill only for the resources your task actively uses:

• $0.20 per active CPU-hour
• $0.05 per active GB-hour

Each task run will be billed at a minimum of just one second at 0.1 CPU and 0.1 GB RAM.

Tasks that spend significant time waiting on LLMs or external APIs should cost up to 70% less under Flex.

Larger compute plans (Pro and higher) will remain available and keep their fixed billing model. We’re also adding a 2 CPU / 8 GB plan and lowering prices for the existing Pro Max (4 CPU / 16 GB) and Pro Ultra (8 CPU / 32 GB) plans.

Per-workflow concurrency with dramatically higher limits

Per-workflow resource limits will replace the current workspace-wide concurrency limit. This means your different workflows will no longer compete over a shared resource pool.

With a Pro workspace or higher, a workflow can add up to 32 CPU and 128 GB RAM per minute (16 CPU / 64 GB with a Hobby workspace). All of a single workflow’s concurrent task runs can use up to a total of 10,000 CPU and 40,000 GB of RAM.

If you currently pay for a concurrency add-on, we’ll remove it automatically on September 1, and you won’t be charged for it going forward. For teams running more than one workflow service, the new model makes it easier to isolate workloads and scale them independently.

Billing for task state retention

The input arguments and return values of your workflow tasks are temporarily retained to help you retry or debug the run. We will begin billing for this task state retention at a monthly rate of $0.25 per GB.

What happens next

If you currently use Workflows, no action is required at this time. On September 1, workflow tasks that run on the Starter or Standard compute plans will automatically move to Flex, and your September invoice will reflect these changes.

If you have questions about how the pricing changes apply to your workloads, you can reach out to Render Support at any time.

Thank you for helping shape Render Workflows during beta. Your feedback directly informed these changes, and we’re excited to continue building with you as Workflows enters general availability.

Render service builds now run on nodes with faster CPU and disk. These improvements have reduced the median build time for a Render service by 40%, with this reduction reflected across all runtimes:

Before this rollout (week of July 13), median build time was 38 seconds, consistent with prior weeks. Since July 27 (the first full week post-rollout), the highest observed weekly median is 21 seconds, a conservative 40% reduction. Build times remain in this range.

This global build improvement follows recent single-runtime improvements for Node.js, Python, and Docker.

Render’s managed OpenID Connect (OIDC) authentication now supports Anthropic and OpenAI in addition to AWS.

Render services can authenticate to both providers without storing long-lived API keys. Render instead issues short-lived identity tokens for each service and automatically rotates them as needed.

To configure either provider, connect Render as an identity provider, map the appropriate service account, and add the required environment variables to your Render service. After you redeploy, Render automatically makes the service’s OIDC token available at runtime.

Managed OIDC requires a Pro workspace or higher. Get started in the documentation.