Great project, thanks for shipping this! My company has been developing(and using) a project extremely similar to Pulumi - which we're planning to open-source - because there wasn't anything else out there. A question that'll help us decide whether to push ahead or get behind Pulumi: The tool seems to be tied to your platform. Is there any way we can configure a generic object store for checkpoint state?

@quick-football-95839 and @stocky-spoon-28903, great question. It's one we've thought a fair bit about. That default experience of storing state in our service was designed to address the common pain point we hear from customers that need to statefiles by hand, but we also understand that for advanced use cases, people need more control here. We do store checkpoints encrypted at rest and in transit, and we have ideas for advanced features here, like encrypting with your own KMS key, but no solid plans yet. These points may make you feel better, but again, we assume advanced users like yourselves will want more control over this. The good news do have an undocumented mode where checkpoints will be stored on your filesystem, which we used when bringing up the system initially. To use it, run

pulumi login local://

. (@bitter-oil-46081 is the expert here, if you hit snags.) Naturally, it's more challenging to use, and doesn't gain benefits from the service like automatically handling team environments, but we always intended it for scenarios like this. The backend interface is fully extensible -- so e.g., S3 backends are reasonable -- although, advance warning, it'll be a bit of a moving target in the early days as we evolve the interfaces. It's all open source, however, and we will have a roadmap soon and will be fully transparent with where we are planning to go here, well in advance of going there. TL;DR, we are still early, sincerely appreciate the feedback, and would love to work with you to make you happy and successful going forward on Pulumi.

Since I'm the expert I get to point out that the above command is actually slightly incorrect. You run

pulumi login --cloud-url local://

which by default will store data in

~/.pulumi/

. You can also augment the URL with a path to a different folder, eg

pulumi login --cloud-url local:///some/better/storage/location

.

Understood. I’ll figure that part out when I get to it.