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

not really sure what you want to achieve but if you just want to use pulumi to configure LOCAL k8s cluster, you can use local state backend

see: <https://www.pulumi.com/docs/intro/concepts/state/#logging-into-the-local-filesystem-backend>

Thanks <@U0288KYUB7C> that's what I suspected. Its just cumbersome as people will need to login and logout depending on what you are doing. The idea is to have consistency with deployments. Whether I deploy yaml/helm to a local env vs our staging and prod. I would prefer it either all uses pulumi or not

do you want to deploy the same project to local envs as well as staging/prod?

I think you can specify the state backend in `Pulumi.yaml` file but I’m not sure you can do the same on stack level.

<https://www.pulumi.com/docs/reference/pulumi-yaml/> (see the `backend` parameter)

another option I’d check, I’m pretty sure it was possible to override this using env variable

so in case of local development, I’d wrap this in a shell script that would use that env var

Ah awesome, that could actually work nicely. Let me give that a try thanks

see <https://www.pulumi.com/docs/reference/cli/environment-variables/> (`PULUMI_BACKEND_URL`)

so normally you will use Pulumi Service (or other remote state backend of your choice)

and in case of local development you’d use:
```PULUMI_BACKEND_URL=file://./local-state.json pulumi up -s local```