Hi, whenever I run my debug stack, I noticed it takes down my nextJsSite, am I doing something wrong? Is this expected? I can run my localhost in it's it place but even if I end my debug session it will stay in that state until I re-release. Looks like this:

I think you can't have the same stages locally and deployed. i.e. locally I work on

local-amazingproject

. if I run sst deploy, that stage will be deployed. if I run sst start, it'll take the deploy down and get back to work locally, as it does with lambdas and etc. at least that's what I think is happening to you

Thanks for the insight, hmm makes me wonder if my frontend should not be part of the sst.json but split out into it's own. As I like the overriding of external API route whilst debugging, so it would be ideal if my frontend stayed up and ran against the debugging API layer. Or if there is a way to say when the debugging ends re-start up the external nextjs site 🤔

We recommend to use different stages for local development (ie.

sst start --stage frank

) and live (ie.

sst deploy --stage dev

)

Hmm interesting, so if I was to use a different stage, this would mean I would get a completely separate environment right? I.e. the live

dev

backend wouldn't get altered to use my handlers With disablePlaceholder, would that mean I can use the live lambda development without interrupting my frontend?

if I was to use a different stage, this would mean I would get a completely separate environment right?

Yeah, you’d sst start in

stageA

and sst deploy to

stageB

. The two stages can even be in different AWS accounts. For example, I run

sst start --stage frank

and that deploys to my personal AWS playground account. I actually don’t run

sst deploy

from my local. I would git push, and CI run

sst deploy --stage dev

.

With disablePlaceholder, would that mean I can use the live lambda development without interrupting my frontend?

Yes.

Cheers @Frank, thanks for clearing it up. Both have their advantages, quite interesting