In our shop we don't need or use

StackReferences

so we just place all projects in their own directory in our S3 bucket and that works for us.

Yeah, I would be the same, each project would be independent and shouldn't need to use StackReferences of any kind either.

I think you can do it the same way as I just mentioned - except locally you may need to actually create those project name directories. You don't need to do that in blob storage because it just treats path segments as virtual directories.

Another thing to keep in mind when using file state backends is you lose the locking functionality on stacks that prevent concurrent updates. There is a new environment variable you can use to enable it but currently by default it is disabled

I will say that it is a lot easier to test this or even use file state backends in practice, if you completely drop your

pulumi login

usage. Start specifying your backend in the

project.yaml

. Because as you discovered when you use

pulumi login

it sets that file state backend as your current backend in the

credentials.json

file in your user directory and then it is very easy to forget that it will preserve that login across directories and pollute your backend

one last thing, I guess, where/how does the project.yaml support the s3/azblob details instead of using a credentials file?

I guess to ask this more clearly, all examples show I NEED to set the ENv variables for the storage account name and key. Are those not something I can add under the backend section of the config as well? Having trouble finding that documentation

If you need environment variables though, could you not just place those things in the stack config file and then set the environment variables before instantiating your provider?

I'm sorry my experience is with AWS - so for Azure requirements I might be shooting in the dark

I don't think AWS needs required env vars for the s3 backend usage. Or at least without them it defaults to inferred auth. So that's where our disconnect is. My "drop pulumi login usage" recommendation was from personal experience when developing locally - because I will

pulumi login ...

in one pulumi project directory, and then

cd

to another project directory and forget that file state backends don't differentiate and that I need to

pulumi login ..

again. Me setting the

backend/url

in the

project.yaml

is my way of not causing issues when I'm developing locally. In a pipeline, this is a non-issue because you can just have it

pulumi login

everytime - or in automation API you can put the

backend/url

in the

project.yaml

and just set your ENV vars on the workspace. But locally, if those environment vars are required for the azure blob backend, than my recommendation to ditch the pulumi login usage wouldn't work for you - because you also need to remember to change the values of those ENV vars and those can't be set in the YAML files. Unless of course all of your azure blob backends use the same ENV var values, in which case just setting the

backend/url

with the project name suffix in each project YAML will be fine because you don't ever need to change the ENV vars.