. I really like this diagram from the docs as a way to explain all the various terms in a visual way: https://www.pulumi.com/images/docs/pulumi-programming-model-diagram.svg
... depends on your programming language). The stack's config is defined by the
file, while the project config is the
, it tears down the infrastructure (both the resources and the state) in the current context--the stack you have been working on. It doesn't delete the stack's configuration from Pulumi. To remove that stack's configuration from Pulumi, you use
. Be careful as you'll have to rebuild the config from scratch if you do that!
pulumi stack rm
on all of the stacks, you've wiped all of the configurations, and the project is no longer needed as it doesn't mean much without a stack to attach to it. You still have the project on your local machine (or in a codebase somewhere), though, and can kick it back off by initializing a new stack and adding configurations.
pulumi stack rm
, and maybe feature branches. I think you call this monolithic? The alternative seemed to be to make a project and stacks for every git repository that contains something that gets deployed. But, for example, this would make a web app difficult to configure when it depends on other apps (e.g., HTTP APIs) that are deployed in other stacks of other projects. Is there a way to manage this configuration?
file, which got generated by the
command, and a
pulumi new python
file, which got generated in that same command because I defined a first stack of
file got populated by me running the following command:
for each one of those pairs. I could alternatively have run
pulumi config set <key> <value>
, but I'd recommend doing the standard command one by one first until you're comfortable.
pulumi config set-all