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

we split them apart for the assurance that an app stack wouldnt tear down the cluster if there was some bug, to speed up refreshes and updates and yeah to decouple the multiple app stacks from its infrastructure

we ended up having a ton of additional things like nginx, cert-manager, aad-pod-identity, kured etc

Sounds about right - do you just have multiple folders each with a project then?

we just put cluster.kubeConfigRaw in a keyvault from the cluster stack and then load it in to create a kubernetes provider in each app stack

but there are StackReferences now which is probably more sensible

I generally keep them all in the same stack for local dev / prototyping, but would also suggest splitting them up for production use cases.

I'd use separate stacks for the very reason you suggest in the next post---possibly being able to deploy the app(s) locally _or_ to a production-quality cluster in the cloud.

Thanks for the input all. Perhaps a follow on topic, how do you manage k8s contexts? Do you copy the kubeConfigRaw from your infra stack to your app stack so you can use it?