Hello Pulumi team, I'm an early user since 2018 and have always supported Pulumi which is a game changer in the industry since then, but I have a serious issue with your current pricing model (team edition). Using Pulumi today to manage all of our aws infra costs us 2x more than what we pay to aws, which is insane for "just" IaC. And I'm talking only about resources credits here since we don't use anything else (and we won't given this pricing issue). While I'm willing as a business to pay a fair contribution to support your project instead of using the free plan, this is not properly balanced nor sustainable. So, what should we do ?

I am also trying to figure the costs we have now in Pulumi cloud.

Yeah, I attempted to minimize resource costs using various optimization techniques, but first I should not have to do that and second there is a limit to that anyway. For example, simply registering multiple custom granular policies to maintain a secure infrastructure costs us up to $10 per month in Pulumi, whereas even AWS provides this functionality at no charge. The resources credits pricing model is wrong imo. It can't be justified and it obviously don't scale properly.

We've been grappling with the same thing. It's been a bit uncomfortable that the pricing doesn't scale with the benefit we get from the cloud platform, and discourages us from using more pulumi components. Having the number of all items in our state count towards the overall cost has been rough - for example: using the random provider to create a random value is a credit. For us, would love some kind of storage-based pricing for the state and log storage, since that's what we signed up to use because we thought it would be simpler than self-hosting a backend.

Same, for me much of the value is in having IaC for everything - but the cost for even our core needs would be tend toward not-feasible for the scale I'm at (organisationally teeny) - and when one tries to do the right thing and have a lot of limited privilege users / accounts / etc for diverse parts of my responsibilities it very rapidly heads toward prohibitive.

Hey all, I’m not on the pricing side, but I wanted to say thanks for laying out concerns. I can’t speak for pricing decisions or promise changes, but this kind of specific feedback is genuinely useful internally, so I’ll make sure folks see this thread. For anything tied to your actual bill or plan, the only people who can really dig in are support@pulumi.com or your account contact. I don’t have access to that detail myself.

@elegant-bird-72480 Do you mean that you would rather be charged per state file instead of per resource?

@modern-spring-15520 by way of example, and this is just users, policies. policy attachments and credentials for AWS:

Current stack resources (43)

(for the production environment). There is a combination of more needed and some optimisation that would remove resources that probably balance out but this doesn't even touch actual useful work. A single "service" deployed to EKS comes out at 12, two of which are providers and two stack references (and one kubernetes service!). I have quite a few services to deploy (some may require fewer resources, some rather more...)

Hey @modern-spring-15520 Thanks for your answer. While I don't expect promises or pricing models change overnight, I would like to know if the team is aware of this problem and could tell if this could/will be addressed soon. Because I think you can understand that your customers can't reasonably pay you more than their own cloud providers for basically keeping a json state file of resources. I can't justify such (growing exponentially) pricing discrepancy any longer (even to myself)

Yeah, pricing is tricky and something that is thought about a lot. (And we appreciate you being with us since 2018. ) That's probably about all the specifics I can share. But will draw attention to this thread.

Yeah, I can rely on finding the right pricing model, tricky indeed. Thanks for sharing the thread internally. It's just that, while we could switch back to free plan or even host the state ourselves, first we don't really have time to allocate to that and second I would prefer to continue to be a contributor to Pulumi but with a fair price. Thing is we're kind of at a price threshold that don't justify paying that much anymore and allocating time to get out will make sense, which I'd like to avoid.

@faint-motherboard-95438 Have you reached out to support/billing at all with your concerns? https://www.pulumi.com/contact/

Well, no, I'm used to come here (even if that's a while I didn't, because it works pretty well) but if you prefer I reach out there and forward the thread, sure I can.

Yeah, for a pricing concern, the contact for will help get it in front of the right folks directly.

I'll chip in and say that this very much on my mind as an SRE/infrastructure engineer currently in the evaluation stage deciding whether to advocate for a move to Pulumi internally. We've decided to carry out a proof of concept in one area of our tech stack, but we're pretty concerned about how costs will scale. (Less significant overall but the limitations on user management and RBAC at the Team plan also seem a little rough for groups our size to evaluate and make a case for internally - difficult to pitch it internally as a tool that'll be user-friendly and easy for all our developers to interact with when we can't give them accounts, and having only one account able to act as admin is a big friction point when we're deploying resources through the kubernetes operator and only an admin account can delete empty stacks.)

@kind-napkin-56243 How large is your org's cloud footprint? Would you be on the Teams plan, or Enterprise?

@stocky-restaurant-98004 alright, I'll follow up directly with contact, thanks. But given the (unexpected) shared feedback this thread has brought up, I think that's actually a healthy discussion to also have openly with the community

Yes, both convos are good to have: in the community, and directly with support.

@stocky-restaurant-98004 - I suspect we'd probably be near the cap of 500 resources in Pulumi for the Teams plan if we rolled our current POC out to all our environments (managing database, database users and credentials in Pulumi rather than Terraform). We have somewhere between 100-200 resources currently at a preliminary phase. A very large number of these are individual pieces of metadata of the kind @faint-motherboard-95438 mentions - we have around 10 resources per stack of individual database grants and default privileges , and 4 providers (AWS, PostgreSQL, random, Kubernetes). Feels like quite a conflict between making good use of Pulumi's ability to write granular and nuanced infrastructure definitions and writing things in a way that'd be cost-efficient. If we decided to build new infrastructure in Pulumi rather than Terraform going forward and stuck to the kind of design patttern we've been using here, we would end up on the Enterpise plan.

@kind-napkin-56243 Probably not gonna solve the whole issue, but you may not need to use the random provider unless you're generating keys. Autonaming solves the need for it for a lot of customers.

@stocky-restaurant-98004 we are using this to generate passwords for database users.

Just to provide another datapoint: We looked into Pulumi Cloud some time ago and pricing turned out to be prohibitively expensive for our >> 12,000 resources.

@stocky-father-81239 so you're self hosting states in a bucket or not using Pulumi at all ?

The former! We use Azure blob storage.