This message was deleted.

Hi Albert, curious what the motivation is to leave the managed service. Always happy to hear some feedback.

Pulumi managed service is great and we don't need put much effort to manage login and backend, but we want to get more control and visibility on the state. Cost is also one of another reasons because there are many resources created for one service. For example, each DNS record in Route 53 and each Security Group Rule are also treated as one resource. This number will be very large for us.

@dazzling-television-62903 the answer there is “it depends”. You don’t have to create individual security group rules, for example, you can include them as part of the security group inputs (although there are times when this might be necessary).

Hi @dazzling-television-62903 let us know if you need more input.

Just want to chime in as another user of both Pulumi service and self-hosted backend. We do use Route53 as well, and it would make it quite expensive when use the service. So for those project we've got just s3-backed state. There might be non-production stacks with hundreds of resources inside - and visibility is not really required there, nor the features that the service provides. So it makes sense to keep them in a "free" state backend. However, Pulumi currently doesn't support having a mix of state backends within one project. Or even referencing stacks that use different backend. Would be nice to make it possible. Overall, the Pulumi managed service is nice, but it's not always the best choice for us.

@brave-planet-10645, thanks for your suggestion. In some scenarios, it's true that we may use other way for provisioning in order to reduce the number of resources. For us, we still have many other scenarios that generate many resources like parameters in Parameter Store and Route 53. Even though I can create baseline rules together with the creation of security group, we still need to allow other projects to create security group rules on the created security groups for some use cases. We have 3 environments (stacks), so the number of the resources consumed will be 3 times roughly.

Feel free @dazzling-television-62903 to drop any feedback via the contact form too! Always happy to hear our customers. In all terms!

Sure, thanks for your follow-up. By the way, anyone in your team can help to answer this: I'd know the way how to migrate our state to our managed backend and clean up the state in Pulumi managed service. Thanks again.

pulumi stack rm <name> --force

should delete the stack on remote backend and leaving any resource behind managed by the stack. Be sure, that your new backend is working fine (

pulumi refresh

) before deleting the stack in the managed service backend.

@many-telephone-49025, many thanks for your reply and reminder.