Feature Requests

I have 2 accounts on render.com , both connected to one GitHub account. I want to give Account A access to Repo X I want to give Account B access to Repo Y However, when I log into Account B to give access to Repo Y , Account A also gets access to it. In fact, if I only give access to Repo Y to Account B , Account A gets access to it and loses access to Repo X . This is really bad since the repos are private two accounts are meant for different companies without cross-contamination.

Currently, there are Service Previews and Preview Environments, which are extremely confusing. I accidentally ran migrations against my production database, because I enabled Service Previews, expecting them to work like in Heroku - it's own standalone services generated. I think most people will be confused with this approach, not to mention this requires use of a blueprint-linked service, and this is not something everyone uses. So I'd like to see Service Previews improvement - make the default to replicate the service, but provision new instances, so that it lives in its own sandbox environment. Considering I don't want to link a blueprint, as it's quite scary to mess with a production setup, I will have to completely stop using previews until then. I have a feeling I am not the only one in this boat.

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.

Currently, static outbound IPs are shared with other users, which might lead to being blocked because of a misbehaving neighbor using the same IP. It would be great to have dedicated static outbound IPs that can be used in a project. This would be something like Quotaguard, but built inside Render. All web services within the same project or environment could use the same outbound IP.

I often write my apps with docker-compose to specify all the docker options. I would render to be able to read my docker-compose file, create all the services, and appropriately coordinate between them, as if I had simply run docker-compose up

I accidentally deleted the project and now I don't get back the url I need anymore, that's super stupid since I used this URL myself, there is no reason why it should be blocked forever

We are a Denmark + Finland based media organisation, expecting to expand into other Scandinavian / North European countries. Being able to deploy to the eu-north-1 would reduce latency for our users. Stockholm is also blessed by abundant renewable energy, making hosting in eu-north-1 a more climate friendly alternative to eu-central-1.

Allow cloning repositories from self-hosted GitLab instances.