Render Updates & Release Notes

We recently launched OIDC support for third-party service providers such as AWS, GCP, OpenAI, and Anthropic. OIDC is a neat feature which lets your services authenticate to these service providers without needing to generate sensitive API tokens. Instead, you simply set a few environment variables on any Render service, and suddenly that service can authenticate to the service provider. It Just Works™!

This makes it easier to connect your services, and it’s much more secure than generating long-lived API tokens. But beneath the surface of that simplicity lies deceptively complex machinery to make this feature happen. Let’s open up this clock and see how it ticks!

What OIDC actually means

When you use OIDC to access a service provider, your Render service authenticates with them by sending a Render-generated OIDC token. This token is a plain old JSON blob that contains relevant information about your service, such as its ID and the environment it’s running in:

{
  # Timestamp when the token was issued
  "iat": 1784065787,
  # Timestamp when the token expires
  "exp": 1784069387,
  # The ID of the service
  , # as well as the workspace and environment it's running in
  "sub": "workspace:tea-yourworkspaceid:environment:evm-yourenvironmentid:service:srv-yourserviceid",
  # Who signed the token (Render)
  "iss": "https://oidc.render.com/tea-yourworkspaceid",
  # Who the the token is meant for (in this case, AWS)
  "aud": "sts.amazonaws.com"
}

This token is cryptographically signed to prevent it from being edited or faked. You can configure the external service provider (e.g. AWS) to accept these tokens by providing them a link to Render’s validation keys, which can be used to validate the token’s signature.

Each field in that blob is called a claim. Claims each have a different role in keeping the token secure. Let's take a look!

OIDC is a limited-time offer

The issued-at (iat) and expiration (exp) claims are the easiest to understand. Each token Render signs expires 60 minutes after issuance, at which point the service provider no longer accepts it. In the unlikely event that a token is leaked or stolen, it becomes worthless within an hour. No rotation needed!

This 60-minute window carefully straddles a line between security and usability. If tokens expire faster, leaking one is less dangerous. But shorter tokens also increases the impact of a service outage: if Render is unable to issue new tokens for any reason, this expiration time becomes the deadline when connections start to fail. We never expect one of these service outages to occur, but part of ensuring our platform’s reliability is to be ready for the unexpected. One hour is a solid middle ground: it greatly limits the damage an attacker can do with the token, while providing enough buffer room to recover gracefully if an incident ever occurs.

Who are you, anyway?

The subject (sub) claim is the most important, because it’s what actually identifies your Render service to the service provider. Take AWS, for example: each AWS IAM role has a “Trust Relationship” policy that defines who is and isn’t allowed to assume that role, and those policies can restrict access to specific Render services based on this claim.

This claim can be any kind of identifier, so the simplest solution is to set it to the ID of the Render service. But by also including environment and workspace IDs in this string, users can grant one role to multiple Render services with a single Trust Relationship. For example, users can specify an environment but set the service ID to a wildcard, allowing any service in that environment to assume the role:

"StringLike": {
  "oidc.render.com/tea-yourworkspaceid:sub": "workspace:tea-yourworkspaceid:environment:evm-yourenvid:service:*"
}

With other combinations of wildcards, you could grant access to the whole workspace or limit it to a single service. Or not limit it to any subject at all! Which brings us to the next claim…

Tidying up the foot-guns

The issuer claim (iss) specifies who signed the token. In the example above, this is https://oidc.render.com/tea-yourworkspaceid.

This issuer represents the identity provider who creates OIDC tokens. That URL hosts the public keys used to validate those tokens. You specify this URL when you configure a service provider like AWS, which ensures that they only trust tokens which were authentically issued by Render. Every time that service provider receives a token, they will pull the public keys from this issuer URL and make sure they match. We host our public validation keys at oidc.render.com, so it makes sense that the issuer URL includes that.

But why does the path also include the workspace ID?

That’s is actually a safeguard against service provider misconfigurations. When our users configure a service provider to trust Render, we have no control over how much access they grant, or which service IDs they grant that access to. Some of our users may want to configure a role that doesn’t check the subject claim at all, which would allow any service to assume the role. It’s not the most secure configuration, but there are cases where it makes sense.

But there's a problem: when we say that “any service” can assume the role, we don’t just mean “any service in the user’s workspace”; we mean any service owned by any Render customer! Of course, we try to be as clear as possible that our users should never configure their service providers this way. But mistakes happen, and we don’t want our users’ safety to hinge on an optional validation step.

