Changelog

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

Expand errors, open lines in detail view, toggle live tail mode, and more.

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

Traverse long log histories with infinite scroll.

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

You can now integrate your Render workspace with Jules—Google Labs' asynchronous coding agent—to autonomously debug your Render builds.

To configure the integration, create an API key in the Render Dashboard (dashboard.render.com/jules) and paste it into the appropriate field on the Jules integrations page:

Adding your Render API key to Jules

With the integration enabled, Jules monitors pull request previews on your service repos and asynchronously plans and commits fixes for build failures.

Learn more in the documentation.

Newly created services now use Bun 1.3.4 by default. You can always specify a different version.

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

Render Postgres databases now support self-serve credential rotation via managed creation and deletion of PostgreSQL users.

Add and delete users from your database's page in the Render Dashboard, or via the Render API:

Creating a new managed PostgreSQL user in the Render Dashboard

A newly created user becomes your database's new "default" user, used in the database's connection URLs shown in the Render Dashboard. Blueprint-managed services that dynamically reference your database's connection string will update to use the new default credentials on your next Blueprint sync.

Learn more about PostgreSQL users and credential rotations in the documentation.

The following webhook event types now include a status field in their payload, enabling you to quickly respond to the result of the corresponding action:

• Build Ended
• Deploy Ended
• Cron Job Run Ended
• Job Run Ended (for one-off jobs)

For a completed action, this field's value is one of succeeded, failed, or canceled. You can use this value in CI to terminate a workflow if a build or deploy fails.

Additionally, the Server Unhealthy event type has been removed in favor of Server Failed, which surfaces runtime failures for your service with significantly less "notification noise".

Learn more about webhooks in the documentation.

Render Postgres databases now support PostgreSQL version 18. This is now the default version for newly created databases (you can specify a different version at creation time).

You can upgrade an existing database in-place from its Info page in the Render Dashboard:

Upgrading a Render Postgres database in the Render Dashboard

Note that your database will be temporarily unavailable during the upgrade. The process usually takes less than one hour.

Learn more about PostgreSQL 18 in the release notes. Learn more about database upgrades in the documentation.

As announced in September, Render is now in the process of moving all outbound traffic to use the new IP ranges introduced on October 27th:

Original outbound IPs and new ranges for the Ohio region

Each region has its own set of new ranges and original IPs. As part of this change, outbound traffic will no longer use the original IPs. These IPs will be retired fully by December 1st.

As of today, this switchover is complete for the following regions:

• Ohio
• Virginia
• Singapore

The Oregon region is scheduled for November 10, and Frankfurt has yet to be scheduled. Subscribe to Render's status page for future updates.

If you use outbound IPs to allow access to an external system, you must add the new IP ranges to that system's access rules. You can safely remove all of the original IPs from your access rules starting December 1st.

Learn more about outbound IPs in the documentation.

You can now enable storage autoscaling for Render Postgres databases. When enabled, Render detects when your database is over 90% full and automatically increases its storage by 50% (rounded up to the nearest multiple of 5 GB).

For example, a 50 GB database that's using over 45 GB will automatically increase its storage to 75 GB. This increase is permanent.

Enable storage autoscaling with the following steps:

1. From your database's Info page in the Render Dashboard, scroll down to the Postgres Instance section and click Update.
2. Scroll down to the Enable Storage Autoscaling field and toggle the switch.
3. Click Save Changes.

Learn more about storage autoscaling in the documentation.

