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’s Preview Environments solve this problem by automatically creating a clone of your production environment (including services, databases, and environment groups) on every pull request, so you can test your changes with confidence without affecting staging or relying on devops teams to create and destroy infrastructure.
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.
Preview environments can be helpful in a lot of cases:
- Share your changes live in code reviews: no more Git diffs for visual changes!
- Get shareable links for upcoming features and collaborate more effectively with internal and external stakeholders.
- Run CI tests against a high fidelity copy of your production environment before merging.
- Make sure your services and databases are defined in a
render.yamlfile and synchronized in your Render Dashboard. See our Infrastructure as Code documentation for how to get started with
previewsEnabled: trueat the top level of your
render.yamlfile to enable preview environments.
previewsEnabled: trueservices: - type: web ...
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 explicitly set a
branch for your services in
render.yaml then that would be used to deploy a preview environment as well which may 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.
You can override the billing plan used for preview services by specifying a
previewPlan that is different from the corresponding production value. See YAML plan names for a list of valid values.
previewsEnabled: true services: - type: web plan: standard previewPlan: starter name: express-server env: node databases: - name: my_test_db plan: standard previewPlan: starter
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.
previewsEnabled: true services: - type: web plan: standard name: express-server env: node envVars: - key: MY_API_KEY value: production-api-key previewValue: test-api-key
Placeholder environment variables defined with
sync: false will not be copied to preview environments. To share secret variables across preview environments:
- Manually create an environment group in the Dashboard.
- Add one or more environment variables.
- Reference the environment group in your
render.yamlfile, as needed.
previewsEnabled: true services: - type: web plan: standard name: express-server env: node envVars: # The value for `MY_API_KEY` provided in the Dashboard will *not* be # copied to preview environments. - key: MY_API_KEY sync: false # Any values in this group will be copied to preview environments, # if `all-settings` exists and is *not* included in this file. - fromGroup: all-settings
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.
You may 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
previewsEnabled: true services: - type: web plan: standard name: express-server env: node initialDeployHook: ./seed_database.sh
You can set the number of days a preview environment can exist without any new commits to help control costs. Set
previewsExpireAfterDays 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.
previewsEnabled: true previewsExpireAfterDays: 3services: - type: web plan: standard name: express-server env: node
If you define the Root Directory or specify Build Filters for each service in your Blueprint Spec, 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 resources are billed just like regular Render services and are prorated by the second. See Render Pricing for service and plan details.