This is where the issuer comes into play: by including the workspace ID in the URL, service providers treat each workspace as a unique identity provider. OIDC tokens issued by one workspace are not accepted by other workspaces. Under the hood each issuer URL is functionally identical (they even host the same public keys), but from AWS’s perspective they are entirely separate. This means that even if users disable all validation of these tokens, the service provider will still only accept tokens issued to the user’s own workspace.

This does have one downside, which is that users with multiple Render workspaces need to configure AWS to trust each one individually. However, most of our customers only have one or two workspaces so this is rarely a problem in practice.

Know your audience

Finally, there’s the audience (aud) claim. The audience identifies who should receive the token, so in the case of AWS it’s sts.amazonaws.com. At first glance, this seems redundant: of course the recipient of the token already knows who they are! This field doesn’t tell AWS anything which they didn’t already know. But this claim is used to prevent a notable problem inherent to OIDC, which occurs when multiple service providers are involved.

Let’s say you use one OIDC token to authenticate to both AWS and a second service provider called HackerCorp. This one OIDC token can be used access to any service provider who trusts it, so if you send the token to HackerCorp, they could turn right around and present it to AWS to pretend to be you!

OIDC solves this with the “audience” claim: each token specifies which service provider is intended to receive it, and a provider rejects any token whose audience isn't itself. Render sets the audience in these OIDC to be sts.amazonaws.com, and when you configure AWS to add Render as a trusted identity provider, you need to specify what this audience will be. We set these audiences automatically based on the service provider, so we can ensure that two tokens never have the same audience. If Render ever adds HackerCorp as a provider (don’t worry, we won’t), we would give its token a brand new audience (say, get.hacked.com) so if they tried to reuse the token with AWS it would get rejected.

Looking under the hood

Generating these tokens is easy, we just need to construct this JSON blob and generate the cryptographic signature. The hard part is making them available to your Render service. This is trickier than it seems, because we don’t know when your service needs to authenticate with AWS, or how long it maintains that access. Any time your service might need an OIDC token, we need to have one ready. And each token only lasts an hour, so we need some way to replace expired tokens with fresh ones.

We could require the user’s application to handle this complexity, but the magic of Render lies in the fact that everything works right out of the box.

Worrying about key fetching and rotation should be our concern, not yours. Thankfully, all of the service providers we integrate with offer some kind of SDK or command-line tool which we can configure on behalf of our users. For example, we can configure the AWS SDK without needing a single line of code, by setting specific environment variables.

Wrangling the SDKs

In a perfect world, we would configure the various service provider SDK to request a token from a URL whenever it needs a new one. This keeps the implementation simple, as we could spin up an internal service endpoint, a unix socket, or whatever else makes sense for our architecture, and let the SDK determine when it needs us to provision a new token OIDC tokens. There’s just one problem: nobody supports it.

The AWS SDK can be configured to fetch credentials from an endpoint with the AWS_CONTAINER_CREDENTIALS_FULL_URI environment variable, but that mechanism wasn't built for third-party providers like us, its exact behavior is undocumented, and it acts differently depending on the client language and SDK version. In some cases it only allows the specific IP addresses used internally by Amazon EKS. Even if it did work nicely with our system, there aren’t analogous configuration options for other OIDC service providers.

Instead, the most common denominator among most of the popular SDKs is that they expect to read the OIDC token from a file on the disk. There’s no way to tell if or when the SDK will read this file, so it needs to exist at all times just in case the service needs it to authenticate. The exact file file is usually configurable through an environment variable, such as the AWS_WEB_IDENTITY_TOKEN_FILE setting for AWS, but that’s the most we can configure it.

Introducing: the OIDC Daemon

Even getting a file onto the disk is hard. Each service instance runs in its own containerized environment, and we don’t run any Render agents or other code alongside them which can access the filesystem. The keys are specific to each service and they need to be refreshed every few minutes, so we can’t bake them into the filesystem. We even allow services to run using custom images which we don’t control, so we can’t guarantee we’ll have any code inside the runtime environment.

Instead, we have to work from outside the environment. We've started running a service outside of each runtime container called the OIDC Daemon: This simple program has the ability to generate and sign OIDC tokens, but not much else.

Whenever a new service instance starts up and requires OIDC tokens, we initialize it with a read-only bind mount#Bind_mounting) between /var/lib/render/oidc/ inside the container, and a directory inside /dev/shm on the underlying host. The OIDC Daemon also has a bind mount to this same directory, which allows the Daemon to write files to that one specific path without having any additional access to the service. The /dev/shm directory is backed by a virtual in-memory filesystem, so none of the files it writes are ever actually persisted to the disk.

