Service Groups in the Dashboard
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.
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
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.
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
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 - email@example.com.
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).
marked this post as
Anurag Goel: Is there any update to this much awaited feature?
Tushar Ranka: we'll have a big update today/tomorrow
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).
Michael Hellein: not in the first iteration (which will be out in a few weeks), but definitely after.
Anurag Goel: That's great news, on both counts. Thanks!
I would love the ability to pause/resume multiple services at once
Hey Anurag Goel, any progress news about this feature?
Wojciech Rzepecki: Hi Wojciech, we should have some exciting news before the end of the month! :)
Give us one more week or two to polish!
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.
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.
This feature will be very helpful, my dashboard is a mess right now.