No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

Yes - you should be able to pass `pulumi update —config` to include configuration along with an update. See <https://pulumi.io/reference/cli/pulumi_up.html>. 

Does that merge in with the config or replace it entirely?

The config flag for `update` is documented as `-c, --config stringArray`. What does `stringArray` mean when called from the command line?

I took a guess and it appears it somewhat works, though the result is unexpected. I ran this command:
```
pulumi update --config 'cloud-aws:externalVpcId=asd'
```
And it actually updated my stack config file to contain `cloud-aws:externalVpcId`. I was expecting that it was merge in my CLI config options in memory and not actually update the config file.

Ahh - yes - in the current form this has the same effect as `config set` along with `update`. 

Curious to understand the scenario that motivates you to want to set configuration on the update but not persist it?  How will you know what to do for the next update?

I want to use `cloud-aws.Service` with a VPC created in code and the only way to configure that is via the config file. My plan was to create all my other infrastructure in project1, mark all the required `externalVpc` config params as exports, and use them to `update` the project, project2, that contains my `Service`. Because the resources in project2 depend on project1, project2 cannot and should not be deployed without project1 being deployed.

As a side note: I expected the `--config` flag to do the merge in memory rather than mutate the file because if I wanted a file mutation I would've just used `config set`.

I see - yes that makes a ton of sense. 

Really we need to support the ability to create an instance of the cloud framework parameterized in code instead of config. That’s something we’re looking into. 

Feedback on `pulumi update —config` being a little surprising makes sense too. 

Note - although it’s a little fragile - I’m pretty sure if you imperatively set  `cloudaws.config.externalVpcId` prior to constructing any resources from cloud that depend on the network, you can override this in code. I recall working with a user who was doing this a couple months ago. 

(This is exactly what we want to support in a more first class way as part of <https://github.com/pulumi/pulumi-cloud/issues/601>)

Cool, that feature would simplify life a lot! I'll give your suggestion a try tomorrow. Thanks. 

I assume I need to do the imperative set in an `.apply`.

Wait were you saying I'd be able to merge both of my projects into one and set the `externalVpc` params prior to constructing the resources that require the network?

Because the `cloud.Service` does not have any implicit dependencies on values from other resources, I believe I need to add some resources to the `dependsOn` list, assuming that does what I expect :slightly_smiling_face:

Trying that out now. Annoyingly, Pulumi still creates a default-vpc because it doesn't know that the externalVPC params are going to be set later.

This approach did not work. The `cloud.Service` was created in the default-vpc that Pulumi created.

Hmm - okay - that's a shame.  Definitely makes <https://github.com/pulumi/pulumi-cloud/issues/601> even more important.