Can anyone tell me which language makes pulumi most performant? If I want to minimise the size of my CICD runners which language should I write pulumi in?

I would assume writing it in pure yaml https://www.pulumi.com/docs/iac/languages-sdks/yaml/

The AI tells me it would be golang, I can do some testing. But are there any stats, or anecdotes. My basic CICD runners use a t3a.micro to run aws cli commands which works well. But to run pulumi up for typescript projects I've needed to move to c5d.large it was a while ago and I can't remember how many other sizes I tested etc. but it would be nice to be able to use the micros

because AFAICT it doesn’t depend on any external libraries (other than the provider plugins which the CLI still downloads / uses when running in other languages). to run

pulumi up

with nodejs/any other lang, you need the library support for those languages and to be able to run the code for those languages in a separate process. if you run

pulumi up

with pure yaml, it gets applied directly by the pulumi CLI

That seems reasonable. I'll have a go at translating one of my stacks into yaml and do some testing.

The performance of the Pulumi programs is almost never a factor in the overall performance of a deployment. The language of your programs doesn't affect the engine: it's always the golang one. And almost all of the run time is either within the engine, or waiting for API responses from the cloud. Choosing your Pulumi program language for performance reasons falls well within the realm of "premature optimization". Developer preference and associated build tools / tool chains are much more useful considerations.

node is pretty memory hungry which i would assume is why he had issues running on a t3a.micro and npm install can eat up resources pretty quickly. it seems like a reasonable guess that you could have perf issues on that small of an instance that’d be resolved by running via go or yaml. but i agree it feels like overoptimization

I feel like the performance of development (both writing the apps, and more importantly, writing the unit tests) in choosing TS or Kotlin over anything else, will win every time. I run Pulumi on T3as and have no issues with performance: the slowest part of my build chain is, by several order of magnitudes, my CI's handling of local runners. My 4s CI deployments might take 3s on my local machine, but they're wrapped in a 45s download-all-the-caches-and-start-the-container chunk of time. So optimizing 1s out of that is absolutely pointless.

thanks for the replies. Jason is right about the node and the memory issues. I have not come across bun before. The reason why the optimisation is necessary is that in order to have snappy deploys it's nice to have the CICD agents running all the time so there's no container startup time. This is why the micros are useful as they are on 24/7

Yep. Container startup time isn't relevant (it's measured in microseconds) but container host startup can be relevant. And EC2 startup time is definitely a thing. If you've already got TS code written, I would suggest looking at both bun and tsx; you may get enough bang out of one of those that you can save yourself the redevelopment effort.

thanks tenwit, good advice. I will check them out.