Anyone skip the backend and secrets provider abstractions and interact with internals directly? For example, for the backend we can only configure a URL and the SDK will for the resource over the network, but I'd like use my own state store rather in code.

like you want to use local state?

The only option i see right now is localworkspace, export the stack, and then push it to my k/v. Id rather not hit the filesystem and I'd like update the state store as it changes rather than all at once at the end of a transaction.

yeah, you can only use the pulumi-supported backends via the exposed API - https://www.pulumi.com/docs/intro/concepts/state/#logging-in

Ha ha this will level my expectations: the automation api is just a wrapper that runs the pulumi binary in a child process: https://github.com/pulumi/pulumi/blob/master/sdk/nodejs/automation/cmd.ts#L55

indeed

@best-summer-38252 you might wanna follow this issue: https://github.com/pulumi/pulumi/issues/4605

Nice and thank you @prehistoric-nail-50687 Im now subscribed. My take away to using file-based in object storage was to have tiny plans in anticipation of failure. Learning the SDK is a wrapper around the CLI dramatically lowered expectations. On how we can interact with Pulumi in our platform. I did not want to depend on k8s but perhaps I should be more open tech like Crossplane and OAM.

@best-summer-38252 IMO I wouldn't expect anything big from OAM. And Pulumi is opensource, you can do anything with it.

@famous-leather-94346 as in make a TS native port instead of the CLI wrapper? I dont think that is a realistic contrib and it legit disappointment dispite the open source components. Pulumi's messaging around the Automation SDK was not a CLI wrapper. As for the the OP, any ideas on exposes the state internals in the CLI so the automation SDK could use a function rather than a object storage URL for the backend?

As for the the OP, any ideas on exposes the state internals in the CLI so the automation SDK could use a function rather than a object storage URL for the backend?

The internals (and CLI) are all written in go so this would have to be implemented across many components.

Right. It not a matter of opening PR to scratch my own itch, it is inherent in the design. Lots of smart people have help create Pulumi and the Automation SDK. So Im questioning my desire to treat Pulumui state needs similar to my application state needs (db, redis, etc) vs treating it as repository more similar to an artifact store (GCS, S3...). I think there is an opportunity to speed things up but I more concerned recovering from a failure in the file based & repository-style state treatment. I think there are potential work-a-rounds. The disappointment with the CLI wrapper approach is: more about the next case(s) requiring work-a-rounds?

honestly i'm not really sure what you're asking - have you tried using it and has it failed you in any way?