One repercussion of this is that this will supersede what you have specified in ~/.aws/credentials.

One option would be to move this into comm-dev, however, nix develop already denotes a development environment; so having it use local configuration doesn't seem too far off the mark.

Curious on how this might affect a workflow that relies on an externally running staging environment.

This should only have an effect if you're running a service (e.g. identity) locally. Otherwise it shouldn't affect things such as keyserver connecting to a particular service.

If somebody wanted to access a staging environment on AWS, would they need to set these envvars in eg. their ~/.profile?

No. That's a separate issue. This mostly affects code which "loads aws credentials from environment". Such as https://github.com/CommE2E/comm/blob/ee8762ce834ca154fa61f4f0bdd88b927256f3b7/services/blob/src/config.rs#L54

There's 3 possibilities here:

• Have valid aws credentials in ~/.aws, and localstack just won't use these, but will make calling code which uses aws happy (e.g. aws_sdk crate). However, it's not clear if you're using localstack or actual aws.
• Have phony aws credentials in ~/.aws. Localstack won't use these, but will still make the calling code happy. However, this will overwrite legitimate aws use cases for a developer.
• Set phony environment variables (this diff). Localstack doesn't care either way, but will make the calling code happy. These are just set for development, so shouldn't exist when deploying services.