Preview Environments

Preview environments require a Pro workspace plan or higher.

For details, see the pricing page.

It is critical to have testing and staging environments accurately reflect production, but achieving this can be a major operational hassle. Most engineering teams use a single staging environment which makes it hard for developers to test their changes in isolation; the alternative is for devops teams to spin up new testing or staging environments manually and tear them down after testing is done.

Render preview environments solve this problem by automatically creating a fresh copy of your production environment (including services, datastores, and environment groups) with every pull request, so you can test your changes safely and confidently. Copies of datastores and persistent disks do not include data from their corresponding "base" resource (you can seed sample data as part of preview environment initialization).

Preview environments do not currently support Render Workflows.

If you enable preview environments, Render automatically skips creating preview copies of any workflows your Blueprint defines.

Render keeps your preview environments up to date on every commit and automatically destroys them when the original pull request is merged or closed. You can also set up an expiry time to automatically clean up preview environments after a period of inactivity.

Use preview environments to:

• Test out logical and visual changes in a live, production-like environment
• Quickly share links to upcoming features with teammates, customers, and clients
• Run multi-service integration tests against a high-fidelity copy of your production environment before merging

Render will support preview environments for stacked pull requests on November 18, 2026.

Getting started

1. Make sure your resources are defined in a YAML file configured as a Blueprint in the Render Dashboard.

   • By default, Render creates a Blueprint using the render.yaml file at your repository's root. You can specify a custom file path in the Render Dashboard. For details, see Render Blueprints.

2. To enable preview environments for a Blueprint, set the previews.generation key to one of manual or automatic in your YAML file:

   For details on each option, see Manual vs. automatic preview environments.

   Setting the deprecated field previewsEnabled: true is equivalent to setting this field to automatic.

3. Merge your changes to your Blueprint's linked branch.

You're all set! Open a new pull request in your repository and see your preview environment deploy with status updates right in the pull request. You can visit the URL for your preview environment by clicking View deployment next to your web service deployment.

As of this writing, GitLab does not support status updates on merge requests.

If you'd like to try this for yourself, fork our Preview Environments example repository, synchronize the render.yaml file in your dashboard, and open a new pull request.

If you explicitly set a branch for your services in render.yaml then that would be used to deploy a preview environment as well which might not be expected behavior. Typically, if you're using preview environments you don't need to specify a branch as we would use the branch the blueprint was created for initially and then the branch the pull request is against to create the preview environment.

Manual vs. automatic preview environments

Stacked pull requests

Preview environments for stacked PRs on GitHub are coming soon.

Starting November 18, 2026, Render can create preview environments for every PR in a stack. See details below.

To enable this feature sooner, reach out to our support team in the Render Dashboard.

In a PR stack, each PR targets the branch of the PR below it:

Each preview environment for a stacked PR deploys that PR's branch, including the changes from every PR below it. Your preview mode determines how Render handles preview environments for stacked PRs:

• Automatic: Render automatically creates a preview environment for each PR in a stack built on your linked branch. In the example above, both PRs get a preview environment.
• Manual: Include [render preview] in the title of each PR you want to preview.

In automatic mode, you can skip the preview environment for any PR in a stack by including [skip preview] in its title. This is useful for mid-stack PRs, since the top PR's preview environment includes every change.

Override preview compute plans

Services in a preview environment can use a different compute plan from their production counterparts. By using smaller compute plans for preview environments, you can reduce costs.

• For Render Postgres and Key Value instances, set the previewPlan field.
• For all other service types, set the previews.plan field.

See example render.yaml declarations below. For all supported values, see the Blueprint YAML Reference.

If you don't specify a preview compute plan for a service, Render uses the same compute plan that you use in production.

Override number of preview instances

Web services, private services, and background workers in a preview environment can use a different number of instances from their production counterparts. By using fewer instances for preview environments, you can reduce costs.

See example render.yaml declarations below. For all supported values, see the Blueprint YAML Reference.

If you don't specify a preview number of instances for a service, Render uses the same number of instances that you use in production. If autoscaling is configured, Render uses the minimum number of instances.

Environment variables

You can override environment variables in preview environments with previewValue. This can be useful if you need to override a production API key with a test key, or if you'd like to use a single database across all preview environments. Environment variable overrides are supported for web services, private services, and environment groups.

Placeholder environment variables

Placeholder environment variables defined with sync: false are not copied to preview environments. To share secret variables across preview environments:

1. Manually create an environment group in the Dashboard.
2. Add one or more environment variables.
3. Reference the environment group in your render.yaml file, as needed.

You can also use an environment group that’s managed by a Blueprint, if it’s not the same Blueprint that you’re using to manage your preview environments.

If you use the same Blueprint for both, a new environment group will be created for each preview environment. Placeholder environment variables will not be copied to these environment groups.

Preview environment initialization

You might want to run custom initialization for your preview environment after it is created but not on subsequent deploys, for example to seed a newly created database or download files to disk. You can do this by specifying a command to run after the first successful deploy with initialDeployHook.

Automatic expiration

You can set the number of days a preview environment can exist without any new commits to help manage costs. Set previews.expireAfterDays to automatically delete the environment after the specified number of days of inactivity. The default is no expiry. The expiration time is reset with every push to the preview environment.

Root directory and build filters

If you define a root directory or specify build filters for each service in your Blueprint file, Render will only create a preview environment if the files changed in a pull request match the root directory or build filter paths for at least one service.

Preview environment billing

Preview resources are billed the same as other Render services and are prorated by the second. For details, see the pricing page.