If a Render service needs OIDC tokens, the Daemon writes all of those tokens to the shared directory before the service ever starts. Because the token will expire within an hour, the Daemon keeps watching the files and updates them periodically.

For every OIDC token we set, we also configure the environment to pick these files up automatically. Each provider is configured in different ways, for example AWS only needs a single AWS_WEB_IDENTITY_TOKEN_FILE environment variable, while GCP requires us to write a custom credential configuration file to the disk.

Try it yourself (it’s easy!)

The benefit of all this internal machinery is a frictionless user experience: our users simply tell us which service provider they want access to, and we handle the rest. No copying API keys or configuring secret managers. It’s rare for the easiest option to also be the most secure one, so it’s very satisfying to have the ability to do both.

If you want to see this in action, the docs walk through setting up OIDC for your own services. It only takes a few minutes to configure, and you can stop worrying about your API keys forever!

At Render we spend our time figuring out how to turn hard infrastructure problems into simple features for millions of builders. If this kind of work sounds interesting to you, we're hiring.

Today we’re launching Render Sandboxes in public beta. Render Sandboxes let you safely give your agents a computer to work with: a fully isolated Linux environment where they can install dependencies, edit files, and run code.

Each sandbox starts quickly, runs indefinitely, and automatically suspends when idle. You can reliably run thousands at once and lock down what each one can reach. You’re billed for CPU only when your agents are actually using it.

Render Sandboxes work with any agent harness and model. You can operate sandboxes through the TypeScript or Python SDK, or the Render CLI.

Check out our quickstart, or share this prompt with your coding agent:

Follow the quickstart at https://render.com/docs/sandboxes to run my first Render sandbox. Show me the output, and terminate the sandbox when you’re done.

Agents need a computer of their own

Agents doing complex work need a separate machine for each task or user, isolated from your app and from each other. And since agent work comes in bursts, those machines need to start and stop with demand.

A web service isn’t built for this. Its instances stay up and serve all your users, and a new deploy can take minutes.

Render Sandboxes give each user or task its own machine the moment it’s needed. Each sandbox runs in its own Firecracker microVM.

“We’ve long been fans of Render because it enables us to move fast, and Render Sandboxes have kept that promise. Sandboxes are the runtime for the agents in our software factory, and they let our customers securely run custom code on our platform. All in, setting up Sandboxes was fast and easy, which meant less time solving infrastructure challenges and more time solving customer problems.

Built to handle long-running work

Render Sandboxes can run indefinitely, so an agent on a multi-day task like a codebase migration keeps its running app, processes, and memory the whole time.

Each sandbox starts from an image: Render’s default, or a custom image that already includes your agent harness, dependencies, and configuration. From there, two types of snapshots can capture its progress:

• A filesystem snapshot saves files and installed tools. Use it to skip setup on new sandboxes, or to carry an agent’s notes from one session to the next.
• A runtime snapshot (the default) also saves memory and running processes, so your agent picks up mid-task instead of reloading its state from disk. This can make startup 3x to 10x faster.

By default, when a sandbox idles without a command, Render automatically snapshots and suspends it, and then wakes it back up on the next command. Importantly, you don’t pay for CPU or memory while a sandbox is suspended. (The default idle timeout of 15 minutes is configurable, and auto-suspend is optional.)

With the TypeScript and Python SDKs, you can also snapshot a sandbox yourself and restore it in a new one later.

Keep each sandbox secure

Agents often need network access and API keys to do useful work. Render Sandboxes let you grant them both, while controlling where each sandbox can send data and the keys it can see. This helps protect against situations such as an agent falling for a prompt injection attack, or unknowingly running malicious code.

Each sandbox has its own outbound network policy: allow all traffic, allow only a list of domains, or block outbound traffic entirely.

Render Sandboxes also support credential brokering, which keeps your API keys out of the sandbox entirely. Code inside the sandbox sends requests without credentials, and a broker outside the sandbox safely adds the right key or token as each request leaves for an allowed domain. This means a prompt injection attack can’t result in leaked keys.

You can also create scoped API keys with only the permissions a task needs, like managing sandboxes without access to your other services. That means you don't need to worry about (for instance) your agent mistakenly deleting your database because it can manage sandboxes.

