Setting NODE_ENV to 'test'
I am deploying my wasp app to fly.io for a testing environment. Eventho I set the NODE_ENV Variable in fly.io to 'test', my server thinks he is in production mode.
When checking my servers logs i see the following code being executed:
npm run db-migrate-prod && NODE_ENV=production npm run start
How can i manipulate this? I am using wasp deploy fly deploy for the test deployment8 Replies
Hi @Gwaggli. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Based on the knowledge sources provided, I can offer some insights into your question about setting the NODE_ENV variable for a testing environment on Fly.io using Wasp. However, the information available doesn't directly address your specific scenario.
The main issue here is that Wasp's deployment process seems to be hardcoding the NODE_ENV to 'production' during the deployment, which overrides your Fly.io environment variable setting.
Here are some relevant points and potential workarounds:
1. Wasp's deployment process: When you use
wasp deploy fly deploy, Wasp generates a Docker container for deployment. It appears that this process is setting NODE_ENV to 'production' by default.
2. Environment variables in production: According to the Wasp documentation on env vars, for server-side variables in production, you should set them using the deployment platform's methods. For Fly.io, this would typically be done using the flyctl secrets set command.
3. Custom modifications: There isn't a built-in way to change this behavior in Wasp currently. However, you might be able to work around this by modifying the Dockerfile that Wasp generates.
Here's a potential workaround, though it's not ideal and might require some experimentation:
1. Run wasp build to generate the build files.
2. Locate the Dockerfile in the .wasp/build directory.
3. Modify the Dockerfile to use your desired NODE_ENV value.
4. Use wasp deploy fly deploy --build-locally to use your modified Dockerfile.
This approach is based on the information from the Wasp CLI deployment docs, which mentions the --build-locally option.
Keep in mind that this is a workaround and not an official solution. It might break with future Wasp updates or cause other issues.
For a more robust solution, you might want to:
1. Raise this issue on the Wasp GitHub repository to request a feature for controlling NODE_ENV during deployment.
2. Consider using manual deployment methods where you have more control over the environment setup, as described in the manual deployment docs.
Remember, modifying the generated files is not recommended for production use, as it can lead to inconsistencies and issues with future updates. It's best to work with the Wasp team to find a proper solution for this use case.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Gwaggli, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?The only valid values for
NODE_ENV are "development" or "production"; you must use one of those.We haven't really thought of this before, to be honest. Why would you need
NODE_ENV=test specifically? Could you introduce a separate variable e.g. DEPLOY_ENV=test or smth like that to run different logic on the server if in test?FYI in JS apps, NODE_ENV !== environment your application lives on, eg development, staging, test, production etc. Developers often make this mistake. It's a configuration setting used for the build process which tells your bundler to do things specifically for production like removing source maps, minification, etc
Thanks for clarification! I will use a custom env variable 🙂
@Gwaggli why would you need that specifically? I have set up Wasp to deploy to Fly.io staging or production environments based on the GHA flags, and then I have separate secrets set for the two environments to make sure they do what they're supposed to
@Sergio Visinoni Yeah, I just thought it would make sense to use this NODE_ENV variable. But as pointed out by donmackinnon, its bad practice to do so. So I will just use a custom env variable to distinguish the environments.
TIL