Deployment Error
Hey Wasp community! 👋
I'm deploying an OpenSaaS app to Fly.io from my M1 MacBook Pro, following the standard deployment docs:
1. Ran:
wasp deploy fly launch myApp dfw
2. Set my environment variables (Google OAuth, SendGrid)
3. Updated OAuth redirect URLs in Google Cloud Console
The deployment seems successful, but I'm getting CORS errors when trying to access the app:
Access to XMLHttpRequest at 'https://myApp-server.fly.dev/auth/email/signup' from origin 'https://myApp-client.fly.dev' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
I've followed the deployment docs exactly and avoided any manual configuration since Wasp is supposed to handle this automatically. Has anyone else encountered this CORS issue with Fly.io deployment? Any suggestions that don't involve manually editing configuration files?
Thanks! 🙏17 Replies
Hi @ein. 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 information provided in the knowledge sources, it appears that you're encountering a common CORS (Cross-Origin Resource Sharing) issue when deploying your Wasp app to Fly.io. This problem often occurs when the server is not properly configured to accept requests from the client's domain. Let's address this issue step by step:
1. First, ensure you're using Wasp version 0.12.4 or later. There was a bug fix related to imports in this version that could potentially affect deployments. You can check your version by running
wasp version and upgrade if necessary using the command provided in the Discord support thread.
2. The most likely cause of your CORS issue is that the WASP_WEB_CLIENT_URL environment variable is not set correctly on your server. This variable is crucial for Wasp to properly configure CORS headers. According to the Wasp deployment documentation, you need to set this variable to the URL where your frontend app is running.
To fix this, run the following command:
Replace myApp-client.fly.dev with your actual client app URL.
3. Additionally, make sure you've set the WASP_SERVER_URL environment variable to your server's URL:
4. After setting these environment variables, you'll need to redeploy your server for the changes to take effect. You can do this by running:
5. If you're still experiencing issues after these steps, you might need to customize the global middleware for your server. You can do this by adding a middlewareConfigFn to your app declaration in your main.wasp file, as described in the Wasp documentation on configuring middleware.
Remember, Wasp is designed to handle CORS configuration automatically, so manual edits to configuration files should not be necessary in most cases. If you continue to experience issues after following these steps, it might be worth creating a minimal reproducible example and sharing it with the Wasp community for further assistance.
Discord support thread
Wasp deployment documentation
Wasp middleware configuration documentation
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @ein, 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?It's likely because there's a mismatch between any of the following:
(1) Your DNS records;
(2) Your env variables.
I had to look through mine with a fine tooth comb to find the issue the first time. Now, I just input the info into Claude (obvie leave out sensitive API keys like Stripe), explain the problem, and ask Claude to find the mismatch.
Also check your fly deployment files to ensure they match the above.
Would DNS records be an issue if i'm just using the turnnkey fly.io domain out of the box?
Yes, you need to ensure the DNS records are pointing to the correct places for both your front end and back end.
I definitely recommend inputting the data into Claude and asking for the solve. It took me days the first time, and the second time, it took me about a day.
Whatever you do though, I wouldn't try and manually update the CORS files. I went down a whole rabbit hole trying to adjust them, and it didn't help. I know the bot is suggesting that as an option, but my understanding is that OpenSaaS is really supposed to work out of the box.
How do I check/ensure the DNS records are pointing correctly for these default Fly.io domains? I thought Fly.io would handle this automatically when using their .fly.dev domains, but it sounds like I still need to verify the DNS configuration?
Could you walk me through how to check this? I'm using the domains created by
wasp deploy fly launch myApp dfw without any customization.
Looking at my secrets list, I see all the automatically set Wasp variables:
- DATABASE_URL
- JWT_SECRET
- WASP_WEB_CLIENT_URL
- WASP_SERVER_URL
- PORT
But I can't see the actual values to verify they're pointing to the correct URLs. Is there a way to check the values of WASP_WEB_CLIENT_URL and WASP_SERVER_URL specifically?
I'm wondering if these might have incorrect values causing the CORS issue, even though they were automatically set by Wasp during deployment with wasp deploy fly launch myApp dfw.
I've been relying on Claude for solutions up to this point, but it’s taken me down some confusing paths. I’m trying to step back, slow down, and carefully work through this final deployment error. I’ll be so relieved once I find a fix.Wohooo @ein, you just became a Waspeteer level 1!
I'd have to dig through my Claude logs, which I won't be able to do until next week. But happy to share once I have the results. As an alternative, I ended up switching to Heroku and Netlify (I ran into some dependability issues with fly, and it was a bear to set up), and as of this AM, I have relatively robust notes on it ready to go. I can share those rn.
I'm at the point now, where I can deploy on Heroku/Netlify in <5 minutes every time.
Found something interesting in my server logs. The server is listening on port 8080:
Server listening on port 8080
But Fly.io is expecting it on port 3000:
[PC01] instance refused connection. is your app listening on 0.0.0.0:3000?
This seems to be happening with the default Wasp deployment - I haven't manually changed any ports. Could this port mismatch be causing the CORS issues? How can I fix this while staying within the OpenSaaS deployment guidelines?
Oh cool, i'de love those notes!Yeah, that's it!
Wohooo @AC, you just became a Waspeteer level 3!
That was one of the last errors for me too, if I recall correctly. You have to change the port in the fly-generated deploy docs, if I recall correctly.
I think that just fixed. holy cow
Yay!
Just hope it doesn't break again because of fly outages, haha
Yeah If so I'll hit you up for those notes.
Thanks for the hand-holding / getting me back on track!
Really appreciate it.
No problem! Happy to reduce the deployment pain.
Hey @AC, thanks for the help (again)!
@ein Glad you got it working
@miho Check this out, is this normal? Why is it listening on a different port by default?
Yes, this is an open issue for us, we have this PR sitting here: https://github.com/wasp-lang/wasp/pull/2403
GitHub
Force internal port to 8080 by jturner · Pull Request #2403 · wasp-...
Description
This is a proposed fix for #2398. This is similar to a fix that was made to the client setup. Another option would be to change like 120 to PORT=3000 but my guess is older version of fl...