 instance type or higher can enable high availability (HA) for that database from the 

 instance of your database and automatically fails over to it if your primary instance encounters an issue.

The Render platform supports all your apps _and_ all their data—with just a few clicks, you can spin up a PostgreSQL database with at-rest encryption, daily backups, and comprehensive extension support. And because that database runs on the same network as your apps, connections are fast, secure, and reliable.

Adding to our existing set of database reliability features (like read replicas and point-in-time recovery), today we're happy to announce the full launch of **High Availability** (**HA**) for Render PostgreSQL. With just a few _more_ clicks in the Render Dashboard, teams with a **Pro** instance type or higher can now activate HA for their database:

<video autoplay loop muted controls width="700">
 <source src="https://render.com/images/enable-ha.mp4"/>
</video>

Following a restart, your database is protected against most causes of extended interruption, reducing their impact to under sixty seconds. (This one-time restart can take a couple minutes, so we recommend flipping the switch during off hours.)

## How it works

When you activate HA, Render spins up a second database instance, called a **standby**. The standby replicates the state of your existing **primary** instance (asynchronously, on a delay of no more than a few seconds).

The standby runs in the same region and network, but on hardware that's physically isolated from the primary. It doesn't receive any incoming queries—it simply keeps itself synced with the primary, ready to jump into action when needed.

### Failing over

Even the best built software has its quirks, and so does the hardware it runs on. At some point in the future, your database's primary instance might become unavailable: the underlying node might go down, or the PostgreSQL process itself might crash.

When Render's control plane observes that your primary has been unresponsive for 30 seconds, it automatically **fails over** to the standby by pointing the primary's URL at the standby instead:

```mermaid
flowchart TB
 subgraph "Render"
 others("Your other services")
 primary[("<s>Primary</s> ❌")]
 standby[("Standby 🟢")]
 others -.->|"❌"|primary;
 others --> standby;
 end
 class primary failure;
```

This swap takes a few seconds, after which the standby instance becomes the new primary! Whenever the unresponsive instance becomes healthy again, it becomes the new standby. Database access is restored in less than a minute, avoiding what might have been a much longer interruption. Render even triggers a failover on your HA database when performing routine maintenance, reducing the associated interruption to less than a minute.

**Again, failover happens automatically**—no action is required from your team. You _can_ trigger a manual failover from your dashboard, but you should only need to do that for your own testing purposes.

## Highly available, now generally available

