Second & third: Devops-y questions 1. What is the support for multiple environments, e.g.: I'd prefer that we have say, 3 accounts instead of 1 account with 3 stacks, is that possible - how do API keys work in this case? What does Pulumi recommend to handle secrets across environments and say, prohibit a "Staging" environment API key from being used to deploy to the "Production" environment? 2. We use GitLab review apps to deploy many branches to Kubernetes, each as their own independent version of our entire backend/frontend, so we often have many versions of our pre-staging infrastructure running simultaneously. What would Pulumi recommend to handle this case? Are these considered their own "stacks", and would the pricing then be dependent on how many

1. What is the support for multiple environments, e.g.: I'd prefer that we have say, 3 accounts instead of 1 account with 3 stacks, is that possible - how do API keys work in this case? What does Pulumi recommend to handle secrets across environments and say, prohibit a "Staging" environment API key from being used to deploy to the "Production" environment?

There are several options. You can use any mix of cloud-provider accounts you want, and use either a single Pulumi stack which manages resources in multiple cloud-provider accounts or separate Pulumi stacks for each of the cloud-provider accounts. We provide RBAC as part of the stack management offered by pulumi.com for organiations, so you can restrict which Pulumi user accounts have read/write access to which stacks - which can provide a layer of defense in depth on top of your IAM configuration for you cloud provider. The most common approach here is to have separate Pulumi stacks per environment you are targeting, and set each stack's configuration with the desired secrets. Because it's all just code, you can also do whatever verification you want up front in the deployment to protect against accidentally deploying a stack with incorrect credentials - like comparing the account number of the credentials used for the deployment against a fixed account number that the stack is configured to deploy against, or providing all cloud provider credentials in explicit config so that no ambient credentials are used.

I would also be interested in the planned changes to the stack pricing model 🙂 It would be great to know what we can expect.

Thanks @white-balloon-205, I would like to hear what @adamant-restaurant-73893 and the company are thinking for evaluating per-stack pricing like this. For what it's worth, we typically have between 4 and 10 review apps going at a time, with 3 engineers on staff. I'd expect that to scale linearly or less as we grow, because eventually we'll have "pods" or "teams" of users which work together on feature branches, as opposed to each engineer typically working on one of a few different features at a time.

Will do 🙂.

Successfully poked - and sorry for the tardy response!