By default, Render rebuilds your code every time you deploy, even if the code hasn't changed from the previous build. But if you're deploying the same commit to staging then promoting to production, or running multiple services from one repository, you shouldn't have to wait for Render to rebuild identical code.
You can now save time and compute by reusing builds across multiple Render services. Reusing builds also ensures that the correct artifact is promoted between dev, staging, and production environments.
Starting today, we are rolling this feature out in Private Beta to select customers. To request access, fill out this form, and our product team will be in touch when we're ready to onboard you.
When to reuse builds
If you run two or more services on Render built from the same repository or image (a web service and its workers, multiple services within a monorepo, or the same service deployed across staging and production) reusing builds can usually save you time and money. The benefit increases with the number of services sharing a build and the time each build takes.
Reusing builds when promoting between environments also ensures that those environments don't drift apart because of changes in build-time variables or in how dependencies resolve.
How it works
Define a Build Source once by specifying a repository, branch, and build command, and Render produces one immutable build artifact. Any linked service across development, staging, and production can deploy that exact artifact with no rebuild.
For services linked to a Build Source, build-time and runtime variables are now scoped separately, so runtime secrets aren’t available during the build unless you explicitly pass them as build-time variables. This separation makes it safer to promote the same build across environments instead of rebuilding it with a different set of credentials.
What’s supported during Private Beta
Currently, you can reuse builds for web services, private services, and background workers. This allows you to:
- Link multiple services to a single Build Source, so the same commit builds once rather than once per service
- Deploy the same build across linked services, so production runs the exact artifact you verified in staging
- Automatically deploy the latest build from a Build Source or manually deploy a specific build
- Create and manage Build Sources through the REST API and Blueprints, and view Build Sources, linked services, and related logs in the Render Dashboard
See the documentation for current limitations.
What's next
During Beta, we plan to add cron job support, a fuller Dashboard experience, and CLI and Terraform support.
How to join Private Beta
Capacity is limited during this phase. To request access, fill out this form. We'll review your request and reach out when we are ready to onboard your team.
Once approved, you’ll:
- Work directly with the Render Engineering team as you implement Build Reuse and share feedback
- Review and influence design details across the REST API, Blueprints, and Render Dashboard before they’re finalized
- Get early visibility into related features as they’re introduced during Private Beta
Your use case and feedback will help shape Build Reuse as we work toward General Availability.