Feature Requests

Support for selecting Postgres version 17

I’d love a “roll password” button on the database page. It would be nice if the services using the connection string automatically restarted with it, but I could do that manually if needed. I really just don’t want to have to dump/restore a new database in order to downgrade someone’s credentials (I’d like to do more than just remove their IP from the list). I think that the nicest would be to even have scheduled password recreating.

While Render supports storing data on disks, it would be great to have a really easy to use object storage feature with the capabilities of AWS S3. This would be accessible via S3-compatible APIs and will be used to store arbitrary blobs like images and videos.

Deno ( https://deno.com/runtime ) is a modern, fast JavaScript runtime (from the originators of Node.js). I'd love to use Render for Deno-based web services instead of Node.js-based web services. It should be very simple to adapt what you have for Node.js web services and tool it for Deno instead. (Deno is actually simpler than Node.js + npm, a single all-in-one executable that is both the runtime and the package manager, etc.)

uv is an extremely fast Python package and project manager, written in Rust. Supporting this will make deployments way faster. Instead of "poetry install" for Build Command, will be great to have available "uv install" This is uv: https://docs.astral.sh/uv/

Feature Request: Automated Billing Workflow Integration with Render Objective To streamline the billing process for clients hosted on Render by automating the generation and synchronization of project, environment, and service data, and integrating it into a billing system. The outcome is a consolidated database to generate QuickBooks invoices efficiently. Overview On the 1st of each month, an automated cron job will: Fetch the latest projects, environments and services from the Render API. Synchronize their environments and services data. Ideally with the new API we match each service to billing details for invoice generation. Key Requirements Cron Job Setup: - Schedule: Trigger monthly on the 1st at a designated time. - Action: Call Render’s Projects API to fetch project data and store it in the database. Environment Synchronization: - Action: For each project retrieved, call the Environments API to synchronize environment data. Service Synchronization: - Action: For each environment, call the Services API to fetch associated services. Billing Data Generation: - Action: Map the fetched service data (via service IDs) to corresponding billing/pricing data. - Deliverable: A database record with the following structure: - Project - Environment - Service - Pricing details - This record should be complete and ready for invoice generation. Invoice Automation: - Use the finalized database records to create QuickBooks invoices via an automation tool. For us this is the Expected Outcomes A fully automated, end-to-end billing workflow. A consolidated, accurate database for all clients’ project, environment, and service data mapped to billing details. Reduced manual effort in invoice generation via integration with QuickBooks.

Proposal It would be really nice to have the following syntax available in render.yaml : envVars: - fromGroup: my-production-env-group - fromGroupPreviewOverride: my-preview-env-group This problem has come up several times in the community and is one of the most important parts of a streamlined CI/CD workflow. I would love to see it on the roadmap :) Problem statement Currently, there are 3 options for overriding environment variables in preview environments: Solution 1 Define them in plaintext within render.yaml : envVars: - key: MY_ENV_VAR value: production-value previewValue: preview-value This works for values that can be shared, but is not suitable for private secrets (which is a pretty common use-case) Solution 2 Define them with sync: false and manually fill them in on each PR. This works, but is extremely time consuming, especially if your env file has 10+ variables to fill in. Solution 3 (workaround) Omit environment groups from render.yaml altogether, but still reference them in your services. For example: envVars: - fromGroup: my-production-env-group - fromGroup: my-preview-env-group From here, you must write additional logic into your application to choose the correct variable based on the environment. let myVariable; if (process.env.NODE_ENV === 'development') { myVariable = process.env.LOCAL_VALUE } if (process.env.NODE_ENV === 'production') { // https://render.com/docs/environment-variables#all-services if (process.env.IS_PULL_REQUEST) { myVariable = process.env.PREVIEW_VALUE } else { myVariable = process.env.PROD_VALUE } } In my opinion, this 3rd solution is the best, but still isn't great because it requires you to expose production variables in your preview environment.

Allow users to set account-level spending limits for variable factors.

After a deploy (or after other significant events), I want to hit an endpoint on my api so I can run logic (ex. notify users, increment release number in the db, etc)

I would love to be able to deploy from another host, from Subversion, or from a local repo.