This message was deleted.
# general
s
This message was deleted.
g
Right now, for local dev, the devs are storing state locally, and deploying from their own machine, with their own AWS account, for dev and testing needs. But in the CI/CD, we need a more persistent way of storing state, for our dev, staging, and production environments. So obviously,
file://
as a backend won’t do well there. 🙂
b
I guess if you're not sharing any of the infrastructure then you could use the local backend, but I would recommend using the Pulumi backend (which gives you extra features like access control and state locking) and if you really don't want to, then something like S3. Otherwise all your engineers are going to be working on their own version of the state
g
Thank you for the response @brave-planet-10645
👍 1
I’m aware of Pulumi as an ultimate backend, just wanted to do additional exploration. Regarding S3 buckets… we were thinking about simply putting the
s3://…
in our
Pulumi.yaml
project file (this file is checked into our git repo) and avoid the
file://
all together, but the thing is, every dev has its own AWS account, and only the account that created the S3 bucket would actually have access to it, and store state files via Pulumi. Additionally, the devs would have to create their own bucket, with a different name (since S3 buckets must be unique in name), and then we end up with another problem, where every dev would have their own Pulumi.yaml file, with their own backend set in it.
I guess this is one of the problems that Pulumi backend addresses, among others of course
b
You could create a central account that has an S3 bucket that they all have access to?
🤔 1
g
thanks, will take that into consideration too