Earlier this week we announced new usage-based pricing for Pulumi Team and Pulumi Enterprise.  These changes have been based on talking to dozens of Pulumi customers (including many of you here - thank you!) over the last few years.  We've heard loud and clear that per-user pricing was holding back broad adoption of Pulumi within organizations, and that the lack of a free tier for small teams getting started was making it harder for teams to get up and running with Pulumi and the Pulumi Service. Our new editions address these two pieces of feedback.  They are priced based on the number of cloud resources under management, with a low per-resource price and a generous free tier so teams can get started easily. Critically, there are no changes at all for Pulumi’s open source projects. In summary: • If you are happily using Pulumi purely open source today, there are no changes. • If you have considered using Pulumi Team or Enterprise, but the pricing didn’t fit your needs (either you needed a free tier of Team to get started, or you needed an option that gave your whole team access at a lower cost), please do take a look at our updated offers. • If you are already a Pulumi Team of Enterprise customer, you can keep your current plan indefinitely, but if you would like to explore moving to the new resource-based pricing, please contact us.

Curious if you guys have thought about static website scenarios where each file is treated as a separate resource? That could add up quick and quite a few of your static website examples do it that way.

I was looking at the pricing page yesterday and was slightly unclear about what constitutes a resource-hour. Is that for deployed resources only? ie the clock starts ticking upon the completion of

pulumi up

and stops at

pulumi destroy

or something else?

Re: what Joshua said above, that's exactly how our business has done things. Right now a deployment is ~90%

aws.s3.BucketObject

resources and the pricing model (0.18 USD/resource-month) does not work at all for us, as much as we would like to take advantage of unlimited stacks. Our Docker containers and Lambda functions don't care about the number of files involved, so I don't think our frontend builds on S3 should be any different. Has anybody developed a good solution for an S3FolderSync custom resource or similar?

@bored-oyster-3147 @brash-area-40729 I'm curious how this works for you in the code? Why this solution was preferred compared to an 'out-of-pulumi' recursive upload ? Also, how many s3 objects are you managing in your buckets?

It's structurally identical to this example from the docs: https://www.pulumi.com/docs/tutorials/aws/s3-website/ A single tenant deployment for us is ~420 S3 bucket objects, and we have four deployments now expecting more soon. Are there docs or examples of out-of-Pulumi upload solutions? I can conceive of what they might look like but there is a huge variety of potential tools that could be used.

A pricing model should align with added-value provided and I am convinced that the new Pulumi pricing model violates this rule. Resources in Pulumi (and also in similar tools like Terraform, AWS CDK, ...) are a purely technical dimension and often needed for engineering (but not business) purposes. • Let consider for example an AWS IAM

RolePolicyAttachment

resource it is neither a business object nor a billable AWS resource, it's just an abstraction used to decouple AWS IAM

Role

and AWS IAM

Policy

resource from each other. But now in Pulumi it will become a billable resource which is absolutely ridiculous. • If I create a resource (e.g. a S3 Bucket), Pulumi only provides added value whenever I need to change something on that resource's configuration. Pulumi does not provide any added-value by just storing the resource's state in-between resource modifications. So paying per resource-hour is not usage-based-pricing. Paying per resource modification/operation (e.g. create/update/delete would be usage-based-pricing in this case). • I have to pay an hourly fee to the cloud provider (e.g. to AWS per EKS control plane hour, or per EC2 instance hour), which is justified as I get an added-value in return (a running EKS cluster resp. a running virtual machine), but having to pay an hourly fee for all the Pulumi micro-resources that make up an EKS cluster or an EC2 instance is just not justified I do not get any added-value in return on an hourly base from Pulumi (as mentioned above Pulumi only provides added-value during configuration change). I's really sad to see how more and more startups miss the point of their own added-value propositions and just try to imitate business model (pricing) of other players without realising that is does not make any sense at all. That said, it would be totally fine to increase pricing in the existing (old) model if margines are not working out, customers will understand and accept it as long as they still benefit (have an added-value from using Pulumi). I could go-on with more arguments like this, but now I rather invest my time to figure out what's the impact on my Pulumi bills and if necessary how to move-out of Pulumi again 😞.

@steep-sunset-89396 Kenneth linked the relevant Pulumi documentation example. Using that method it would be very easy to hit 1000s of BucketObjects for a single static site

I appreciate all of the feedback folks 🙏 We are listening. I am sure this isn't the final destination for how we package and price Pulumi, so this feedback will help us refine things over time. We did consider introducing tiers of resources (the S3 object and IAM feedback), but wanted to keep the initial model as simple as we could, to start. With existing customers, although this was a common initial reaction, usually after modeling it out due to the very low per unit cost, and typical blend of resource types, it was workable. We also considered doing per-resource-update, but that varies wildly for customers too (we have some customers who deploy every minute), and we expect to introduce new features like drift detection and proactive policy as code monitoring, that work even when you're not actively updating. Note that the motivation for this change wasn't financially motivated. In fact, we lose revenue on this plan compared to the old model. Instead, we have regularly heard that teams perceived it to be too expensive to get started with Pulumi, too expensive to pay for everybody in the team to get a seat, and that it's frustrating to even think about seats given the large disparity in usage (some users are "power users" and use it daily, others are "casual users" and might only use it weekly or monthly). In fact, it's sort of antithetical to the entire goal of Pulumi enabling cloud engineering collaboration between devs and infra folks. The free tier was chosen so that the entire team can get up and running entirely for free with many production workload architectures. It's still early and I can't claim we've gotten this 100% right. We had a few dozen customers switch over to the new model, however, and they are universally happier with the new model, for what that's worth. More of the team gets access to Pulumi, at a lower cost, and the price scales naturally with the "success" they see with Pulumi over time: more projects, more stacks, more resources, etc, means they are getting value from Pulumi, more so than "users who have access." If after doing the analysis, the new model simply doesn't work for your team as-is, please get in touch and we'll hop on a call to figure out an arrangement that does. We also aren't forcing folks to switch to the new model and are honoring all prior agreements, as we are still early here. Again, thank you for the feedback, please keep providing it and we will learn and adjust.

I'm using a self-managed S3 backend at the moment. Do you have any utility for using the stored stack/state information to generate a cost estimate under the new pricing?

We do! @gentle-diamond-70147 can help you out.

@astonishing-quill-88807

pulumi stack ls -a

will print your stack summary, with the number of resource for each stack. Repeat that for each bucket/backend you use if you separate them across different buckets (e.g. prod vs. nonprod). Then can take the total number of resources multiplied by 730 (number of hours in a month) to get the Pulumi Credit number for the month.

Great, thanks. I'll give that a shot.

Your dashboard at https://app.pulumi.com gives a graph showing your usage over time, which should be plenty for a quick estimate