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

enabling `debug` and using `-v9` I can see the following messages:

```deployment_executor.go:259] deploymentExecutor.Execute(...): incoming event (nil? true, Error: an unhandled error occurred: Program exited with non-zero exit code: -1)

step_executor.go:364] StepExecutor worker(-1): StepExecutor.waitForCompletion(): waiting for worker threads to exit

step_executor.go:364] StepExecutor worker(-2): worker exiting due to cancellation

step_executor.go:364] StepExecutor worker(-1): StepExecutor.waitForCompletion(): worker threads all exited

deployment_executor.go:303] deploymentExecutor.Execute(...): step executor has completed
error: an unhandled error occurred: Program exited with non-zero exit code: -1

deployment_executor.go:161] deploymentExecutor.Execute(...): exiting provider canceller

ignore.go:44] Explicitly ignoring and discarding error: rpc error: code = Canceled desc = grpc: the client connection is closing```

I don't see anything in that debug output that screams memory issue :thinking_face: Also it looks like the errors are occurring in golang, not TS :confused:

In any case, by default, NodeJS's runtime engine has a cap of 1300MB heap space on 64 bit systems, regardless of how much RAM is actually available. You can override it by setting the NODE_OPTIONS environment variable inline with your pulumi  command (or set the envvar outside of this step by other means):
```NODE_OPTIONS="--max-old-space-size=3000" pulumi preview```
Pulumi might already be overriding this value internally, or it might not be a memory issue at all -- so this additional option might not have any effect.

You can read more about `max-old-space-size` here <https://stackoverflow.com/a/64409997>

I tried setting `NODE_OPTIONS` but still experienced failures

I also noticed when running in docker desktop memory consumption goes up over 3GB during the preview and when resources are getting created drops to around 100MB, that's why I suspect the TS build process can be the problem (considering this needs to happen before resources are created/updated).