-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make it clear in docs which env vars and how users need to set when deploying to production #2053
Comments
@vincanger opened the same issue (#2055) but a bit different angle, so adding that here: it's unclear which (server) ENV VARS are set automatically and which VARS users need to set themselves when deploying via Since Wasp automatically sets the following vars (below) via the deploy command, it would be best if we informed the user about this:
const secretsArgs = [
`JWT_SECRET=${randomString}`,
// NOTE: Normally these would just be envars, but flyctl
// doesn't provide a way to set envars that persist to fly.toml.
'PORT=8080',
`WASP_WEB_CLIENT_URL=${deploymentInfo.clientUrl}`,
`WASP_SERVER_URL=${deploymentInfo.serverUrl}`,
]; |
wasp deploy fly deploy
, provide guidance on setting server env varswasp deploy fly deploy
, make it clear which env vars get set and which ones they and how need to set
I am putting this one back for triage, people keep failing on this and I think we need to look into it sooner than later. Here is another instance of it: https://discord.com/channels/686873244791210014/1241745021955473548/1248364761092198521 .
We should improve the docs to have clear examples on how vars should be set, also make sure we mention the double quotes. |
We should do this also for the rest of the docs, not just Fly. It is also not super clear for Railway that env vars need to be set. We need to make this clear in general, for deployment. Here is an example of a user missing this for Railway also. |
wasp deploy fly deploy
, make it clear which env vars get set and which ones they and how need to set
I can confirm this is pretty frustrating, even for someone who works on Wasp every day. 😄 We could maybe even go a step further, detect the missing env vars on deployment (depending on which features they use), and give them a command for setting them. |
As a user this would be incredible. |
Can the env vars from |
@santolucito you don't want that because the ones in .env.server (their values) are to be used for development -> so test API keys, URL to the test database possibly, ... . In production, on let's say Fly.io, you will went to provide values that are for production only. What might be interesting is us figuring out which env vars are used in .env.server and then using that knowledge to help user when deploying to production. For example, check if they had set these in production, maybe warn about it. Although this is a bit tricky to pull of with 100% precision, so might be not worth doing it in this shape. |
That makes sense! Thanks for the comment. It does seem like an interesting area for wasp since (at least from what I can tell) wasp is all about organizing these cross-stack configs. I guess env var management is more of a cross team/dev config management issue. I wonder how this is handled by companies - are there tools for this or does everyone just hack something together? Sorry, getting a bit off topic from the original issue here. Really appreciate all the work y'all are doing! |
Certainly, we plan to to much more work on this area, regarding recommending best practices but then also implementing solutions for those. Super short, we can divide the problem into:
(3) is usually done by using cloud provider's secret manager solution, e.g. AWS secret manager. I hope in the future we will have a nice page in the docs where one would be able to read all about this and then learn how to do it in Wasp! |
We had a user struggling quite a bit with setting up env vars for their app while deploying it via
wasp deploy fly deploy
: https://discord.com/channels/686873244791210014/1241745021955473548/1241745021955473548 .The thing is, our docs at https://wasp-lang.dev/docs/advanced/deployment/cli are really not mentioning env vars much! They do mention setting up that one for client URL, but don't at all go into setting other env vars. Since the idea behind
wasp deploy fly deploy
is that it should be quite streamlined, then we can't expect users to suddenly figure out they need to manually set those server env vars.We should:
wasp deploy fly deploy
and point them to confirm that by runningwasp deploy fly cmd --context server secrets list
, therefore also teaching them how to list existing secrets.wasp deploy fly cmd --context server secrets set WASP_WEB_CLIENT_URL=https://mycoolapp.com
. Explain to them they should be going through their .env.server and making sure all the stuff they have set there should also be present on the Fly cloud.EDIT: Actually, this also goes for other methods: Railway, even manually. Users often don't realize that they need to set the vars from .env.server on the production server. We need to make this very clear and show how to do it in different situations.
We should also catch when env vars are missing in production and write nice errors, for that we have separate issue though: #2086 .
The text was updated successfully, but these errors were encountered: