Is there a way in the Automation API to run a particular update asynchronously (specifically in Go)? An example would be in the Pulumi over HTTP example, you may want to create/update the stack in the background and then they can check for updates. So really two questions: 1. Is it possible to kick off the automation in the background (or should I just queue up a Goroutine to do this)? 2. For a particular stack, is it possible to get the status of the current update (or even of an update with a particular ID)?

So where I’m at our work flow is like this: • user hits API to start deployment • API fires off a message at a message queue • Worker service picks up that message • Worker service does a bunch of business logic • Worker service uses the Automation API, and captures the logs in real time • API exposes those real time Automation API logs via web socket so you can watch deployment progress

Is it possible to kick off the automation in the background (or should I just queue up a Goroutine to do this)?

Yes, queueing up a goroutine is the right thing to do here.

For a particular stack, is it possible to get the status of the current update (or even of an update with a particular ID)?

What do you mean by "status"?

<http://stack.info|stack.info>

will return some minimal information, like whether or not an update is currently in proggress on the stack.

stack.history

can show that same info over the last N updates. https://pkg.go.dev/github.com/pulumi/pulumi/sdk/v3/go/auto#Stack.Info https://pkg.go.dev/github.com/pulumi/pulumi/sdk/v3/go/auto#Stack.History If you are looking for an API to poll more detailed update metadata using just an ID, that doesn't exist yet. If you have ideas on info you'd like to see, please do open an issue with more details: github.com/pulumi/pulumi/issues/new If I were to build something like this into my own app, I'd probably do something like the following: 1. submit updates into an async queue, store a task ID in sql 2. have N "automation api workers" consuming work from the queue and performing updates 3. each worker that starts an update consumes the structured event log. It reads structured events, and turns them into some format appropriate to display to your end users, stores that rollup in the SQL db with the associated task ID that your application can query.

Thanks @lemon-agent-27707 @bored-oyster-3147 - that’s very helpful, and the direction I was planning on going in, but good to see the confirmation.