Hi! A question/feedback. Any special reasons why pulumi resources (stacks, stackreferences, providers) count in billing? we manage as per today 407 resources which 50 (12%) are only logical references and not actual managed resources. No criticism. Just to understand the logic behind pricing which looks like those kind of resources grow linearly against the number of resources you manage, which we always need to take as a cost overhead.

hi @few-postman-20852 Can definitely appreciate the question. We definitely hear this feedback. The foundational logic here is that Pulumi does not differentiate the purpose of a resource when it’s counted as a billable item. There is overhead to us to track and manage every item, whether it’s a stack/stack reference/provider which to customers may seem “free” or even an autoscaling group with 100 huge instances in it (which obviously would have a huge cost) - to pulumi they all look the same, it’s an object inside the resource graph that needs to be tracked and managed. While you’re right that this will grow linearly, our thought process has always been that it’s also predictable. However, we do recognise that some orgs and workloads might have more of these resources than others. One thing that we do also recognise is that this may drive your usage of Pulumi into a way that doesn’t follow best practices. We are consistently having conversations internally about how to effectively manage this, and I’ll feed that information back to the team. In addition to this, we’d be happy to have a conversation with you about your individual usage to see if we can help here. Please feel free to reach out to me personally lbriggs<at>pulumi.com and I will facilitate a conversation with someone from the account team

Thanks for the answer! Yes, definitely it leads me to overuse Resource.get instead of importing it to the codebase or using stack references. We can also avoid using micro stacks which slows down a lot in CI/CD. In contrast I see more fair to have the cost included in the token price of the actual resources rather than on those logical resources in the graph, which drives the real delivered value of pulumi and avoid such kind of discussions.

Late reply - it would be great if such 'logical resources' were not priced separately, but included in cost of 'real provider' resources. Then if there's overuse of logical resources there could be a fee that kicks in at a higher level perhaps, or a lower fee for such resources. Pricing more for use of micro stacks seems like it's creating the wrong incentives.

Correct. Terraform Cloud for example doesn't count their own resources in the graph in the billed ones. Today the free tier is covering the Pulumi resources, which leaves you to say that the free tier can cover ~100 resources depending on your usage.

@few-postman-20852 do you have any literature on the terraform cloud not billing for provider/meta resources I can refer to?

That doesn’t seem to differentiate between provider resources and cloud resources?

I don't use TF Cloud, but I would guess that its own resources don't appear in TF state files? If so they would not be chargeable