Service Groups in the Dashboard | Feature Requests

Service Groups in the Dashboard

complete

I would group services related to a product of mine under the same belt.

June 8, 2022

Meagan Gamache

marked this post as

complete

As of today, projects are now available to all Render users on the team plan or higher. Learn more on our blog here: render.com/blog/projects

Emile

Please consider the network isolation (https://feedback.render.com/features/p/network-isolation) in your implementation. Offering environments that are not segmented is really not the way to go and is against all modern good practices of security.

The docs makes it look like it is a good thing and should be rephrased as a SEVERE limitation front and center.

Anurag Goel

Emile: I agree network isolation within teams is an important feature, and we've added it to our near-term roadmap.

Shawn Moore

Projects is now in Early Access! Use projects to organize the services for your applications, and environments to manage multiple different deployments (think Production vs Staging). You can try it out for your team by enabling the feature in your team settings.

More information on projects in our docs here: https://render.com/docs/projects

Michael Hellein

Shawn Moore: I appreciate that there's a way to group services, but this seems like it's both too much and too little. It's too much UI and navigation for something this conceptually simple, and it delivers too little functionality for the level of setup it requires.
For this feature, I would have been happy to have a way to tag services and filter them on the dashboard. This feature isn't a great fit for the stated need from this discussion.
What I really want from "projects" is a pipeline for (atomic) releases, and this seems like a step away from that instead of toward it, since it encourages plopping more than one resource into a project's environment sack. It seems that customers are looking for a replacement for Heroku's pipelines - or even a clone if the product design process doesn't come up with something more intuitive.

David

Michael Hellein: Exactly, I can't agree more. I think Render made a design mistake when they decided there was no need to distinct build phase from release phase, as stated in the 12-factors-app manifesto. I wrote a detailed article to explain why: https://www.david-dahan.com/blog/the-importance-of-the-release-stage-in-deployment

Shawn Moore

Michael Hellein: Hi Michael, thanks for your thoughtful note. We certainly hear you that you'd like more from projects. What we're launching now is foundational for the features you've mentioned, and even more still that we're excited about, like network isolation between environments. This first release was designed very much with that ambitious roadmap in mind.

We're always happy to chat more about what you're looking for - shawn@render.com.

Shawn Moore

David: Hi David, expect to hear more about decoupling builds from deploys soon!

Julian Vergel de Dios

David: Strong agreement with your article. The separation of build and release phases in Heroku that enabled the pipelines feature was so central to what made it a joy to use for non-trivial apps, IMO, but no one seems to be trying to replicate it (except hopefully Render, now).

Anurag Goel

marked this post as

in progress

Tushar Ranka

Anurag Goel: Is there any update to this much awaited feature?

Anurag Goel

Tushar Ranka: we'll have a big update today/tomorrow

Anurag Goel

Merged in a post:

Service Grouping

Hamed Montazeri

Related services should be grouped together on the UI to make them easier to manage and visualize together.

March 23, 2023

Michael Hellein

Is the in progress Render concept of service grouping going to include build promotion? To me, that's the most crucial missing feature in Render. The fact that there's no way to do an atomic deploy of an existing tested build introduces risk into every release (or even a change to environment variables).

Anurag Goel

Michael Hellein: not in the first iteration (which will be out in a few weeks), but definitely after.

Michael Hellein

Anurag Goel: That's great news, on both counts. Thanks!

Jeremy Bell

I would love the ability to pause/resume multiple services at once

Wojciech Rzepecki

Hey Anurag Goel, any progress news about this feature?

Shawn Moore

Wojciech Rzepecki: Hi Wojciech, we should have some exciting news before the end of the month! :)

Shawn Moore

Give us one more week or two to polish!

barry

My case is fairly simple, and when I think grouping I think deployment.

My Blueprint encapsulates a number of things including a Rails web service and a Sidekiq worker service. As the web and worker services need to stay in sync codewise, I would like a way to mutually deploy both of those services together. I realize auto-deploying might approximate this, but I’d prefer not to auto-deploy and it also doesn’t assure that both services have successfully deployed before finalizing the deploy. It would be good for these deployments to be tied together such that they can be rolled back together if either of them fail.

Bergur Hallgrimsson

I would love the ability to link the blueprints to those groups. Today the "standard solution" to having staging with autoDeploy and preview on MR and then a manual deploy is duplicate the blueprint and move the production blueprint into a another repo.

→