High availability serves as a powerful line of defense against the vast majority of events that cause database downtime. With both HA and [point-in-time recovery](https://docs.render.com/postgresql-backups#point-in-time-recovery), you're fully equipped to keep your mission-critical databases healthy and responsive.

Learn all the details about HA in the [docs](https://docs.render.com/postgresql-high-availability), and enable it for your team's **Pro** and larger databases from the [Render Dashboard](https://dashboard.render.com).

For your smaller databases, check out Render's other PostgreSQL reliability features, such as [read replicas](https://docs.render.com/postgresql-read-replicas) and [daily restorable backups](https://docs.render.com/postgresql-backups).

Announcing High Availability for Render PostgreSQL

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 

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

Teams can now require login via Google account

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.

Added Virginia region (US East) in early access

Powerful new application metrics are available for paid instances in the 

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.

Enhanced service metrics in the Render Dashboard and API

Many popular IDEs now provide schema-backed validation and autocompletion for the 

IDE validation for render.yaml files

 file from your existing services in the 

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.

Create a Blueprint from existing services

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

. After you authorize Render, your Bitbucket repos appear in the selection list:

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

Added support for Bitbucket

Teams on Render can now designate individual project environments as 

. 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

Designate environments as protected to prevent destructive actions

 and persists their assets in the same region where you deployed your 

 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 

 that point to a Render web service in the same region.

Static site assets now built and persisted in the same region as other services

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

With this initial release, native runtimes use Bun version 

 by default. You can use a different version by setting the 

Added native support for Bun

Newly created Ruby services now use Ruby 3.3.0 by default. You can always 

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

Default Ruby version updated to 3.3.0

Added gettext to all native runtimes

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

Instances created before this date used version 

. Render will upgrade these instances to 6.2.14 as part of their next scheduled maintenance.

New Redis instances use version 6.2.14

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

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

Default Elixir version updated to 1.16.1

Now in early access, you can scale Render services that have an attached 

. Enable this capability from your Account Settings or Team Settings page in the 

If you scale a disk-backed service, Render attaches a

 This can result in data fragmentation for services that act as a centralized, non-distributed database.

Scaling is well suited for disk-backed services that use their disk as a standalone cache, where different instances can process independent jobs in parallel.

Scalable disk-backed services now in early access

Newly created Node.js services now use Node.js 20.11.1 by default. You can always 

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

Default Node.js version updated to 20.11.1

Newly created Python services now use Python 3.11.8 by default. You can always 

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

Default Python version updated to 3.11.8

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

If you have an existing database that you want to move to PostgreSQL 16, see 

PostgreSQL 16 now available for new Render PostgreSQL databases

Enable high availability for large PostgreSQL databases

You can now bulk-add environment variables from your local 

 file while creating or modifying a service or 

Below any environment variable list in the 

Add environment variables in bulk from a .env file

 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.

Patched Leaky Vessels container breakout vulnerabilities

All disks attached to Render services (including 

 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).

Persistent disks migrated to new hardware

 (a shared collection of environment variables and/or secret files) to a single 

. This helps protect against accidentally connecting a staging service to a production database (or vice versa).

Restrict shared config to a single environment

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 

Customize your service notifications

We've added support for regex and wildcard search to Render's 

 - Find lines that mention at least one of 

 - Find lines that mention a path that includes 

Search your logs with regex and wildcards

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

 services keep their original defaults to prevent breaking changes.

Updates to default language versions

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.

New log explorer + HTTP logs

Teams on Render now support two member roles: 

 members can perform organizational tasks like billing management, enforcement of 2FA, and inviting other team members.

Assign access roles to team members

 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.

Run migrations and other tasks with the pre-deploy command

, which runs all of your team's builds on compute with 

 of default build instances. If your builds are currently hitting a resource limit, the Performance pipeline provides a whole lot more headroom.

Run builds with higher RAM and CPU

 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 

Skip an unnecessary pull request preview

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 

 images from Docker Hub, GitHub, and GitLab.

Deploy a prebuilt Docker image from a registry

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.

View service metrics for different time ranges

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.)

Add Datadog monitoring to existing Render PostgreSQL databases

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 

Cancel deploys via Render's REST API

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 

PostgreSQL point-in-time recovery now available

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

 Customers using Python native environments can now use a POETRY_VERSION environment variable to specify the version of Poetry they wish to have installed. 

 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

 If you configure an invalid start command, you'll now see an error in the logs and on the events page

 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 

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

June 30, 2023 - Changelog

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

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.

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.

Updates to our build retention policy for Instant Rollbacks

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

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

 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

 Now, if a one-off job fails, we publish a meaningful error that should help make debugging easier

 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 

 explaining how host and port configurations work. We also updated the 

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

June 21, 2023 - Changelog

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!

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.

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!

June 9, 2023 - Changelog

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 

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.

Jun 2, 2023 - Changelog

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

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

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.

You can now find services using service IDs.

Early Access: Deploy images from public and private registries

 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!

May 26, 2023 - Changelog

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!

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.

 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.

 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.

 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 

 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.

May 19, 2023 - Changelog

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

Host a ChatGPT retrieval plugin on Render We created a 

 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 

 You can now view your invoice immediately after the billing period ends, so you have clarity around your spending on Render all the time.

 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 

 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.

May 5, 2023 - Changelog

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.

 🔒 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.