We’re trying to move the db configuration for a service, into pulumi. Our issue is that in order to configure a DB you’ll need to connect to it. When the pulumi client is running on a machine with access, that’s no problem, like through a VPN. But in Github actions CI we want to also deploy, but the runners don’t have access. Now we can seperate this step into a seperate stack like qa-db-setup to be run manually, for example. But I’m wondering if there is a nicer pattern for managing RDS database setup with the pulumi postgres provider, to only run in certain envs but not the others?

One option would be to consider moving your db setup logic to out of the “runner” - e.g. the example here provisions a lambda which can be invoked separately or as part of the deploy: https://gist.github.com/lukehoban/5c168258b641368dcccc7810dc454ca9

@sparse-park-68967 Thanks for the example, interesting approach, also seems viable.

https://medium.com/pixel-and-ink/running-database-migrations-in-aws-fargate-with-pulumi-eba56a7bf5e4 This is my approach to DB migrations