Blueprints (Render's infrastructure-as-code model) now enable you to define projects and environments in your workspace, and to assign resources to those environments:

Defining a project with two environments using Render Blueprints

Your render.yaml file now supports two new top-level fields:

• projects: an array of project definitions, each with one or more environments and their associated resources
• ungrouped: an object for defining resources that belong to no environment

If you define a resource under one of these new fields, do not duplicate it in your file's top-level services / databases / envVarGroups fields. These fields remain supported, and resources in them keep their currently assigned environment (if any).

Learn more about Blueprint support for projects and environments in the documentation.

Edge caching for web services now includes the option to cache response data for all file types—not just for a predefined list of common static file types (like images and PDFs).

You choose which set of Cacheable File Types to allow when you enable edge caching:

Enabling edge caching for all file types in the Render Dashboard

Caching all file types increases the risk of caching dynamic content. To prevent this, make sure to set proper Cache-Control headers for all of your service's dynamic responses before enabling this option.

Learn more about edge caching in the documentation.

Enterprise orgs on Render can now set inbound IP rules for the following:

• Individual web services and static sites
• An entire environment
• An entire workspace

IP rules are allowlists of IP ranges specified using CIDR notation. Add rules from your service or environment's settings in the Render Dashboard:

Setting a web service's inbound IP rules in the Render Dashboard

Requests to your service from a disallowed IP receive a 403 Forbidden response.

All plan types support setting inbound IP rules for individual Render Postgres and Key Value datastores (this is existing functionality).

Learn more about IP rules in the documentation.

To assist with compliance needs, the Render API now provides the following endpoints for exporting audit log data:

• List workspace audit logs
  • Includes user actions performed in an individual workspace, such as management of services and datastores.
• List organization audit logs
  • Includes org-level management actions, such as configuring SAML SSO. These audit logs are exclusive to Enterprise orgs.

Audit logs require an Organization plan or higher. Learn more about audit logs in the documentation.

On October 27, 2025, Render will roll out new outbound IP ranges for each region. Render will also retire each region's original set of outbound IPs no later than December 1, 2025.

Viewing new outbound IP ranges in the Render Dashboard

If you use your service's outbound IPs to safelist access to an external system, you will need to add the new IP ranges to that system's access rules. You can safely do this now in preparation for the change by following these steps.

Learn more about outbound IPs in the documentation.

Starting next week, free Render web services will block outbound network traffic to SMTP ports 25, 465, and 587.

This change will be live across all regions by Friday, September 26th.

To continue sending traffic to an SMTP port, you can upgrade your free web service to any paid instance type.

Learn more about free service limitations in the documentation.

You can now open a shell session to a specific instance of a scaled service. Previously, shell sessions always selected an instance at random.

• In the Render Dashboard, open a service's Shell page and select a specific instance from the Instance dropdown:
  

Selecting an instance in the dashboard shell

• When connecting over SSH, include an instance's 5-character slug in the hostname. Here's an example command:
  
  ssh srv-abc123-d4e5f@ssh.oregon.render.com
  
  In this example, the instance slug is d4e5f. You append this value to the service ID, separated by a hyphen as shown.

You can obtain the slug of a running instance from your service's logs and metrics in the Render Dashboard. You can also open a dashboard shell session to a particular instance directly from these views:

Opening a dashboard shell session from the log explorer

Opening a dashboard shell session from service metrics

Learn more about SSH support in the documentation.

Similar to other service types, you can now suspend Render Key Value instances in the Render Dashboard. At the bottom of your instance's Info page, click Suspend Key Value Instance:

Suspending a Key Value instance in the Render Dashboard

You can also include Key Value instances in newly supported bulk suspend actions.

Paid Key Value instances include disk-backed persistence, and they retain their state on disk while suspended. Free Key Value instances do not include persistence, and their state is lost upon suspension.

You can now suspend multiple services at the same time in the Render Dashboard. Click the checkbox next to each service you want to suspend, then click Suspend in the action menu that appears:

Suspending multiple services in the Render Dashboard

You can resume multiple suspended services the same way by clicking Resume in the action menu:

Resuming multiple suspended services in the Render Dashboard

The official Render MCP server is now generally available. By connecting AI applications like Cursor and Claude Code, you can manage and inspect your Render infrastructure using natural language:

Analyzing service metrics in Cursor with the Render MCP server

Connect your AI app to the official hosted server at https://mcp.render.com/mcp to automatically benefit from new capabilities as they're released (see setup instructions). You can also run the server locally.

Supported tasks include:

• Fetching and analyzing service metrics (new with this release)
• Creating web services, static sites, and datastores
• Fetching and filtering service logs
• Listing a service’s deploy history
• Querying a Render Postgres database

Learn more in the documentation.

Newly created services now use Bun 1.2.20 by default. You can always specify a different version.

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

You can now enable edge caching for any paid web service in the Render Dashboard. Backed by a global CDN, edge caching dramatically speeds up response times when serving most types of static assets (images, documents, audio, and more):

Diagram illustrating edge caching for web services

In a simple curl test, enabling edge caching reduced the average wall-clock response time for the same image file by over 40%.

Edge caching is available for all paid web services at no additional charge. Enable it from your web service's Settings page in the Render Dashboard:

Enabling edge caching in the Render Dashboard

Learn how to configure your web service's edge caching behavior in the documentation.

Two new workspace member roles are now available for advanced plan types:

• Contributor (Organization and Enterprise plans) — Has similar permissions to the existing Developer role, with the following additional restrictions:
  • Can't view sensitive fields (such as connection strings and environment variables).
  • Can't access running services via SSH or the Shell tab in the Render Dashboard.
  • Can't create, modify, or delete most workspace resources.
• Viewer (Enterprise plans only) — Has read-only access to resources in the workspace, except for sensitive fields (such as connection strings and environment variables).

Workspace admins can assign roles to other members in the Render Dashboard. Learn more about member roles in the documentation.

Render Postgres databases now support PostgreSQL version 17. This is now the default version for newly created databases (you can specify a different version at creation time).

You can upgrade an existing database in-place from its Info page in the Render Dashboard:

Upgrading a Render Postgres database in the Render Dashboard

Note that your database will be temporarily unavailable during the upgrade. The process usually takes less than one hour.

Learn more about PostgreSQL 17 in the release notes. Learn more about database upgrades in the documentation.

Service metrics in the Render Dashboard now highlight service events that occurred during the selected time frame:

Service events in Render Dashboard service metrics

By viewing metrics and events together, you can quickly pinpoint the underlying cause of performance changes in your service.

By default, graphs display events related to service deploys and instance failures. Use the Filter events dropdown to select from a wide variety of additional event types:

Selecting service events to display in metrics

Click any event in a metrics graph to view more details about it.

Learn more about service metrics in the documentation.

Coming to early access, paid web services will support edge caching for static content (text files, images, audio, and so on). By serving cached assets directly from Render's global CDN (similar to static sites), you can shorten your web service's response times and reduce load:

A diagram depicting edge caching for web services

To apply for early access, please upvote the feature request at feedback.render.com. We'll gradually roll out early access to requesting workspaces over the coming weeks.

After early access is enabled for your workspace, you'll be able to enable edge caching for a web service from its Settings page in the Render Dashboard.

For preliminary details on edge caching, see the documentation.

Some workspaces created before January 1, 2023 currently support sharing individual services with Render users outside the workspace:

The legacy sharing UI in the Render Dashboard (only visible to specific workspaces)

This legacy sharing method is now deprecated. Future platform changes might disrupt access granted by this method. There is currently no scheduled date for end-of-life.

Collaboration remains central to the Render platform. If you currently use this sharing method, you can add affected users to your workspace and assign them appropriate roles.

Starting 2025-07-14, newly created workspaces set their default overlapping deploy policy to Wait instead of Override. This policy determines how your services handle newly triggered deploys if a deploy is already in progress:

• Wait: Allow the in-progress deploy to finish, then proceed directly to the most recently triggered deploy (skipping any in between).
• Override: Immediately cancel the in-progress deploy and start the new one.

For most use cases, the Wait policy helps your workspace maintain a steady cadence of deploys during periods of high change volume.

Existing workspaces keep their current policy setting. Learn more about overlapping deploys in the documentation.

Professional workspaces and higher can now create private links directly in the Render Dashboard:

Creating a private link in the Render Dashboard

Private links enable your Render services to securely connect to AWS-hosted cloud services:

Diagram depicting private link communication

Use a private link to access compatible services like Snowflake, MongoDB Atlas, or resources in your own VPC. Each workspace can have up to 3 private links.

• See pricing details for private links.
• For setup instructions, see the documentation.

On August 1, 2025, we're making the following changes to how we charge for bandwidth:

• Lower bandwidth pricing: Bandwidth pricing will decrease from $30 per 100GB to $15 per 100 GB. We will continue to only charge for bandwidth usage above your workspace plan's included amount. If you don’t exceed the bandwidth already included in your plan, these changes won't affect your bill.
• Accurate bandwidth billing: Currently, bandwidth usage only includes HTTP responses sent from your web services and static sites to browsers and other clients over the public Internet. We are correcting this behavior to align with industry standards. Outbound bandwidth will now include the following in addition to HTTP responses:
  • Service-initiated outbound traffic: Network communication initiated by any of your Render services over the public Internet (e.g., calls to an external database or uploads to a public cloud storage service)
  • Service-initiated Private Link traffic: Same as the above, but over a Private Link connection
  • WebSocket Responses: WebSocket responses sent from your web services to browsers and other clients over the public Internet

This update brings our pricing model in line with industry norms and helps us accurately reflect real infrastructure usage.

99% of workspaces will see lower or unchanged bandwidth costs.

Learn more about these changes in the documentation.

The official Render MCP server is now hosted at the following URL:

https://mcp.render.com/mcp

This hosted server will automatically update over time to reflect the latest release. Like the underlying project, the hosted server is in early access.

Apps that support streamable HTTP communication with an MCP server (such as Cursor) can now connect directly to Render's hosted server instead of running a local version. See example configuration.

Note that the MCP server does not yet support OAuth, and clients authenticate via an Authorization header. Learn more in the documentation.

Search results in the Render Dashboard now include shortcuts to common settings:

Shortcut search results in the Render Dashboard

Jump directly to your API keys, webhook settings, compliance docs, and more—all with a few keystrokes.

For services that set their auto-deploy behavior to After CI Checks Pass, the following GitHub check conclusions now all count as a passing check:

• success
• neutral
• skipped

Previously, only success counted as a passing check. Conclusions besides those listed above continue to count as a failed check.

Learn more in the documentation.

Use the official Render MCP server to manage your Render infrastructure with natural language in AI-powered apps like Cursor, Windsurf, and Claude:

An MCP-powered prompt response in the Cursor IDE

The MCP server runs on your development machine alongside your AI app. With each prompt, your app intelligently determines whether to use the Render MCP server to perform relevant actions using the Render API:

Diagram illustrating Cursor using a locally running Render MCP server

Supported actions currently include:

• Creating web services, static sites, and datastores
• Fetching and filtering service logs
• Listing a service's deploy history
• Querying a Render Postgres database

Get started with the MCP server in the documentation.

Newly created services on Render's native language runtimes now use the following updated language and library versions by default:

• Python 3.13.4
  • Poetry 2.1.3
  • uv 0.7.12 (new on Render)
• Node.js 22.16.0
• Ruby 3.4.4
• Go 1.24.4
• Elixir 1.18.4

With the exception of Go services, you can always specify a different language version.

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

Render's Python native runtime now supports the uv package manager. To enable uv for your service, include a uv.lock file in your project's root directory. You can then use uv in place of pip for your service's build command and other scripts.

Note that you don't use uv to set your service's Python version.

Render workspaces now support secure, low-latency connections to your other cloud resources via AWS PrivateLink:

Diagram of Render services accessing MongoDB Atlas over AWS PrivateLink

Use a Private Link to access resources like Snowflake, MongoDB Atlas, or Amazon Aurora. Both same-region and cross-region connections are supported.

To request a Private Link for your workspace, please reach out.

Your active Private Links appear under your workspace's Networking page in the Render Dashboard:

Viewing Private Link details in the Render Dashboard

Learn more in the documentation.

Teams with an Organization or Enterprise plan can now enable HIPAA compliance capabilities for their Render workspace. Services in a HIPAA-enabled workspace run on access-restricted hosts, helping to secure any protected health information (PHI) processed or stored by your applications and databases.

Admins can initiate the HIPAA enablement process from the Compliance section of their Workspace Settings page:

Initiating the HIPAA enablement flow in the Render Dashboard

This process includes signing a business associate agreement (BAA), along with performing a restart of all existing services to migrate them to HIPAA-specific hosts.

Before enabling HIPAA capabilities for your workspace, review all important considerations.

Learn more in the documentation.

You can now specify your workspace's overlapping deploy policy from your Workspace Settings page:

Selecting an overlapping deploy policy in the Render Dashboard

Whenever a new deploy is triggered for a service that's already deploying, Render can either:

• Override the in-progress deploy (default), or
• Wait for it to finish, then proceed directly to the most recent triggered deploy (new):

An example deploy flow with overlapping deploy policy set to "Wait"

Choosing Wait helps you maintain a steady shipping cadence during periods of high change volume.

Learn more in the docs.

You can now configure your service to skip its automatic deploy whenever code changes cause your repo's CI checks to fail.

In the Render Dashboard, go to your service's Settings page and set Auto-Deploy to After CI Checks Pass:

Configuring a service's auto-deploy setting in the Render Dashboard

Depending on your Git provider, Render detects CI check results from the following:

• GitHub Actions, along with providers that integrate with the GitHub Checks API
• GitLab CI/CD Pipelines
• Bitbucket Pipelines

Render triggers an auto-deploy only if all detected checks pass.

Learn more in the documentation.

The Render API now includes endpoints for the following capabilities:

• Managing webhooks
• Configuring metrics streaming to your OTel provider
• Listing the members of a workspace

Get started with the Render API in the documentation.

In the Render Dashboard, the Metrics page for a Render Postgres database now includes graphs for the following:

• Disk usage, activity, and operation volume (these metrics are also available for services with an attached persistent disk)
• Memory usage
• Transaction volume
• Network activity
• Lock-delayed queries

Additionally, click the Queries tab on your database's Metrics page to view tables displaying active processes and top queries for the database.

Learn more about service metrics in the documentation.

The log explorer in the Render Dashboard now displays each log line's originating service instance:

The format of a log line in the log explorer

This is helpful for debugging services that are scaled to multiple instances, and for observing instance swaps during a zero-downtime deploy.

Click any line's instance identifier to display only logs from that instance.

Additionally, mouse over the timestamp for a log line to view that same timestamp in UTC and Unix formats:

Multiple timestamp formats in the log explorer

The log explorer is available from your service's Logs page in the Render Dashboard. Learn more about the log explorer—including helpful keyboard shortcuts—in the documentation.

As of 2025-04-22, all newly created Render Key Value instances use Valkey version 8.1. View highlights of this release.

Valkey instances created before this date currently use version 8.0.1. Render will upgrade these instances as part of their next scheduled maintenance.

Learn more about Render Key Value in the documentation.

You can now add up to five read replicas to a Render Postgres database. Previously, each database supported only a single read replica.

This enables you to dramatically increase your volume of database reads without introducing load on your primary instance.

Note the following:

• Each read replica has the same instance type and storage as your primary instance and is billed accordingly.
• Render does not automatically load balance queries across multiple read replicas. Any such load balancing must occur in your application logic.

Learn more about read replicas in the docs.

Workspaces with a Professional plan or higher can create a metrics stream to push OpenTelemetry-formatted service metrics to an observability provider, such as Grafana or Honeycomb.

Render streams metrics related to CPU and memory usage, HTTP requests, and more.

Configuring a metrics stream in the Render Dashboard

Render provides simplified configuration for several popular providers, and you can connect other providers by first routing metrics through your own OTel collector.

In the Render Dashboard, set up a metrics stream from your workspace's Integrations > Observability page. Your provider will start receiving metrics for all services in your workspace besides static sites.

Learn more about setup and reported metric types in the documentation.

Professional workspaces and higher can now configure webhooks for a variety of Render service events. Set up an HTTPS endpoint to receive notifications, then subscribe to any combination of supported event types in the Render Dashboard:

Select from nearly 50 webhook event types.

Receive notifications related to deploys, scaling, datastores, and more.

Use webhooks to trigger custom logic in third-party services, such as posting in a Discord channel or triggering a GitHub Actions workflow.

To get started with webhooks, check out the docs and three example implementations.

SAML single sign-on (SSO) is now generally available for teams with a Render Enterprise plan and a SAML 2.0-compatible identity provider (IdP), such as Okta.

With general availability, Enterprise orgs can now:

• Self-manage domain capture and integration with their IdP
• Enable SCIM-based provisioning and deprovisioning of org members via their IdP

Learn more about Enterprise orgs and SSO in the docs. If you're interested in upgrading to an Enterprise plan, please contact us.

Services on Render's Go native runtime now use Go version 1.24. Existing services that currently use Go 1.23 will upgrade to 1.24 with their next deploy.

Note that this change does not apply to Docker-based services that specify a Go version in their Dockerfile.

Recent improvements to build caching have significantly reduced the median spinup time for Render cron jobs—especially cron jobs that run multiple times per hour.

Previously, each run of a cron job took approximately 20 seconds to spin up in the median case. Now, cron jobs that use the new build caching strategy often spin up in 5 seconds or less.

To take advantage of this speedup, make sure you've triggered at least one new build for your cron job since February 1, 2025. You can manually trigger a build from the cron job's Builds page in the Render Dashboard:

Triggering a manual cron job build in the Render Dashboard

Render Postgres databases now generate logical exports in a directory-based format (.dir.tar.gz) instead of a plain SQL archive (.sql.gz).

You can restore a directory-based export into a local or Render-hosted database using the pg_restore utility, which is included in most standard installations of PostgreSQL itself.

For full restoration instructions, see the documentation.

Render has adopted Valkey in place of Redis® for all newly created Render Key Value instances. Valkey is an open-source key-value store that began as a fork of Redis version 7.2.4. For most applications and frameworks that interact with Redis, Valkey is a drop-in replacement.

Existing Redis instances on Render will continue operating as usual. However, they will no longer receive version updates.

Learn more about this change in the docs.

As of January 6, 2025, Render is officially certified under the EU-US Data Privacy Framework (DPF), along with its UK extension and the Swiss-US DPF.

This certification demonstrates Render's ongoing commitment to compliance with the latest privacy and security regulations. View the details of this certification under Render's entry at dataprivacyframework.gov/list.

See also Render's privacy policy and data processing addendum.

Now in early access, teams with an Enterprise plan can manage access to their Render organization via SAML single sign-on (SSO).

SAML SSO requires an identity provider (IdP) that supports the SAML 2.0 standard, such as Okta.

During the early access period, we'll work with you directly to enable SSO for your organization:

• If you already have an Enterprise plan, please reach out to your Render contact to request SSO.
• If you don't yet have an Enterprise plan, please contact us.

Learn more in the documentation.

Documents related to Render platform security and compliance are now available from the Document Center in the Render Dashboard:

The Document Center in the Render Dashboard

Open the Document Center by visiting dashboard.render.com/documents or by clicking Compliance and documents in the bottom-left corner of the dashboard.

All workspaces can view the following documents:

• SOC 3 report
• GDPR DPA

Organization and Enterprise workspaces can view additional documents after signing an NDA:

• SOC 2 Type 2 report
• ISO 27001 certificate
• Render security policy

You can now add your GitHub, GitLab, or Bitbucket credentials to more than one Render account to enable deploys from your repositories.

This is useful for:

• Individuals with separate Render accounts for work and personal use
• Agencies that help many different organizations get up and running on Render

Manage your deployment credentials from the Account Security section of your Account Settings page:

Configuring deployment credentials in the Render Dashboard

Note the following:

• You can't use the same Git provider account to log in to multiple Render accounts—only to enable deploys.
• A given Render account can have up to one connected account from each Git provider (GitHub, GitLab, and Bitbucket).

Learn more in the documentation.

Install the Render CLI to start managing Render services directly from your terminal:

Interactive navigation in the Render CLI

• Kick off service deploys (and optionally block on completion with --wait).
• Restart a service or trigger a one-off job.
• View and filter live service logs.
• Open a psql session to your database, and much more.

The CLI provides interactive, menu-based navigation. It also supports non-interactive mode with output in any of JSON, YAML, or plaintext for use in automation.

Get started with the Render CLI.

The Render Dashboard now provides faster, more intuitive navigation between your different services, environments, and workspaces.

• The left pane displays your workspace's top-level resources and settings (along with documentation and other helpful links):

The left navigation pane in the Render Dashboard

• As you navigate between services and other resources, the left pane updates to show what's most relevant:

Settings for a service in the Render Dashboard

• While viewing a resource, use the breadcrumbs at the top of the page to switch between projects, environments, and individual services:

Resource breadcrumbs in the Render Dashboard

• Open the improved search (⌘+K / CTRL+K) and use the arrow keys to jump directly to any resource:

Workspace-wide search in the Render Dashboard

• Switch to a different workspace with the dropdown menu in the left pane:

Switching workspaces in the Render Dashboard

Open the Render Dashboard to try out the new navigation!

As of Render's most recent database maintenance, every paid PostgreSQL instance now includes point-in-time recovery (PITR). In the event of data loss, use PITR to restore your database to any previous state from the past few days:

Point-in-time recovery in the Render Dashboard

Prior to this maintenance, some paid databases on legacy instance types did not support PITR.

Because PITR provides continuous backup capabilities, Render no longer creates daily logical database backups. You can still create and export logical backups on demand from your database's Recovery page in the Render Dashboard:

Creating a logical backup in the Render Dashboard

Learn more in the documentation.

All Render services now use OpenSSH version 9.9 to manage SSH connections. Services previously used version 8.9.

If you initiate SSH connections from your service, this upgrade includes one change that might affect those connections. From the OpenSSH release notes:

"SetEnv directives in ssh_config and sshd_config are now first-match-wins to match other directives. Previously if an environment variable was multiply specified the last set value would have been used."

If you use the SetEnv directive in your service's SSH configuration, make sure you don't set the same environment variable multiple times to avoid unexpected behavior.

Learn more about using SSH on Render in the documentation.

An interactive menu in the Render CLI

Now in public beta, the new Render CLI provides command-line support for common platform actions, including:

• Triggering service deploys, restarts, and one-off jobs
• Opening a psql session to your database
• Viewing and filtering live service logs

The CLI supports interactive menu-based navigation, along with a non-interactive mode for use in scripts and CI/CD.

Get started with the Render CLI.

Render has achieved certification to ISO/IEC 27001:2022, an internationally recognized standard of requirements for an Information Security Management System (ISMS). Alongside our SOC 2 Type 2 attestation, this certification exemplifies Render's rigorous ongoing commitment to maintaining a secure, global application platform.

Customers with an Organization or Enterprise workspace can request our ISO 27001 certificate from the Render Trust Center.

The Render docs now provide AI-powered chat trained on our documentation content. Click Ask AI next to the search box:

Opening AI chat in the Render docs

Use the chat to receive fast, focused answers to your questions about the platform, along with links to relevant articles:

Example AI chat in the Render docs

In-place PostgreSQL upgrades are now generally available for all Render workspaces. This feature upgrades your database to the most recent major PostgreSQL version supported by Render (currently 16).

Upgrading your database requires downtime. Schedule upgrades accordingly.

Open the upgrade page for your database in the Render Dashboard by clicking the version number on its Info page:

Opening the version upgrade page for a PostgreSQL database

Learn more in the documentation.

Render has moved PostgreSQL version 12 to legacy support ahead of its end-of-life on November 14.

Starting today, you cannot create new managed PostgreSQL 12 databases in your workspace unless you already have one.

We strongly recommend upgrading any PostgreSQL 12 databases to an actively supported version to continue receiving important security updates. Render supports in-place upgrades to PostgreSQL 16 from any previous version.

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

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

Newly created Python services now use Python 3.11.10 by default. You can always specify a different version.

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

Update: In-place PostgreSQL upgrades are now generally available.

Render now provides early access support for upgrading your PostgreSQL database's major version in-place. This upgrades your database to the most recent PostgreSQL version supported by Render (currently 16).

Upgrading your database requires downtime. Schedule upgrades accordingly.

Enable in-place upgrades from your Workspace Settings page in the Render Dashboard, under Early Access:

Enabling PostgreSQL upgrades in the Render Dashboard

Then open the upgrade page for your database by clicking the version number on its Info page:

Opening the version upgrade page for a PostgreSQL database

Learn more in the documentation.

Render's new flexible plans for Render PostgreSQL are now available for all workspaces. These plans enable you to set your database's storage separately from its RAM and CPU.

Starting today, every new database created on Render has a flexible plan. If you have a database on a legacy instance type, you can optionally move it to a flexible plan for improved customization and control.

Learn more in the documentation.

You can now enable maintenance mode for any paid web service in the Render Dashboard:

Enabling maintenance mode in the Render Dashboard

While in maintenance mode, a web service is not reachable from the public internet (but it remains up and running).

Enable maintenance mode to prevent incoming client requests while rolling out major changes to your infrastructure.

Learn more in the documentation.

All individual and team accounts on Render are now workspaces. This unified account model simplifies upgrading from an individual to a team. There are no changes to pricing.

Here's a summary of what's changed:

• Each individual account is now a free Hobby workspace with a single seat.
• Each team account is now a workspace with its existing plan, seats, and features.
• Hobby workspaces gain the ability to create one project with up to two environments.
• A newly created Hobby workspace can add a maximum of two total custom domains.
  • This limit does not apply to individual accounts created before this date.
• The Team plan is now named Professional. Paid plans are otherwise unchanged.
• You can upgrade or downgrade your workspace's plan at any time.

For details about each workspace plan, see the pricing page.

When you update a service's environment variables in the Render Dashboard, you can now specify whether this triggers a new deploy.

Selecting deploy behavior when modifying environment variables

You can select from three options:

• Save, rebuild, and deploy: Render triggers a new build for your service and deploys it with the new environment variables.
• Save and deploy: Render redeploys your service's existing build with the new environment variables.
• Save only: Render saves the new environment variables without triggering a deploy. Your service will not use the new variables until its next deploy.

Learn more about environment variables in the documentation.

As part of creating a pull request preview, Render now creates a GitHub deploy on the associated pull request. This matches the behavior for preview environments.

A PR preview's associated GitHub deploy

Click View deployment to open the preview instance in your browser.

Before this change, Render instead added a comment with preview details to your pull request. Render continues to use comments for GitLab and Bitbucket repositories.

Learn more in the documentation.

Render teams with a configured log stream can now override their default log stream settings for individual services:

Overriding log streaming for an individual service

• All teams can disable log streaming for an individual service.
• Teams with an Organization plan or higher can stream an individual service's logs to a non-default destination.

Additionally, all accounts can now configure whether logs from preview instances (service previews and preview environments) are included in their log stream.

Learn more in the documentation.

You can now opt to create preview instances only for particular pull requests that you specify. This new manual preview mode is provided alongside the original automatic mode, where Render creates a preview for every pull request by default:

Configuring manual PR previews in the Render Dashboard

In manual mode, you trigger a preview for a pull request by including the string [render preview] in the PR's title.

You can enable manual previews for any combination of pull request previews and preview environments. See the documentation for each:

• Pull request previews
• Preview environments

Protected environments on Render now enforce the following additional restrictions:

• Only Admin team members can view the values of environment variables and secret files for resources in the environment.
• Only Admin team members can view connection URLs and passwords for PostgreSQL databases and Redis instances in the environment.

Additionally, Render audit logs track the viewing of these values for all of an organization's resources (not just resources in a protected environment).

Teams on Render can now configure a project environment to block all private network traffic from entering or leaving that environment. This helps prevent your staging services from inadvertently accessing a production resource (or vice versa).

Toggle this setting from an environment's Settings page in the Render Dashboard:

Blocking cross-environment connections in the Render Dashboard

Learn more in the documentation.

Render's Virginia (US East) region has graduated from early access to general availability.

Select a service's region as part of the creation flow in the Render Dashboard:

Selecting a service's region in the Render Dashboard

Render supports deploying services to the following regions:

• Oregon, USA
• Ohio, USA
• Virginia, USA
• Frankfurt, Germany
• Singapore

The Render Dashboard now provides a dark display theme:

The Render Dashboard's dark display theme

Additionally, you can toggle a high contrast mode to more prominently highlight certain interactive elements.

Quickly set your theme from the account menu in the top-right corner of the dashboard:

Setting a display theme in the Render Dashboard

To also toggle high contrast, open your account settings and scroll down to the Theme section:

Theme settings on the account settings page

The Render API has added over 50 new endpoints to support much more extensive integration with the Render platform.

Endpoints are now available for the following resources that were previously unsupported by the API:

• Datastores (PostgreSQL, Redis, and persistent disks)
• Service logs
• Environment groups
• Blueprints
• Projects and environments
• Notification settings

New endpoints are also available for certain resources that are already supported by the API, such as redirect/rewrite rules for static sites.

With these additions, the API supports almost all functionality available in the Render Dashboard. There are no breaking changes to existing API endpoints.

The OpenAPI spec for the Render API is available in JSON format at this URL. You can use this spec to create your own custom clients and other tooling.

Learn more in the API reference.

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

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

Redis instances now emit service logs. As with logs for other service types, Redis logs are available in the Render Dashboard and via any configured log stream.

Redis logs in the Render Dashboard

Learn more about logging in the documentation.

Teams with an Organization or Enterprise plan can now export audit logs of material events that occurred in the account over a given time frame. This includes events related to:

• Team member management
• Project and environment management
• Service creation/deletion

Team admins can export audit log data in the Render Dashboard, from the Audit Logs section of the Team Settings page:

Exporting audit log data in the Render Dashboard

For a list of all audit log event types, see the documentation.

Note the following about data availability:

• For existing Organization and Enterprise accounts, audit log data is available starting from June 24, 2024.
• For a new Organization or Enterprise account, audit log data is available starting from the date of account creation.
• If you upgrade an account to Organization or Enterprise, audit log data is available starting from the date of the upgrade.

Learn more in the documentation.

You can now pull and deploy your private Docker images from Google Artifact Registry. Add your credentials in the Render Dashboard during service creation:

Adding a Google Artifact Registry credential in the Render Dashboard

With this addition, Render now supports pulling private images from the following registries:

• Docker Hub
• GitHub Container Registry
• GitLab Container Registry
• Google Artifact Registry

Learn more in the documentation.

Render now provides simplified deployment for popular PostgreSQL admin apps in the Render Dashboard.

Deploying PostgreSQL admin apps in the Render Dashboard

With a few clicks, you can deploy each app as a standalone web service that's automatically configured to connect to your database.

The following apps are currently supported:

• pgAdmin
• PgHero

Learn more in the documentation.

Render's official Terraform provider is now available in early access. You can use this provider to manage your Render services alongside other systems in your organization's infrastructure.

• The provider and its documentation are available in the Terraform Registry.
• Please submit any issues on GitHub.

Note that breaking changes might be introduced during the early access period. Any such changes will be noted in accompanying release notes.

You can now change the native runtime for an existing service in any of the following ways:

• Make an HTTP call to the Render API’s Update service endpoint.
  • Specify a new runtime via the serviceDetails parameter you provide in your request.
• If you’re managing your service with Render Blueprints, update the service’s runtime field in your render.yaml file, then sync your Blueprint.

Changing a service's runtime in the Render Dashboard is not currently supported.

Learn more in the documentation.

As of 2024-05-20, newly created Free Render PostgreSQL databases expire after 30 days (previously 90 days). Free databases created prior to this date retain their original expiration date.

The following Free database policies remain unchanged:

• Each individual and team account is limited to one Free database at a time.
• After your Free database expires, you have an additional 14 days to upgrade it to a paid instance type before your data is deleted.
• After your Free database expires, you can create a new Free database.

Learn more about Free PostgreSQL limitations in the documentation.

Teams can now require all members to log in to Render via their Google account (instead of using another supported login method, such as username and password).

Admins can enable this feature from their Team Settings page in the Render Dashboard:

Enforcing login via Google account in the Render Dashboard

If a team member does log in to Render using a different method, they cannot access the team's resources or settings.

Learn more in the documentation.

Update: The Virginia region is now generally available.

You can now deploy Render services to the Virginia region (US East).

Note that this region is currently in early access. It's available to all users, and it's feature-complete with our other regions. Early access provides us an opportunity to address any one-off issues that might arise with spinning up a new region. We'll announce when this early access period completes.

Specify a region in the Render Dashboard during service creation:

Specifying the Virginia region during service creation

If you're creating your service via a Blueprint, you can instead set region: virginia in your render.yaml file.

Learn more in the documentation.

Powerful new application metrics are available for paid instances in the Render Dashboard:

CPU metrics in the Render Dashboard

From your service's Metrics page, you can now visualize:

• CPU and memory usage over time, segmented by instance for scaled services
• HTTP request volume and response latency, segmented by status code, path, and more
  • Response latency metrics require a team account.

Metrics from the past 7 days are available for individual accounts. Teams can view metrics from the past 14 or 30 days, depending on their plan.

Learn more in the documentation.

You can now generate a render.yaml file from your existing services in the Render Dashboard:

Selecting services to include in a generated render.yaml file

Use this file to create a Render Blueprint that manages those existing services, or to replicate your architecture with a completely new set of services.

Learn more in the documentation.

Many popular IDEs now provide schema-backed validation and autocompletion for the render.yaml file format used with Render Blueprints:

An example of render.yaml validation in VS Code

To enable in VS Code, install the YAML extension by Red Hat.

Learn more in the documentation.

You can now connect your Bitbucket account to Render and deploy from any Bitbucket repo you have access to.

During service creation in the Render Dashboard, click + Connect Bitbucket. After you authorize Render, your Bitbucket repos appear in the selection list:

Selecting a Bitbucket repo in the Render Dashboard

You can also now sign in to Render using your Bitbucket identity.

Learn more in the documentation.

Teams on Render can now designate individual project environments as protected. Doing so prevents non-Admin team members from performing potentially destructive actions on that environment or its resources, including:

• Deleting any of the environment's resources (services, environment groups, etc.), or deleting the environment itself
• Modifying environment variables or secret files for any service or environment group that belongs to the environment
• Moving resources into or out of the environment
• Modifying access control IPs for any PostgreSQL database or Redis instance that belongs to the environment
• Accessing the shell for a service that belongs to the environment

Learn more in the documentation.

Render now builds your static sites and persists their assets in the same region where you deployed your first non-static Render service. Previously, all static site assets were stored in the Oregon region.

Static sites are still cached and served to users by a global CDN, regardless of their region. This change primarily improves latency for any rewrite rules that point to a Render web service in the same region.

All Render native runtimes now include the Bun JavaScript toolkit.

You can update your service's build and start commands to use Bun:

Updating a service's build and start commands to use Bun

With this initial release, native runtimes use Bun version 1.1.0 by default. You can use a different version by setting the BUN_VERSION environment variable for your service.

Newly created Ruby services now use Ruby 3.3.0 by default. You can always specify a different version.

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

All Render native runtimes now include the GNU gettext utilities.

As of 2024-03-11, all newly created Redis instances on Render use Redis version 6.2.14.

Instances created before this date used version 6.2.5. Render will upgrade these instances to 6.2.14 as part of their next scheduled maintenance.

Learn more about Redis on Render in the documentation.

Newly created Elixir services now use Elixir 1.16.1 and Erlang/OTP 26.2.2 by default. You can always specify different versions.

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

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

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

Newly created Python services now use Python 3.11.8 by default. You can always specify a different version.

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

Render now supports PostgreSQL version 16 for newly created databases. You select your database's version during the creation flow in the Render Dashboard.

If you have an existing database that you want to move to PostgreSQL 16, see Upgrading your PostgreSQL Version.

Teams with a database on a Pro instance type or higher can enable high availability (HA) for that database from the Render Dashboard.

When you enable HA, Render creates a standby instance of your database and automatically fails over to it if your primary instance encounters an issue.

Learn more in the blog post and documentation.

You can now bulk-add environment variables from your local .env file while creating or modifying a service or environment group.

Below any environment variable list in the Render Dashboard, click Add from .env:

Adding environment variables from a .env file in the Render Dashboard

Learn more in the documentation.

On January 31, 2024, a set of four container breakout vulnerabilities was disclosed to the public. We have patched all of our affected systems following the recommendations included in the disclosure.

These patches are transparent to applications running on the platform. Render users should see no changes to their experience and do not need to take any corrective actions.

After a thorough audit of potential exploit vectors, we found no evidence that this impacted Render's internal systems or users' apps and data. We will continue to monitor our systems for irregularities or unexpected activity.

If you have any questions, please get in touch with our Support team at support@render.com.

All disks attached to Render services (including PostgreSQL, Redis, and persistent disks for other service types) have been migrated to new hardware. Almost all services will observe improved read/write performance compared to previous hardware (especially for disks under 1 TB in size).

Teams on Render can now restrict any environment group (a shared collection of environment variables and/or secret files) to a single project environment. This helps protect against accidentally connecting a staging service to a production database (or vice versa).

Learn more in the documentation.

You can now customize:

• Which service events trigger notifications (such as deploy failures)
• Where those notifications go (email and/or Slack)
• Which services you receive notifications for

These settings help you stay informed about exactly the events that you care about most.

To start configuring your notifications, head to your Account Settings or Team Settings page in the Render Dashboard. For all the details, check out the blog post and documentation.

We've added support for regex and wildcard search to Render's new log explorer. Try out searches like these:

• /(request|response)/ - Find lines that mention at least one of request or response.
• /api/* - Find lines that mention a path that includes /api/.

See more examples in the documentation.

We've updated the default language versions for several of our native runtimes. Here are the changes:

• Node.js: 14.17.0 → 20.9.0
• Ruby: 2.6.8 → 3.2.2
• Elixir: 1.9.4 → 1.15.6
• Python: 3.7.10 → 3.11.6

A couple items to note:

• These are Render's new default language versions. You can always specify a different version for your app.
• These updates are for newly created services. Existing services keep their original defaults to prevent breaking changes.

There's a powerful new tool for searching and filtering service logs right from your dashboard:

Use the explorer to search your logs for an arbitrary string, filter by log level, and click to view any result in its original context.

With a team account, you can also view logs for every incoming HTTP request to your web services.

See the blog post, or try out the explorer in your dashboard.

Teams on Render now support two member roles: Admin and Developer. Only Admin members can perform organizational tasks like billing management, enforcement of 2FA, and inviting other team members.

For details, see the documentation.

Set a pre-deploy command for your service to run tasks (such as database migrations or asset uploads) right before a new version of your service goes live.

This command is particularly useful for services that deploy a prebuilt Docker image, because they can't fold these kinds of tasks into the build command.

For details, see the blog post and documentation.

Teams on Render can now enable the Performance build pipeline, which runs all of your team's builds on compute with 8x the RAM and CPU of default build instances. If your builds are currently hitting a resource limit, the Performance pipeline provides a whole lot more headroom.

For details, see the blog post and documentation.

Pull request previews help you and your team test out proposed changes, but some pull requests don't have any changes to test (like one that just updates a README).

In these cases, you can now include any of these strings in your pull request's title to tell Render not to generate a preview instance:

• [skip render]
• [skip preview]
• [render skip]
• [preview skip]

Render can now pull and run a Docker image directly from your container registry. These new image-backed services can speed up your deploys significantly if you're currently building from source with a Dockerfile.

You can pull public images from any registry, along with private images from Docker Hub, GitHub, and GitLab.

For more information, see the blog post and documentation.

While viewing metrics for a web service or private service in the Render Dashboard, you can now choose from multiple time ranges. Zoom in on a hiccup from the last five minutes, observe broader trends from the past week, or go with something in between.

You can now add your Datadog API key to an existing Render PostgreSQL database from the Render Dashboard. (Previously, integrating Datadog with an existing database required contacting Render support.)

We've added our newest deploy management feature — the option to cancel a deploy — to the REST API. This new endpoint can help if your team uses a third-party CI/CD tool to manage deploys with Render's deploy hooks. Learn more in our docs.

With Point-in-Time Recovery (PITR) enabled for your Postgres database, Render archives your data continuously. If unexpected data loss occurs, you can restore to a new database seeded with data from archives saved before the data loss occurred.

PITR is available on Team, Enterprise, and Organization plans for Pro database instance types and above. Learn more on our blog.

We spent the week working hard on upcoming releases, so our update is short and sweet.

Small wins we shipped this week

• Set preferred Poetry version Customers using Python native environments can now use a POETRY_VERSION environment variable to specify the version of Poetry they wish to have installed. Learn more.
• Deploying from external registries We addressed several bugs in the Early Access feature. As a reminder, you can try deploying containers from external registries by enabling the feature in Settings
• Errors for bad start commands If you configure an invalid start command, you'll now see an error in the logs and on the events page

• New logging for slow queries We now log when a query takes longer than 2s so that you have more data to help debug slow app performance.

Reminder: Updates to our build retention policy for Instant Rollbacks

Starting on July 5, 2023, we will retain builds only for the most recent deploys of Render services. Based on historical data, this change will not affect most users. The number of builds retained will vary based on plan.

Find more detail under Instant Rollbacks on our pricing page.

Happy long weekend to everyone in America! See you next Friday!

We're posting an off-schedule Changelog update to share that Render has achieved a significant milestone. Read on to learn more!

Render's $50 million Series B

This week, we announced that Render raised a $50 million Series B led by Bessemer Venture Partners. This new round of funding empowers us to continue to build toward our vision of making cloud infrastructure management a thing of the past and ushering in a new era of developer productivity.

Learn more about our story on Insider, Techcrunch, and our blog.

Projects are now available for all teams

Projects are now available for all developers on the Team, Organization, and Enterprise plans. You can use projects to organize your app’s services, making managing and collaborating with your team easier.

Learn more on our blog here.

Updates to our build retention policy for Instant Rollbacks

Starting on July 5, 2023, we will retain builds only for the most recent deploys of Render services. Based on historical data, this change will not affect most users. The number of builds retained will vary based on plan.

Find more detail under Instant Rollbacks on our pricing page.

Cancel deploys, Errors for failed on-off jobs, and more

We've also shipped a ton of small wins over the last week.

• Cancel deploys You asked, and we listened. If a deploy was triggered by accident or isn't going as anticipated, click the new Cancel button, and your service will remain as-is
• Show errors for failed one-off jobs Now, if a one-off job fails, we publish a meaningful error that should help make debugging easier
• New Trust Center If you need to request Render's SOC 2 report or learn more about our security and compliance posture, all of this is now available self-serve in our new Trust Center
• Doc updates We added a new section to our Web Services article explaining how host and port configurations work. We also updated the Free Instance Types article to better explain free-tier limitations

That's it for this week! As always, please let us know how we can improve Render for you. Thank you for choosing Render!

Happy Friday! This week, we've delivered major improvements to support our platform's reliability and integrity, making things better for everyone building on Render. On to the update!

Improved resilience to DDoS attacks

Render's load balancers are shared by multiple services, helping us handle our rapidly growing scale efficiently. With this update, we're introducing improved domain-level rate limiting to better isolate DDoS attacks. While we also have other DDoS prevention measures in place, this change improves how we prevent attacks from affecting unrelated services.

Bugfix for the native Python environment to allow installation of specific packages like Poetry

One of our customers wrote a script for installing a specific Poetry version on their instance, which uncovered an issue with installing packages that rely on specific locations for shared libraries. We fixed the issue this week, so other developers can try it too! We plan to make the process even easier by supporting a POETRY_VERSION variable similar to PYTHON_VERSION.

Faster, more reliable propagation of changes to custom domains

We are currently rolling out a change to significantly reduce the variance in the time it takes for custom domains to propagate across our global load-balancing infrastructure. The changes bring this variance down to O(seconds) instead of O(minutes). We will finish rolling it out early next week, and it should have the most noticeable impact on our Singapore and Frankfurt regions.

Improved reliability for logs

We finished rolling out an architecture change that removed a big moving part in how we stream logs to customer endpoints. This should lead to even more reliable logging going forward, especially as we continue to scale usage.

We also shipped several automations to block abusive services, making our engineers happier and more productive!

That's it! Have a great weekend!

Happy Friday! We've shipped fixes for two common pain points this week.

Easily find the runtime version used for apps running on native environments

Sometimes developers who use Render's native environments for building their apps end up using the incorrect runtime version. Since we didn't publish the runtime version, it took time for developers to figure out why their app didn't work. Developers can now see the version of the runtime their app is using and get just-in-time guidance to change it if it's not what their app needs.

Learn more about Native Environments support in our docs here.

Change the credentials associated with a service

Teams often encounter another challenge when someone who sets up a service leaves their team. Since the developer's credentials remain associated with the service, the team can't deploy the service anymore.

Now, team members can change the credentials associated with any service, ensuring that development continues as the team evolves.

Have a great weekend!

We have lots of quality-of-life improvements to share this week!

Restart servers using our REST API

Last week, we shipped the ability to restart services without redeploying them. We've now added an API endpoint to do the same — more at https://api-docs.render.com/reference/restart-server.

Faster go-lives for deploys

Massive scale meant some deploys took much longer than we'd have liked to go live. Not anymore! We've rewritten things to make deploy go-lives up to 10x faster.

Improved reliability for PostgreSQL replicas

We've fixed a bizarre edge case where Postgres replicas can get 'stuck' and never catch up with the primary.

Search by service ID

You can now find services using service IDs.

ICYMI

Early Access: Deploy images from public and private registries

Last week, we introduced the ability to deploy container images directly in early access. You no longer need to wrestle with Dockerfiles, and deploys can be much faster using pre-built container images.

That's it for this week. Have a happy and safe Memorial Day weekend if you're in the US, and enjoy the Spring Bank Holiday in the UK!

This week, we're thrilled to share updates on features we know many in our developer community have been looking to see to give developers more flexible options for deploying and operating services on Render. Without further preamble, let's dive in!

New from Render

Now in Early Access: Deploy container images from external registries

Earlier this week, we introduced the option to deploy container images directly on Render. With this capability, you no longer need to wrestle with Dockerfiles and can take advantage of faster deploys.

All developers can deploy images from public registries, and developers on the Teams plan and above can integrate with private registries hosted on GitHub, GitLab, or Docker Hub.

Try deploying your own container image by enabling this feature in Settings.

Platform Improvements

Restart a web service Developers can now restart a web service any time by navigating to the service page in Render and finding the Restart service option in the Deploy menu.

Restart a database replica We've supported restart for databases for a while. However, now, as of this week, developers can also restart database replicas by navigating to database replica settings.

Render now supports 2-3x more websocket connections for a service Render's designed to support developers building nearly any type of app, so we're excited to share that apps using websockets will see improved reliability going forward.

Faster builds on the free tier Our infrastructure team recently completed a significant redesign of our free tier, resulting in increased reliability and faster builds. Under the hood, we replaced a rather complex combination of Knative and Istio with a custom solution in Go that does exactly what we want it to do and no more. We call it the Hibernate stack: it allows us to scale services to and from zero based on traffic and allows free services to share the same build and deploy constructs used by paid services. We'll share more details in a blog post soon.

Have a great weekend!

It's Friday, and you know what that means! Time for us to dig into all the work we shipped this week.

New from Render

Host a ChatGPT retrieval plugin on Render We created a Render Example you can use to get started with ChatGPT plugins, all on Render. You'll need early access to plugins to try it out, and you can join the OpenAI waitlist here.

Product updates

• Billing improvements You can now view your invoice immediately after the billing period ends, so you have clarity around your spending on Render all the time.
• External connections to Render Postgres now require TLS v1.2 or higher. You'll also need to use one of the cipher suites listed in our documentation to connect to your databases securely. Learn more here.

ICYMI

Projects in Early Access You can now organize your services by app and deployment to make building and managing services much easier.

Access projects today by navigating to Settings and opting into Early Access. Available on the Team plan and above.

Our team is focused on shipping a few new features and bringing our recent Early Access launches into GA, so this week's update is focused on a few critical small wins.

New Releases

Enforced 2FA 🔒 If you're running mission-critical production services on Render, ensuring your Render team is secure is crucial. Starting this week, all Render teams can now require team members to have two-factor authentication enabled on their accounts to access team resources.

Product Updates

Rust is now available in Python environments on Render!

We also shipped several minor bug fixes and updates, including a new label for database pages indicating your database instance's plan.

ICYMI

Projects in Early Access You can now organize your services by app and deployment to make building and managing services much easier.

Get access to projects today by navigating to Settings and opting into Early Access. Available on the Team plan and above.

Get early access to PITR and pgvector If you're still waiting to use point-in-time recovery or pgvector, please get in touch with Support. You'll need to run maintenance on your database to access these features if it was created before March 27, 2023, for PITR, or April 15, 2023, for pgvector.

PITR is available for the Pro plan and above databases on the Team plan or higher.

Hi there! We've got a short update for you this week, so we'll keep it brief.

Product Launches

• Projects was released in Early Access this week! You can now organize your services by app and deployment, making developing and managing services in Render more straightforward and delightful. You can get access to the Early Access feature, if you haven't already, in Settings

Feature Improvements

• pgvector is now available for new Postgres databases! pgvector is a Postgres extension allowing you to harness AI to build semantic search into your apps. Over the next couple of months, we'll roll out pgvector to existing databases so that everyone can try it out

Have a good weekend!

Hi there! It's the end of a productive week at Render, and we're excited to share this week's updates.

Product Launches

• Point-in-time Recovery is now available in Early Access! You can join the preview by navigating to Settings in the dashboard and finding the Early Access section. New databases on the Pro plan or higher, created after joining the Early Access program, will have the option to use PITR. You will be able to enable PITR for existing databases when the feature is generally available. Learn more here.

Feature Updates

• You can now configure a previewPlan type for Redis to allow preview environments to use a smaller Redis instance size.
• We now remember your last active team and switch to it when you log back into Render. 
• We've added links to service or deploy logs in service events to facilitate debugging when errors occur.
• Changes to instance types are now accurately represented in billing. So, if you change an instance type during a billing period, your bill will be easier to follow.
• We added support for Ruby Env versions 3.2.2, 3.1.4, 3.0.6 and 2.7.8 in native environments.

Bug Fixes

• We made some UI polish improvements throughout the dashboard and billing pages.

Rebooting our Changelog

Hi there! As of this week, we're relaunching our Changelog. Expect to see new updates here each week and sometimes in your email.

Here's the update for this week:

New Releases

• You can now change the repo connected to a service
• You can now regenerate the deploy hook URL for a service

Product Updates

• Added support for Python 3.11.2
• Updated log level in log streams to map to appropriate syslog priority. The default log severity level is now INFO instead of ALERT
• Added support for Sumo Logic as a log stream
• Added support for listing more than 100 branches for GitLab repositories
• Service events now display the user who triggered an instance type change

Bug Fixes

• Fixed the display of y-axis labels in metrics charts
• Added an instructive error message in Blueprint syncs if the repo cannot be accessed
• Clarified in the UI that service health checks are internal
• Started cleaning up Preview Environments when a PR is closed, even if Preview Environments aren't enabled
• Fixed an issue causing external Postgres connections to close unexpectedly

Docs Updates

• Updated the REST API docs to reflect monorepo support