Credential brokering and scoped API keys are currently in early access and are being rolled out to more customers. To request access, fill out the credential brokering form and/or the scoped API keys form.

Pay for the CPU your agent actually uses

A running sandbox is billed for actively-used CPU (not simply provisioned CPU), as well as memory allocated to it. That means waiting on a model or a person doesn’t cost you CPU time.

Once a sandbox is suspended, the memory charge stops too, and you pay only for its snapshot storage.

Render Sandboxes are available in Oregon on all workspace plans. See the pricing page for more.

Scale reliably from one sandbox to thousands

While sandboxes are new to Render, reliably spinning up isolated environments on demand is not. Render already does this for every build, more than one million times a day.

Drawing on that experience, we built Render Sandboxes to hold up whether you run one sandbox or thousands. Each one is typically ready for its first command in under one second; even faster when it’s restored from a snapshot. Expect startup time to improve through the beta.

Your sandboxes run next to the rest of your app

Your sandboxes live in the same Render workspace as the web services, background workers, and databases that make up the rest of your app. You manage them with Render API keys, through the Render CLI or the same SDK you’d use for Render Workflows, and they’re billed alongside your other Render services. There’s no extra provider to manage.

Inside a sandbox, agents can use Docker and Docker Compose to start a copy of your app and its database side by side, then test their changes before you deploy.

Render Sandboxes also pair well with Render Workflows. You can use Workflows for the steps that should happen the same way every time, like fetching inputs, calling a model, and saving the output. Sandboxes are best suited to the non-deterministic part, where the agent decides what to do next and needs its state to carry over between runs.

Get started

To try Render Sandboxes in code, install the TypeScript SDK with npm install @renderinc/sdk or the Python SDK with pip install render, set RENDER_API_KEY and RENDER_WORKSPACE_ID in your app's environment, and run your first command in a sandbox.

Or start with your coding agent:

• Install the Render Sandboxes skill.
• Have your agent build from a template: a software factory, a vibe-coding app, or a support engineering triage agent.

For the full SDK and CLI reference, see the Sandboxes docs. To run Claude Managed Agents, Cursor Cloud Agents, or the OpenAI Agents API in a sandbox, follow our setup guides.

What's next

Render Sandboxes are in public beta today. On the way to general availability, we're working on:

• Private networking, so sandboxes can reach the rest of your Render services without going over the public internet.
• More regions beyond Oregon.
• SSH access and public URLs, so you can work inside a running sandbox and open the app an agent started from your browser.
• CPU and memory bursting, so a sandbox can temporarily use more resources for heavy work without moving to a larger size.
• Shared Filesystems are also coming soon. A Shared Filesystem gives your sandboxes and workflow tasks the same persistent files, so parallel agents can read shared inputs, write their own outputs, and build on each other's work. Files stay put after the compute that used them shuts down. Request early access.

As agents become part of more products, giving each one a computer should be the easy part. We’re excited to see what this helps you build.

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.

Give every integration only the API access it needs.

API keys make it easy to automate work on Render. But when a key inherits its creator’s full permissions, a credential created for one task can carry more access than that task requires.

We're launching Scoped API Keys so you can choose which Render API actions a key can perform, limited to permissions you already have. This gives CI jobs, internal tools, agents, and other integrations a more controlled way to act on Render while reducing the potential blast radius of a compromised key.

Scoped API Keys are currently in private beta; to request access, fill out this form.

Permissions that fit the job

A key’s effective access is limited by both the scopes you select and your own permissions—it can never exceed the permissions you already have. You can review and update a key’s scopes as your needs change.

This is useful for integrations and automation, including MCP integrations and CLI workflows that use Render API keys. For example:

• Infrastructure monitoring agents: Give an agent access to logs, metrics, and service health without allowing it to deploy code or modify infrastructure.
• Security and compliance integrations: Let a team pull Render audit logs into its SIEM without granting access to change services or configuration.
• CI/CD pipelines: Allow an automation to trigger deployments without giving it permission to modify service settings or access secrets.

We designed the setup flow to make least-privilege access easy to configure. Choose a workspace and set access levels for the resource types your key needs, with access to secrets controlled separately.

For details on supported capabilities and limitations during private beta, see the documentation.

How to join private beta

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

Once approved, you’ll:

• Work directly with the Render Engineering team as you implement Scoped API Keys and share feedback
• Get early visibility into related features as they’re introduced during private beta

Your use case and feedback will help shape Scoped API Keys as we work toward general availability.

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.