Enhanced Metrics for App and Network Performance
Learn moreTeams can now require login via Google account
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:
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.
Added Virginia region (US East) in early access
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:
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.
Enhanced service metrics in the Render Dashboard and API
Powerful new application metrics are available for paid instances 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.
IDE validation for render.yaml files
Many popular IDEs now provide schema-backed validation and autocompletion for the render.yaml
file format used with Render Blueprints:
To enable in VS Code, install the YAML extension by Red Hat.
Learn more in the documentation.
Create a Blueprint from existing services
You can now generate a render.yaml
file from your existing services in the Render Dashboard:
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.
Added support for Bitbucket
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:
You can also now sign in to Render using your Bitbucket identity.
Learn more in the documentation.
Designate environments as protected to prevent destructive actions
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.
Static site assets now built and persisted in the same region as other services
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.
Added native support for Bun
All Render native runtimes now include the Bun JavaScript toolkit.
You can update your 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.
Default Ruby version updated to 3.3.0
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.