This message was deleted.

There are answers to several questions related to this at: https://www.pulumi.com/docs/troubleshooting/faq/#how-does-pulumi-depend-on-pulumi-com. But to answer your specific question, the

pulumi

CLI speaks directly to your target cloud provider. This ensures that credentials for talking to your cloud provider do not need to be shared with the Pulumi service.

interesting, I can see the reasoning, is the backend for pulumi.com opensource so it can be self hosted?

they manage locking and storing the state, AFAIK there is a local backend for DIY with no feature loss

Sure, but the local backend means you cannot work with other people. So you cannot use this for opensource projects with multiple people handling infrastructure, or share the state across builds in a CD pipeline.

I can hardly imagine opensource (== public) workflow on infrastructure as a code. Coordination within a closed group is certainly possible , you can checkin state file into Git LFS and then use Git LFS locks to prevent parallel runs. With enough discipline (and easy to use wrappers) should be fairly straightforward, although I never tried myself and went for cheapest paid option.

why not? open infrastructure is a thing, once you find a solution for sharing secrets, it’s even pretty good

why not? open infrastructure is a thing, once you find a solution for sharing secrets, it’s even pretty good

Do you have an example of such projects on github/gitlab?

Well, there is ours at least https://github.com/lghs/infra

so thats a code, there is nothing runs that code in that open projects. so when I create a PR it wont spin up throwaway stack in cloud and check my changes lets say. there is no need for locking in this setup, as there is nothing gets run automatically

https://www.pulumi.com/docs/intro/concepts/state/#self-managed-backend u can use a bucket for remote state with your team