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 deployment1 Reply
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?