Deploying to AWS
I've a request:
In https://wasp-lang.dev/docs/advanced/deployment/manually, could the instructions for deploying to AWS be added as well?
24 Replies
@The Brainiac we would certainly love to add them at some point, but didn't have the time yet! It would require some research to determine the optimal way to deploy to AWS, and then writing it down. Do you have experience with AWS, is this something you could potentially help us with?
My team specifically uses AWS.
I’ve deployed some dockerized bots to EC2, but have no experience with Wasp.
Today, was the first time I tried it via MageGPT.
Hey @Brainstorm, thanks for checking us out 😄
If you follow the manual instructions and build a Wasp app manually all the way through - you'll end up with two things:
- A node backend app in
.wasp/build/server
- A built-and-bunlded react app (i.e., just static files) in .wasp/build/web-app/build
You can deploy those two apps to AWS as you would normally deploy any Node or React app. Wasp is completely out of the picture at this point- it just helped you produce the apps.Got it,
This makes things a lot easier!
Wohooo @The Brainiac, you just became a Waspeteer level 1!
Yassss!!!
@The Brainiac did you manage to get the deploy working?
Wohooo @RichardHpa, you just became a Waspeteer level 2!
Are you also trying to do it? anything you are struggling with/
just getting started with it so nothing major yet. ive just never personally deployed to aws before
@martinsos 1 thing I have noticed is that maybe
customerPortalProdUrl and customerPortalTestUrl from the StripePortalUrls could be turned into 1 env variable. Just so it doesnt have to be manually changed when you want to deploy and then remove it again when you want to do local testing@Vinny (@Wasp) maybe for you ^
oh yeah, great idea. thanks @RichardHpa
hmm.. the only thing with this is that we're using it on the client, so in the end we need to add the prod url it before we deploy it anyway. by putting it in the contants.ts file, we can do a check and alert the user if they forget to define it
actually. I'm not sure why you'd need to add and remove the url before deploying. there are meant to be there and will change automatically if you're in dev or prod. why did you need to change them @RichardHpa
yeah just realised you probably dont need to change it, but it just seems like its something that could be env sepcific. Odd scenario but you could have 2 devs with different stripe accounts for testing.
ah that's true... I didn't consider that. What I could do is add
customerPortalTestUrl to the env.client file, as this is the one that could change. The app's prod url should always stay the same and could be shared between devs.
that's also kinda confusing though
I think i'm going to leave it because I can foresee devs forgetting to change it to the prod url before building (since client vars are added at build time) and deploying their client and then they've got the test url in the prod app
if you have a better solution though, I'm all earsYeah I get what @RichardHpa means, stuff like this sounds like something that you want to configure per environment.
If it is was on the server side, in .env.server, then I would certainly say that should be a single var, called
customerPortalUrl and that is it. Locally you would set it to test url, in production you would set it to real url.
Here it is a bit different beast because it is on the client, and env vars for client are provided during building (which happens locally or in CI), not set up there where it is hosted.
But still, it would make sense to use the same logic, I agree.
Ok, so it makes sense to have a single STRIPE_CUSTOMER_PORTAL_URL env var.
Then, when building your app, you would provide it. So you would do STRIPE_CUSTOMER_PORTAL_URL="production_stripe_url" wap deploy fly deploy or if building client manually you would do STRIPE_CUSTOMER_PORTAL_URL="production_stripe_url" npm run build as described here https://wasp-lang.dev/docs/project/env-vars#client-env-vars-1 .
This sounds "right". Although I get why we have it done different way though: it will always be either that test url or the prod url, they are kind of fixed, and you avoid the hassle of having to provide this URL during build time, and also to share the test URL among devs so they can put it in .env.client. So it does sound more practical I guess.
@miho any thoughts?