Is there anyway so set which aws profile to use fr...
# sst
g
Is there anyway so set which aws profile to use from the credentials file without having to set it every time before you run the start command? I tried setting AWS_PROFILE in
.env.local
but it says credentials missing whenever I start. Possibly a "profile" file in
.sst
like you do with stage if the default credentials are empty?
r
There's an environment variable you can set but I can't remember what it's called right now and I'm not in front of my computer. Can confirm shortly
It is on the docs for SST somewhere
t
Right now I do it through the env var
AWS_PROFILE
I set it in my package.json scripts
Setting it in .env won't work unless your shell is configured to autoload env files (know you can do this in zsh)
g
Hmm, that would require everyone on our team to use the same name for the profile then but that should be fine.
t
Ah yeah it does
otherwise it's up to them to run
export AWS_PROFILE=xxx
in the shell before they start
Let me think about how we can make this easier, I personally find this annoying
You can set a default AWS_PROFILE in the config but I find that prone to mistakes
If you name the profile
[default]
I believe aws-sdks will automatically use it
g
Yeah I normally set default to just be empty keys so it will fail because I want to make sure I am explicitly using the correct account.
Like I dont want to accidentally deploy one of my work apps to my account or one of my personal projects to my work account
t
yeah exactly
f
I think it makes sense to store the profile in
.sst
folder like @Garret Harp suggested.
I recall it has also been suggested that
sst.json
contains a mapping of Stage to AWS profile. I’m not sure if that makes sense.
m
Here is something that one user suggested on github. It is solving this problem plus, some advanced feature: profiles based on stage https://github.com/serverless-stack/serverless-stack/issues/167
looks like nice thing to contribute on this project 🙂
f
Thanks @Milos Glavinic, yup thats the thread i had in mind. 2 issues with the mapping approach: • the
sst.json
file can get bloated for teams with many stages (ie. 1 stage for each developer) • for PR workflow, each PR is deployed to a new stage and the stage name is often auto-generated (ie. pr233) It is tricky to define the stage names up front