What pattern are folks using for duplicating and a...
# general
What pattern are folks using for duplicating and amending their default provider configuration? I need to declare a second provider with same settings as default, but with a different region. Deploying locally is different than in CI.
Copy code
let awsProviderDefaults;
if (!process.env.AWS_ACCESS_KEY_ID) {
  aws.sdk.config.credentials = new aws.sdk.SharedIniFileCredentials({ profile: awsConfig.get("profile") });
  awsProviderDefaults = { profile: awsConfig.get("profile") };
} else {
  awsProviderDefaults = {
    accessKey: process.env.AWS_ACCESS_KEY_ID,
    secretKey: process.env.AWS_SECRET_ACCESS_KEY,
    token: aws.sdk.config.sessionToken,
Copy code
const awsUsEast1 = new aws.Provider("east", {
  region: "us-east-1",
Ahh yes, but this still fails because the default provider has a
and env vars don't override profile any more.
I've resorted to using this command in CI before `up`:
Copy code
pulumi config rm aws:profile
We do the opposite. Require that aws:profile is always set. Lint rule to check the stack file. Disable default provider, pass provider everywhere. And when constructing providers, always provide
profile: awsConfig.require("profile");
And if we need to change the profile for an environment, we do that in the build script or whatever, before calling Pulumi.
"pass provider everywhere" The part I hate 😞
That said, it's probably the better strategy long-term
The other downside of using an AWS profile in CI is that the secrets would be written to disk
I'm a big fan of being OTT explicit. Allowing people to guess providers isn't convention-over-configuration, it's just making it easier to hide bugs..
Our AWS profiles only ever contain session creds, max duration an hour. We often have "permanent" profiles, but they use role_arn and source_profile. The base profiles are always temporary creds.
And we use OIDC for our CI-initiated deployments. That was great, when GitHub announced that.
Yeah, I think long-term it's the best strategy given the default provider being tightly coupled with the Stack config. The problem isn't even the verbosity, but the cases where we have abstractions that will make passing the explicit provider a bigger chore.
Your setup sounds similar to ours
We have a base library that builds AWS providers for us, based on things like well-known account IDs and stack names. We construct providers wherever needed.
Ahh, interesting. We have similar, for helpers and custom component resource definitions (