Wasp•3mo ago

wasp deploy

getting the same error after another deploy. it says port is not connecting at 8080. i cant find whats wrong. @kapa.ai

message.txt

7 Replies

Hi @Bruno Njeru. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- I'm sorry you're running into issues with your deployment. Based on the knowledge sources, here are some things to check regarding port 8080 not connecting after deploying with Wasp: 1. Environment Variables: When deploying (for example, to Fly.io), you need to set the PORT environment variable to 8080, as that's the port the server will listen on. Make sure you've set this correctly using your deployment platform's secrets or environment variable configuration. For Fly.io, you would run:

   flyctl secrets set PORT=8080

   flyctl secrets set PORT=8080

Also, ensure that WASP_WEB_CLIENT_URL and WASP_SERVER_URL are set to the correct URLs for your deployed frontend and backend, respectively. These are required for proper operation and CORS configuration. If any of these are missing or incorrect, the server may not start or may not be reachable on the expected port Deploying Manually: Environment Variables. 2. Server Listening Port: Double-check that your server is actually configured to listen on port 8080. If you are using a custom Dockerfile or Nginx config, ensure that the listen directive and the EXPOSE command match the port you expect (8080) Railway Deployment Example. 3. Port Conflicts: If another process is already using port 8080 on your deployment server, your Wasp app will not be able to bind to it. Make sure no other service is occupying that port. 4. Firewall/Network Issues: If the server is running but you can't connect, there may be firewall rules or network policies blocking access to port 8080. Check your deployment platform's networking settings. 5. Deployment Platform Specifics: Some platforms (like Fly.io) require you to specify which port your app listens on, and may only expose certain ports to the public internet. Make sure your app and platform configuration are aligned Fly.io Manual Deployment. If you've checked all of the above and the problem persists, please provide more details about your deployment setup (e.g., which platform, any custom Docker or Nginx configs, relevant logs), so I can help you further. Let me know if you need more specific troubleshooting steps! ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Bruno Njeru, 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?

Bruno NjeruOP•3mo ago

the peorts are set at 8080, same as server url and waspwebclienturl. ive confirmed that. but theres still a cors error in the browser and here are the startup logs on the server . anything you can point out @kapa.ai @Wasp Team

message.txt

kapa.ai•3mo ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- Based on the knowledge sources, if your ports and URLs are set correctly but you’re still seeing a CORS error in the browser, here are the most relevant things to check: 1. CORS Configuration Depends on WASP_WEB_CLIENT_URL
Wasp configures CORS based on the WASP_WEB_CLIENT_URL environment variable. If this value is not set correctly (for example, if it has a trailing slash, or doesn’t match exactly what the browser is using), you can get CORS errors. Even a trailing slash can cause issues, so double-check that the value matches the frontend URL exactly, without a trailing slash if the frontend is served at the root (Ensure the REACT_APP_API_URL and WASP_WEB_CLIENT_URL env vars are valid URLs). 2. CORS and Custom APIs
If you are using custom HTTP API endpoints, you may need to explicitly enable CORS for those endpoints using middleware. Wasp’s default middleware covers Operations, but not custom APIs. You can use an apiNamespace with a middlewareConfigFn to ensure CORS is enabled for your custom endpoints (Making Sure CORS Works). 3. Order of Middleware
There have been reports that CORS errors can occur if the middleware is not registered in the correct order, especially if you have ejected and customized the server. In standard Wasp projects, this should not be an issue, but if you have custom middleware, ensure CORS is set up before your routes (Api.post on custom HTTP Endpoint results in CORS Error). 4. Environment Variable Propagation
Make sure the environment variables are actually being picked up by the running server. Sometimes, deployment platforms require a restart or redeploy after changing environment variables. What to do next: - Double-check that WASP_WEB_CLIENT_URL and WASP_SERVER_URL are set exactly to the URLs your browser and server are using, with no trailing slashes or typos. - If you’re using custom APIs, ensure you have CORS middleware set up for them. - If possible, share the relevant part of your server startup logs and the exact CORS error message from the browser for more targeted help. If you’ve checked all of the above and the issue persists, please provide the startup logs and the full CORS error message so I can help you further. The knowledge sources do not provide more specific troubleshooting steps without those details. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Bruno Njeru, 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?

