Feature Requests

webapp

Hi Render team, I'm building Vibe Costs, a dashboard that lets developers monitor live software and AI infrastructure spend in one place. Render already shows provider-calculated current usage and cost in its dashboard, and it supports third-party integrations. I could not find a documented way for a workspace admin to authorize an external cost dashboard to read billing data without sharing a more powerful credential. Would you consider an organization-scoped billing:read OAuth permission? The useful fields would be the current-period total and currency, credits and adjustments, cost by service and project, billing period, and a freshness or finalization timestamp. It should not allow deploys, service changes, settings changes, or billing writes. Our proposed response shape and authorization requirements are here: https://vibecosts.app/cost-api/docs Render support directed me to post this request here. I would be happy to test an early implementation against my own workspace. Thanks, Alderik Vibe Costs

I'm looking for the current status and roadmap position of multi-zone high availability for Web Services. Our SOC 2 Type 2 controls require production service instances to be deployed across physically separate data centers. The requirement would be satisfied by something close to what Render already ships for Postgres HA: instances in the same region, placed in zones that are geographically separate, with automatic failover when a zone becomes unavailable. We do not need multi-region. My understanding from the public docs is that Web Service instances carry no zone-diversity guarantee, even when a service is scaled to multiple instances. If that is wrong, I would like to understand the actual placement behavior. Three questions: Is zone-redundant placement for Web Services on the roadmap? If so, is there a rough timeline or a way to follow it? For a Web Service scaled to multiple instances today, is there any guarantee, or documented best-effort behavior, around spreading those instances across zones? Is there documentation on Web Service instance placement and failure domains that we can reference as audit evidence? This is currently blocking us from running Web Services in production. We would prefer to keep this workload on Render rather than move it, so any clarity you can give helps.

Render forces me to enter credit card when I try to create new static website, even on trial account period. Howether your documentation says it's not required.

When I’m making a web service and I deploy tells me “Please enter your payment information to select an instance type with higher limits.”

Currently, there’s no way to securely use an API key while controlling my web application. I’m developing an API to monitor the server's boot status and attempted to use the List Events feature. However, I can't keep the API key completely safe due to platform limitations. It would be beneficial to have the option to restrict the API key's access to specific actions, like only allowing it to use the List Events API.

I want to make a suggestion. On the settings page, maintenance mode is currently showing a switch with a label 'Maintenance Mode disabled'. This suggests that if I flick the switch to on it would still show 'Maintenance mode disabled' with the switch on. Instead what happens is when you flick the switch the label changes - this is confusing. The switch should act like a checkbox. At the moment it's unchecked, suggesting that if I check it I'm disabling maintenance mode. What actually happens is that I toggle maintenance mode from off to on.

I would like to define the minor PG version and have finer grain control over minor version updates. My team is running into issues with schema generation right now because CI and Prod use an older PG version than many devs on our team run, and there are syntax differences for some things between 15.15 and 15.18 so we're getting unexpected schema modifications when running migrations locally. It's going to be a pain if everyone has to downgrade to 15.15 and then update again whenever Render does db maintenance.