Feature Requests

Call GitHub Deployments API automatically after a Render deployment is started, canceled, successful, etc. It would be really useful to see all the currently running environments on GitHub with all the details: environment url log url deployment details date & time of deployment commit deployed etc.

Render should add built-in support or clear documentation for handling special characters in sensitive environment variables, such as MongoDB connection strings. This would help users avoid common pitfalls with URI encoding (e.g., special characters like |, @, or &) when deploying services that rely on external databases or APIs. A small enhancement, such as automatic encoding or validation, could greatly improve the developer experience.

I am hosting my own docker registry, and I would want render.com to be able to pull my images from it. Currently, providing a docker hub based username and password credential would give me a notification that render was able to connect and find the image in my registry. The logs in the registry confirm this as well. However, when I try to deploy the web service, render fails to pull the image from the registry. The logs indicate render provided the incorrect credentials when it attempted to pull the image. It seems like almost everything is there from render's side, and it just needs a bit of a modification for it to work. As a side note, the deployment works fine if I remove the credentials from the registry.

You can use Render Deploy Hooks to trigger a build from an external CI service like GitHub Actions or CircleCI. https://render.com/docs/deploy-hooks It would be nice to automate this process based on CI status check events that GitHub already emits on the repo.

Sometimes, a service is dependent on another service, like when a background worker is dependent on the main service getting updated and running migrations. It would be nice to be able to define this relationship in Render, so things like deploys can run sequentially.

We're considering migrating from Heroku where our Java and Scala apps are essentially monorepos for API+workers. Heroku runs a build once and then can deploy the API and all the workers quickly, they even have incremental builds which are very valuable for Scala projects. Render builds from scratch for each service (for each line in your Procfile), no incremental builds are available either. So instead of one build and multiple quick deploys, we are looking at 4,5 builds/deploys. Scala apps take a long time to be built so we're looking at hours in deployment times. :( Right now we're looking into building elsewhere and then deploying the final Docker images, but it would be great if build-once-deploy-multiple-services was supported by Render natively. We also use Coolify for some self-hosted apps and they support the "build-server" concept. Maybe something to borrow from them: https://coolify.io/docs/knowledge-base/server/build-server Here is another idea from Coolify, push Docker image to a registry after building/deploying so that other services could deploy from the image (see attached image) without building again: https://coolify.io/docs/knowledge-base/docker/registry Thank you

Just is a convenient command runner. I use it in most of my projects to document and run commands locally like start, test, build, lint, etc. For me, it's more convenient than using Make or language-specific project scripts. https://github.com/casey/just I would like to be able to use my Justfile's build and start commands from Render. Two examples are just build and just start-prod on my current project.

Render advertises zero downtime however if you need to deploy several services it's challenging to minimise the time they are out of sync for. Building one service may take significantly longer than building another. For this reason it would be nice to be able to prep a built-version of a service and then, in a separate command, to be able to switch traffic to the new service. That would allow for much better synchronisation in the release of multiple services (e.g. a back end and a front end). Not only that but it would allow the build step to happen in parallel with testing which would shave another minute or so off of the CI cycle. Because a deploy has to happen in lockstep with a build, neither of them can be started until tests have passed. If it were possible to decouple the two then the build step could run in parallel with the tests. Deployment would be the final, instantaneous release command. Heroku allows for this with build slugs that can then be rolled directly into production.

When you trigger a deploy from CI via either a deploy hook or the API the trigger returns immediately. Which also means it does not communicate whether the deploy succeeded. The screenshot below shows a CI process in which both deploys to render actually failed to deploy. However since the actual deploy command doesn't persist through the deploy or return that information then you have to poll Render to find out whether it's succeeded. Doing so is a non-trivial operation. This is a public script that does so: https://github.com/sws2apps/render-deployment/blob/main/src/index.js However well intentioned they are, I don't use any uncertified scritps in CI processes becuase of the tremendous security risk and so it would would be excellent for Render to either: Offer their own, certified Github actions script to make it easy to poll for success or (better still) Offer a way to make a synchronous call to Render which fails if the deploy fails Update ___ I've now written the github script to do this and have shared it below. It's a bit of a waste for all of yoru customers to be battling through this though :/

we recently switch from having automatic pull request previous to manual so we need to add [render preview] at the end of every pull request. When we used the automatic option we would see one notification/comment from render. now everytime theres a change in the pr, etc. we have render notifications spamming our pr. Any help on how to turn off this feature?