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

It does not probably the way you expect it. You can, however, pass in structured configuration as serialized json strings.

I guess I’m missing something about your suggestion. Do you have a small code snippet to expand on your thinking?

There are some rough edges, for instance: <https://github.com/pulumi/pulumi/issues/6352>

But it is possible to work with structured configuration as long as you handle the (de)serialization in your code. Would welcome contributions to make this better if you feel inspired, but it’s not in our list of immediately prioritized items.

&gt; I guess I’m missing something about your suggestion. Do you have a small code snippet to expand on your thinking?
I think the issue I linked might be helpful to understand what goes on, but essentially to set a map you would have to set the top-level config key
```s.Workspace().SetConfig(ctx, s.Name, "myTopLevelKey", ConfigValue{Value: "{'inner': 'foo', 'another': 'bar}", Secret: false})```
To get that config, you would have to get the top-level config:
```s.Workspace().GetConfig(ctx, s.Name, "myTopLevelKey")```
And then Unmarshal the resulting json string into a struct and then access the inner keys.

As I said, definitely not an ideal flow but it is possible to work around the current limitations using the pattern I described.

Context is this: <https://github.com/ringods/pulumi-resource>
This is a Pulumi integration with Concourse CI. To run Pulumi from Concourse, I have to create a binary accepting JSON from concourse on stdin and Unmarshal that to a Go type. I hoped that I could use `ConfigMap` at the right depth of my struct type so unmarshalling would be based on the `ConfigMap` type. But I guess I will have to intercept with a custom JSON marshaller.

<https://concourse-ci.org/implementing-resource-types.html#resource-out>

So, a substructure of the `params` I receive, would be additional stack config I would pass as-is via `stack.SetAllConfig` . At least, that was my intent.

Ah yeah that makes sense. Honestly this is definitely a thing I would love to improve but alas there are too many things!

It's even more difficult to support structured config in strongly typed languages like .net. I put a good amount of effort into trying to do that before we ultimately decided leaving deserialization to the consumer would be the safest way