Feature Requests

Projects are really useful, but at the moment they are only accessible in the dashboard. I'd like to be able to configure them via blueprint yaml as well (so that I have a record of it and can version it in source control)

Add Sao Paulo region

Hello, I have a webapp that uses a Webservice, Worker, Redis, PostgreQL and Flower. All are on paid plans and everything if working fine. I have set the auto build feature off at the moment. So it wont rebuild when any changes are made in GitHub unless I manually instruct it to make the new build. My request is, is there a way to manually instruct all the above services to manually build again at one go? At the moment I need to click build for each of them separately. What would be great is an option to Multi-Deploy many services together. Thanks

Right now the billing is on a global level. But it would be most useful when billing multiple clients, that this is per project (or from a other feature request, each project linked to a client) Shared services like render minutes could be calculated with the amount of minutes used by each project And of course there would be a section for non-project.

It was counterintuitive to not be able to link the .env group to a service during the service set-up process, and only after. The pane for linking to .env groups should be accessible when setting up a service.

When saving your Environment Variables, if a row is entirely blank, ignore it instead of showing an error.

As a student, I donot have any credit card. The should be separate subscription plan for students.

Whenever a PR deployment is created, I have to remember to manually switch the Environment variable group to preview from my default prod group. It starts to get burdensome when I'm opening multiple PR's a day and forget to switch.

Current metrics are great, but they take up way too much space. It would be nice to be able to have a compact version, where metrics are shown in a grid. It should be a quick feature to add, even simply using TailwindCSS grid classes gets us half way there

Currently when whitelisting unless you include the internal service addresses it blocks those internal services from communicating with each other, e.g. Web service to Postgres etc.