Throwing some ideas here, maybe it’s possible to do already, or could be added to SEED. In my organization we have

development

,

staging

and

production

AWS accounts, each of them are totally isolated. Now, from SEED, all the PRs are deployed to

development

, and sometimes I need to promote stuff to

sandbox

due some limitations on the legacy platform. Now.. I would like to have a way to promote my

prXXX

to other stage, without the need of creating it manually. It’s hard to explain, but check this screenshot from my current setup on SEED, I want to promote

pr131

to

staging

, but not to one of the pre-defined environments, instead create a new

pr131

under

staging

. This makes any sense?

Oh.. like a button that does “Create pr131-sandbox stage and Promote to it”?

Not entirely sure I understand but I thought I'd share our set up in case it helps. We don't use the promotion feature in Seed, instead we have stages connected to a dev/staging and master branch. When we create a PR we can deploy it on the staging stage, and when it gets merged to master/main, it'll automatically deploy there. The reason we do it like this is that we need to have separate customer deployments in each stage for the same repo as they have their own env vars/configuration and different AWS accounts. So no promotion is done in Seed, promotion happens via merging in Github

@Frank yes, something like that, what I need is to have different stages of my app not only in

development

but also in

staging

. Now with SST, my plan is to have something like…

<http://pr131.dev.mycompany.com|pr131.dev.mycompany.com>

, where the tech-lead can actually test the implementation from a developer, but also I would like to have…

<http://pr131.staging.mycompany.com|pr131.staging.mycompany.com>

where the QA team can test it too. The reason is what I said before, our staging environment it’s connected to a legacy platform which is “not ready” in

dev

. But well, not sure if this makes any sense to others too, maybe there are other use-cases of why other people want to deploy a PR to different AWS accounts.

I take the same approach - specifically control everythign through github and not through promoting builds in SEED