Bruno NjeruOP•3mo ago

although ive noticed this in the deploy logs 13 DONE 1.8s #14 [server-builder 8/11] RUN npm install && cd .wasp/build/server && npm install #14 2.320 npm WARN EBADENGINE Unsupported engine { #14 2.321 npm WARN EBADENGINE package: '@lemonsqueezy/lemonsqueezy.js@3.3.1', #14 2.321 npm WARN EBADENGINE required: { node: '>=20' }, #14 2.321 npm WARN EBADENGINE current: { node: 'v18.18.0', npm: '9.8.1' } #14 2.321 npm WARN EBADENGINE } #14 2.536 npm WARN reify invalid or damaged lockfile detected #14 2.536 npm WARN reify please re-try this operation once it completes #14 2.536 npm WARN reify so that the damage can be corrected, or perform #14 2 could this be an issue? although ive noticed this in the deploy logs 13 DONE 1.8s #14 [server-builder 8/11] RUN npm install && cd .wasp/build/server && npm install #14 2.320 npm WARN EBADENGINE Unsupported engine { #14 2.321 npm WARN EBADENGINE package: '@lemonsqueezy/lemonsqueezy.js@3.3.1', #14 2.321 npm WARN EBADENGINE required: { node: '>=20' }, #14 2.321 npm WARN EBADENGINE current: { node: 'v18.18.0', npm: '9.8.1' } #14 2.321 npm WARN EBADENGINE } #14 2.536 npm WARN reify invalid or damaged lockfile detected #14 2.536 npm WARN reify please re-try this operation once it completes #14 2.536 npm WARN reify so that the damage can be corrected, or perform #14 2 could this be an issue? @kapa.ai

kapa.ai•3mo ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- Yes, this could be an issue. From your deploy logs, the warning:

npm WARN EBADENGINE Unsupported engine {
  package: '@lemonsqueezy/lemonsqueezy.js@3.3.1',
  required: { node: '>=20' },
  current: { node: 'v18.18.0', npm: '9.8.1' }
}

npm WARN EBADENGINE Unsupported engine {
  package: '@lemonsqueezy/lemonsqueezy.js@3.3.1',
  required: { node: '>=20' },
  current: { node: 'v18.18.0', npm: '9.8.1' }
}

means that the package @lemonsqueezy/lemonsqueezy.js@3.3.1 requires Node.js version 20 or higher, but your deployment is using Node.js 18.18.0. This mismatch can cause runtime errors or unexpected behavior, especially if the package uses features only available in Node 20. Relevant context from the knowledge sources: - Wasp now supports Node.js >= 18, but if your dependencies require a higher version (like Node 20), you must ensure your deployment environment matches that requirement. The Wasp docs recommend using Node 20 or higher if your dependencies need it, and you can set this up with tools like nvm or by configuring your deployment platform accordingly (Quick Start Requirements). - If you see engine warnings like this, you should update your deployment environment to use the required Node version to avoid compatibility issues. Action:
Update your deployment environment to use Node.js 20 or higher to match the requirements of your dependencies. This should resolve the EBADENGINE warning and may also help with related runtime issues. If you continue to see CORS or connectivity issues after updating Node, please provide updated logs and error messages. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Bruno Njeru, 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?

toticozeni•3mo ago

Hey @Bruno Njeru, one thing for sure is I would set my node version to a minimum of v20.

miho•3mo ago

Try doing this - wasp clean and rm package-lock.json and then wasp start to rebuild package-lock.json and then try deploying. There are some known issues with native deps and package-lock.json file, maybe you hit one of them.

Gaming

Programming

wasp deploy

Did you find this page helpful?