@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 wasp deploy fly launch.

Since Wasp automatically sets the following vars (below) via the deploy command, it would be best if we informed the user about this:

• in the "Deployment" docs
• in the "Env Variable" docs
• in the console after running wasp deploy fly launch

https://github.com/wasp-lang/wasp/blob/main/waspc/packages/deploy/src/providers/fly/setup/setup.ts#L116

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}`,
    ];

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 .

I pushed all the envs via terminal. But when you are sending a password with spaces (Google email password) it screws it up if quotes aren't included. So I set it directly on the fly dashboard.

It was a very simple issue, that I think a more experience coder would know. Maybe as a suggestion make it easier to set secrets/ pass along envs?

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.

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.

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 .env.server be pulled automatically and set through fly cli? I can't imagine a scenario where you wouldnt want these to match anyway

@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.
This separates dev activity from production activity, ensuring you don't mess up something in production while doing devleopment, and also ensures that leakage of dev keys (which every dev on the has access to, and on their machine) doesn't compromise the production.

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:

1. Manaing env vars per environment (dev, stage, prod)
2. Safely sharing dev env vars among the team.
3. Safely setting and managing prod env vars.

(3) is usually done by using cloud provider's secret manager solution, e.g. AWS secret manager.
(2) can be done nicely via solutions like https://dotenvx.com/ or Hashicorp's Vault.

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!