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?Since these portal URLs are not something secret, it's okay if they are not in the
.env file and the current implementation feels okay to 😄
One thing to consider, we could upgrade our setup for env vars to be:
.env.client.production
and
.env.client.development
This way, you are covered for all use cases and you don't have to pass the variables every time you deploy, which you might forget.This is correct for all the env vars on the client (that they are not secret), so if we follow that argument, we could say we don't need .env.client at all!
So why do we have .env.client then? Because it makes it clear what is "env" specific and can be easily configured.
It also avoids having logic in the code that is explicitly checking in which env is code, because that can get tricky quite fast.
Which is why I am tempted to consider putting this stuff in .env.client .
.env.client.production idea -> that is an interesting idea indeed! Would that be committed to git then? I think this is something we can explore in the future. Even .env.client could be committed to git. And .env.client.local could be then what is not commited, and what you can use locally to override those default values.
We wouldn't want to offer something similar for .env.server though, since those are normally secrets (although don't always have to be) and could easily get committed to git, causing a lot of trouble.
Ok, I will create a GH issue with the .env.client.production idea, but that is not something we will have implemented super soon, so let's continue trying to figure out how to go about the stripe thing.
@Vinny (@Wasp) I think it will help if you can elaborate on how right now code decides which variable to use, prod vs non prod.
I think we will want to go with the env variable at the end though, and it is up to them to find they way to provide it to build command until we offer something like .env.client.production (they can easily do this with a single script if they wish).
I created an issue here (for .env.client.production idea, not the stripe env var): https://github.com/wasp-lang/wasp/issues/1953 .
GitHub
Introduce .env.client.production file · Issue #1953 · wasp-lang/wasp
They right now have to provide production env vars manually to the build command for the client, like REACT_APP_SOME_VAR_NAME=somevalue npm run build. This can get tedious with more vars, and they ...
ok this makes sense. i like it.
i will make an issue for it and make sure it gets outlined in the deployment docs, as well as some comments in the
.env.client file giving them a heads up.
btw what would then be the recommended way to add these client vars if using wasp deploy fly?
would it be wasp deploy fly deploy --client-secret CLIENT_ENV_VAR=asdf... ?-
wasp deploy fly deploy --client-secret CLIENT_ENV_VAR=asdf... would result in adding those variables to the server serving static files. The React app running is the browser has no access to those variables since they're all the way on the server.
- Those variables need to be defined the moment of building the React app - in this case, when wasp deploy fly deploy is started.
- So you'd write it like this CLIENT_ENV_VAR=asdf wasp deploy fly deploy
Ofc, CLIENT_ENV_VAR needs to be named REACT_APP_CLIENT_ENV_VAR for Vite to pick it upwould this also work for
wasp deploy fly launch?
i.e. the initial deploymentYep, I've tested with
fly launch 😄noice
thanks
Yeah, we should add this to the docs! @Vinny (@Wasp) keep in mind that I already did some doc improvements reagrding env vars -> not exactly this thing, but very close to it. And I did them on
main. So if you are doing improvements here, best to also do them on main.