Issues with deploying to baremetal
The Wasp application is deployed, but all requests (including static assets) are being caught by the catch-all route, resulting in a "{"message":"Catch-all route"}" response.
- Apache is configured as a reverse proxy.
- Node.js server (Wasp backend) is running on port 5555.
- Static files are present in the correct build directory.
We've tried updating the Apache configuration to serve static files and proxy only API requests. I can verify that the Node.js server is responding correctly to API requests.
The application works correctly in development mode with wasp start.
Static assets are not being served properly in production; loading for instance http://<mysite>/index.html or http://<mysite>/login is being routed to the catch-all route, seemingly intercepting all requests.
18 Replies
Hi @Conspyre. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Hmm, I don't know enough to give you a confident answer yet. However, I can tell you that there was a similar issue reported where the CSS was broken when using AuthUI + Tailwind, but it only occurred with
wasp start and not when the app was built and hosted as static files source (https://github.com/wasp-lang/wasp/issues/1764).
There was also a discussion about supporting static assets in a Wasp project, and it was suggested to have a special directory like server/assets/, and whatever is put there would be copied to the built server code while doing wasp build source (https://github.com/wasp-lang/wasp/issues/609).
For more specific help, I would recommend checking the Wasp documentation (https://wasp-lang.dev/docs) or asking in the Wasp Discord community (https://discord.com/invite/rzdnErX).
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Conspyre, 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?I've resolved the errors with deployment and have the server running via docker and client deployed via apache. Issue was solved by reviewing the find documentation, thanks. š
Howver, the deployment isn't fully functional. I am setting the SENDGRID_API_KEY when running docker to deploy the server, and it is the same API key that was tested and working on development. When I try to go through the signup flow, no e-mail is being sent, and signup cannot continue. What could I have missed @kapa.ai
Let me check the knowledge base for you. One moment! :books:
----------------------
Based on the information provided, it seems like the issue might be related to the email verification flow during the signup process. In Wasp, the email verification is done by sending a verification email to the user's email address and requiring the user to click on a link in the email to verify their email address source (https://wasp-lang.dev/docs/auth/email#email-verification-flow).
If you are in development mode and want to skip the email verification step, you can set the
SKIP_EMAIL_VERIFICATION_IN_DEV environment variable to true in your .env.server file. However, since you are deploying your application, this might not be applicable.
Here are a few things you could check:
1. Ensure that the SENDGRID_API_KEY is correctly set in your production environment. You mentioned that you are setting it when running docker, make sure it is being correctly passed to the application.
2. Check the server logs for any errors related to sending emails. If there was an issue with sending the email, it should be logged there.
3. Review your custom sign-up action if you have one. If there is an error in your custom sign-up action, it could prevent the email from being sent source (https://wasp-lang.dev/docs/auth/email#creating-a-custom-sign-up-action).
If you are still facing issues, I would recommend reaching out to the Wasp community (https://discord.com/channels/686873244791210014/1204832621176160286) for further assistance.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Conspyre, 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?@kapa.ai the server indeed shows why email are not being sent. But why is the catch-all route being hit? It is at the end of the main.wasp file.
POST /api/auth/email/signup 200 1.403 ms - 29
Catch-all route hit: POST /api/auth/email/signup
Let me check the knowledge base for you. One moment! :books:
----------------------
The catch-all route being hit after the
POST /api/auth/email/signup might be due to the way your routes are defined in your main.wasp file.
In Wasp, routes are matched in the order they are defined in the main.wasp file. If a catch-all route (route WildcardRoute { path: "*", to: WildcardPage }) is defined, it will match any path that hasn't been matched by previous routes source (https://discord.com/channels/686873244791210014/1112653557934592022).
If the catch-all route is being hit after the signup route, it might be because there is another request being made to the server that isn't being matched by any of the other routes.
To debug this, you could:
1. Check the network tab in your browser's developer tools to see if there are any other requests being made after the signup request.
2. Check the server logs to see if there are any other requests being made after the signup request.
3. Review your main.wasp file to ensure that all necessary routes are defined before the catch-all route.
If you are still facing issues, I would recommend reaching out to the Wasp community (https://discord.com/channels/686873244791210014/1204832621176160286) for further assistance.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Conspyre, 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?Have you deployed SPA + Node.js API server with the configuration before successfully? It should be a pretty similar setup š
1. Client app is just some static files that need to be served at
myapp.com and each different path should just serve the index.html which will then load the client router that will display the proper pages.
2. The server app is a Node.js app that receives request from the client app. Its root starts at / and if you have some sort of prefix in Apache e.g. /api you should strip it before it reaches the server app.
3. The routes in the Wasp file are client routes and shouldn't be confused with the operations and custom API server routes.Wohooo @Conspyre, you just became a Waspeteer level 5!
Hi @miho deploying web apps is somewhat new for me. What I know is "it works on dev" and I'm following pretty closely to the published docs. If I dig around inside of .wasp/out/build/server/src/index.ts and start drilling around, I can eventually find ./routes/auth/index.js from here, which seems to cover the /me route? I can't find anything in here that looks like it should handle the /api/auth/email/signup so it seems not to be surprising that the catch-all route hits it.
I wrote a deploy script, it's basically:
BUILD_DIR="$WASP_DIR/.wasp/build/web-app"
APACHE_DIR="/var/www/html/truthcraft_mk2"
rm -r .wasp
wasp build
cd "$BUILD_DIR"
npm install
REACT_APP_API_URL=https://mysite.com/api REACT_APP_STRIPE_CUSTOMER_PORTAL=https://billing.stripe.com/... npm run build
sudo rm -rf /var/www/html/mysite.com
sudo mkdir -p /var/www/html/mysite.com
sudo mv "$BUILD_DIR/build"/* "$APACHE_DIR/"
sudo chown -R www-data:www-data "$APACHE_DIR"
sudo chmod -R 755 "$APACHE_DIR"
sudo systemctl reload apache2
@kapa.ai does this look correct, specifically the REACT_APP_API_URL ending with /api - is this correct?
Let me check the knowledge base for you. One moment! :books:
----------------------
Your deployment script looks mostly correct, but there might be a potential issue with the
REACT_APP_API_URL environment variable.
In Wasp, REACT_APP_API_URL is used to set the URL of your server (the app's backend). Wasp automatically sets it during development when you run wasp start. In production, it should contain the value of your server's URL as the user's browser sees it, with the DNS and proxies considered source (https://wasp-lang.dev/docs/advanced/accessing-app-config#client-configuration-object).
However, there was an issue reported where if a trailing / is added at the end of the URL to the backend server, the API calls will be invalid, since it will have an extra / in it (e.g. <https://waspello.heroku.app//auth/me>) source (https://github.com/wasp-lang/wasp/issues/332).
So, in your case, you might want to try setting REACT_APP_API_URL to <https://mysite.com> (without the /api at the end) and see if that resolves the issue.
As for the /api/auth/email/signup route, it is likely defined in the Wasp source code and not directly visible in your project files. If you are still having issues with this route, I would recommend reaching out to the Wasp community (https://discord.com/channels/686873244791210014/1204832621176160286) for further assistance.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Conspyre, 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?How about the format of the two URLs we pass in to the docker command building the server? Are those expected to be both the same? I have WASP_WEB_CLIENT_URL='https://mysite.com' and WASP_SERVER_URL='https://mysite.com' so no trailing '/' and no trailing '/api'. Does this look correct @kapa.ai
Let me check the knowledge base for you. One moment! :books:
----------------------
Yes, your format for both
WASP_WEB_CLIENT_URL and WASP_SERVER_URL looks correct.
The WASP_WEB_CLIENT_URL is used to set the URL of your client (the app's frontend). Wasp automatically sets it during development when you run wasp start. In production, it should be set to your client's URL as the server sees it (i.e., with the DNS and proxies considered) source (https://wasp-lang.dev/docs/advanced/accessing-app-config#server-configuration-object).
The WASP_SERVER_URL is used to set the URL of your server (the app's backend). This should be set to the URL where your server will be deployed source (https://wasp-lang.dev/docs/advanced/deployment/manually#set-up-a-heroku-app).
Both of these URLs should not have a trailing / as per the issue reported source (https://github.com/wasp-lang/wasp/issues/332).
So, in your case, having WASP_WEB_CLIENT_URL='<https://mysite.com'> and WASP_SERVER_URL='<https://mysite.com'> (without the trailing / at the end) is correct.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Conspyre, 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?Kapa is not really an expert on this topic š
Let's rewind a bit and let me give a couple of hints.
The script you shared - it only copies the client which is just frontend and there is no API in the
web-app folder. There is zero server in the web-app folder š
The API lives in the server folder. It's a Node.js application that can't be served with Apache as a static page, it needs to be started with Node. Something along the lines node server.js.
https://mysite.com/api is not the API url, I'm not sure where you got this information?
Wasp is consisted out of two different apps that both need to be running in order to get a functional production app running. In dev, Wasp runs boths apps at the same time. The hint is that the client is at the port 3000 and the server is at the port 3001.
Check the deployment docs one more time: https://wasp-lang.dev/docs/advanced/deployment/manually
Your Apache setup should either include two distinct domains - one for the client app and one for the server app. Or if you really want to use the /api prefix - set it up so it proxies all /api requests to the Node.js app at for example, port 3001 if you started the Node.js app at that port.Deploying Manually | Wasp
This document explains how to build and prepare your Wasp app for deployment.
@kapa.ai To get more info, I've added a api route my main.wasp, since the failing route is /api/auth/email/signup, I've added "/api/test" like so:
api testRoute {
fn: import { testHandler } from "@src/testHandler",
httpRoute: (GET, "/api/test")
}
After building and starting the docker image, a curl off localhost responds:
curl http://localhost:3001/api/test
{"message":"Test route works"}
If I do a curl off of the deployed server, we can see that it is being routed correctly:
curl https://mysite.com/api/test
{"message":"Test route works"}
However the /api/auth/email/signup which is (apparently) declared/handled internal to the wasp framework is not.
Server console:
-----
[email protected] start npm run validate-env && node --enable-source-maps -r dotenv/config bundle/server.js
[email protected] validate-env node -r dotenv/config ./scripts/validate-env.mjsš Validating environment variables... š "Email and password" auth initialized stripeMiddlewareFn is called Starting pg-boss... pg-boss started! Server listening on port 3001 Catch-all route hit: GET /api/auth/me GET /api/auth/me 304 1.365 ms - - Catch-all route hit: POST /api/auth/email/signup POST /api/auth/email/signup 200 29.131 ms - 29 Test route hit GET /api/test 200 1.170 ms - 30 I'm building the docker image like so: sudo docker run -d \ --name backend-container \ -p 3001:3001 \ -e DATABASE_URL='postgresql://[email protected]:5432/databasename' \ -e WASP_WEB_CLIENT_URL='https://mysite.com' \ -e WASP_SERVER_URL='https://mysite.com' \ -e JWT_SECRET='BIG_LONG_SECRET_STRING' \ backend And when we build the front end it is being given the REACT_APP_API_URL in the form "https://mysite.com"
Let me check the knowledge base for you. One moment! :books:
----------------------
Based on the information provided, it seems like the
/api/auth/email/signup route is being caught by the catch-all route. This could be due to the order of your routes in the main.wasp file or an issue with the internal routing of Wasp.
Here are a few things you could check:
1. Order of routes: In Wasp, routes are matched in the order they are defined in the main.wasp file. If a catch-all route is defined, it will match any path that hasn't been matched by previous routes. Make sure that your catch-all route is defined after all other routes.
2. Internal routing: The /api/auth/email/signup route is likely defined internally by Wasp as part of the authentication flow. If there is an issue with the internal routing, it could cause the route to be caught by the catch-all route.
3. Environment variables: Ensure that the environment variables WASP_WEB_CLIENT_URL, WASP_SERVER_URL, and REACT_APP_API_URL are correctly set in your production environment. They should be set to the URLs of your client and server without a trailing / source (https://github.com/wasp-lang/wasp/issues/332).
If you are still facing issues, I would recommend reaching out to the Wasp community (https://discord.com/channels/686873244791210014/1204832621176160286) for further assistance. They might be able to provide more insight into why the /api/auth/email/signup route is being caught by the catch-all route.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Conspyre, 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?@kapa.ai I removed my "catch-all" route entirely, from main.wasp, delete the code, and redeployed. Situation remains unchanged.
- wasp-lang provided "catch-all" intercepts /api/auth/me and /api/auth/email/signup
- my API "test" route works
What else can we check?
Let me check the knowledge base for you. One moment! :books:
----------------------
It's quite unusual that the catch-all route is still intercepting requests even after you've removed it from your
main.wasp file. Here are a few more things you could check:
1. Clear build files: Try clearing your build files by running wasp clean before building your project again. This will ensure that there are no old build files interfering with your new build.
2. Check for other catch-all routes: Ensure that there are no other catch-all routes defined in your project. It's possible that there might be another catch-all route defined somewhere else in your project.
3. Check your server logs: Check your server logs for any errors or warnings that might indicate why the /api/auth/email/signup route is being caught by the catch-all route.
4. Check your Wasp version: Ensure that you are using the latest version of Wasp. There might be a bug in the version you are using that is causing this issue.
If you've checked all of these and are still facing issues, I would recommend reaching out to the Wasp community (https://discord.com/channels/686873244791210014/1204832621176160286) for further assistance. They might be able to provide more insight into why the /api/auth/email/signup route is being caught by the catch-all route.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Conspyre, 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?I found an issue which gets us closer to a solution @kapa.ai - the docker container was firewalled, as it's "bridge address" is different from the box it is running on. So:
sudo ufw allow from <put docker bridge IP address here> to any port 5432 proto tcp
sudo ufw reload
After doing so, now when I try to sign up from the /signup URL, there is a momentary delay which is about the same as running in the dev environment (the "catch-all" route failure mode is instant).
Looking in the server logs, we see that the call was successful (200) and that /api/auth/me is also able to be called:
Catch-all route hit: GET /api/auth/me
GET /api/auth/me 304 1.234 ms - -
Catch-all route hit: POST /api/auth/email/signup
POST /api/auth/email/signup 200 1.669 ms - 29
However, no e-mail is received, and checking the Sendgrid "Activity" tab reveals that none were sent.
The sendgrid API key being passed to the docker container is the same as in the development environment.
What could be the issue?
Let me check the knowledge base for you. One moment! :books:
----------------------
Based on the information provided, it seems like the issue might be related to the SendGrid configuration or the email sending process in your application.
Here are a few things you could check:
1. SendGrid API Key: Ensure that the
SENDGRID_API_KEY is correctly set in your Docker container. You mentioned that it's the same as in the development environment, but it's worth double-checking.
2. Email Sender Configuration: In your main.wasp file, make sure you have set the email sender provider to SendGrid source (https://wasp-lang.dev/docs/advanced/email#using-the-sendgrid-provider).
3. Email Sending Process: Review the process of sending emails in your application. If there is an error in this process, it could prevent the email from being sent.
4. SendGrid Account and API Key: Check your SendGrid account and make sure that it's active and the API key is valid. You can do this by logging into your SendGrid account and going to the API Keys section.
5. SendGrid Email Activity: Check the email activity in your SendGrid account. If the emails are being sent but not delivered, it could indicate an issue with the recipient's email server or the email content.
If you are still facing issues, I would recommend reaching out to the Wasp community (https://discord.com/channels/686873244791210014/1204832621176160286) for further assistance. They might be able to provide more insight into why the emails are not being sent.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Conspyre, 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?