No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

Evan, please correct me if I'm wrong. My understanding is that the host we are spinning up is taking over some responsibility from the pulumi CLI in order to have control over the "pulumi function" - the delegate that is instantiating resources.

We are effectively short circuiting that delegate. Where the CLI would be looking at local files based on some parameters in order to build &amp; execute that delegate, we are simply executing the inline delegate we were given regardless of parameters. That's why we only need to implement the `Run` part of the proto

<@U01E602D5JA> that is a pretty good analogy.

Pulumi itself is a series of gRPC services:
1. Engine - orchestrates the entire update process, persists state
2. resource monitor - handles creation requests that come from the engine delegating to various cloud providers
3. Resource Provider - for example aws, azure, gcp, knows how to create individual cloud resources
4. Language Hosts - Know how to execute a pulumi program in a given language. 
Traditionally, all of these services are written in Go. You can see here the <https://github.com/pulumi/pulumi/blob/master/sdk/dotnet/cmd/pulumi-language-dotnet/main.go#L483|dotnet language host> that's written in Go. It sets up the necessary environment variables and config and then runs the dotnet binary via <https://github.com/pulumi/pulumi/blob/master/sdk/dotnet/cmd/pulumi-language-dotnet/main.go#L502|dotnet run>.

With CLI driven programs, the CLI manages the lifecycle of an update including the lifecycle of the program that runs.

With Automation API, the dotnet program manages the lifecycle of the CLI and takes over responsibility of the `LanguageServer`. The gRPC language server is reimplemented in dotnet so that the delegate runs in the same process as the containing automation api program. You can set breakpoints, debug, etc.

&gt;  What is the Pulumi CLI doing that we can't just skip gRPC altogether?
The pulumi CLI and engine is hundreds of thousands of lines of Go. This gRPC approach allows us to have language native programs (`dotnet run automation.cs` `node index.js`, etc) while only having to reimplement LanguageServer. Getting rid of the Pulumi CLI dependency would more or less require reimplementing the entirety of pulumi in a particular language which is not a practical possibility.