Feature Requests

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)

Certain cron jobs need to persist data on disk between runs, and Render Disks work great for this.

The ability to ssh into an existing proccess is great, and let's you do some of the things that heroku run lets you do. (And some things it doesn't, becuase heroku run doesn't actually let you connect to a current process). But the main difference is that heroku run will start a new "dyno" for your run task. Not use an existing web or worker process. It boots it up on demand, and charges you for the minutes of use. This is useful becuase you can run things (or open an interactive console) in a separate environment from your actually running production web/worker, without worrying about interfering with their RAM or CPU resources -- to run a temporary one-off task, or an interactive console. In terms of render's model, I could imagine this working by defining a new service type with it's own "build command"... but then I guess you'd still need some CLI way to launch one of those with a custom one-off "start command".

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.

I can use Docker to run PHP apps but it would be great to have native PHP support in Render.

It would be really nice to have built-in password protection for static sites, so I don't have to use something like Auth0.

For users who don't create PRs, enabling branch previews will serve the same function: automatic creations, updates, and deletions of services for all branches in the repo.

Request to implement some kind of programmatic redirect framework to let the user write a file during build time that will inform static site redirects for Render. Suggested by Brandon Wang.