Failing to deploy (Assign own domain)
I am working with the opensaas template and I have skipped the email configuration since my app will not have registration/login or anything related (so I have Dummy sender).
I have tried to deploy with Fly but it returns this error:
โ --- [Error] Your wasp project failed to compile: -------------------------------
- app.emailSender must not be set to Dummy when building for production.
โ --- [Error] Building of wasp project failed: -----------------------------------
1 errors found.
๐ There was an error running โwasp deploy fly setup <basename> <region>โ. Please review the error and try again (if appropriate).
โ --- [Error] Deploy command failed: ---------------------------------------------
Deploy command failed with exit code: 1
I don't want to configure the email, I want to disable or remove it.
Ps: what is the reason for the second error?68 Replies
Hi @NEROX. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
The error message you're seeing is because the
Dummy
email provider is not meant for production use. It's only meant to be used during development. If you try building your app with the Dummy
provider, the build will fail as you've experienced source (https://wasp-lang.dev/docs/advanced/email#providers).
If you don't need the email functionality, you might want to remove the emailSender
field from your main.wasp
file. However, please note that some features like email verification and password reset flows require an email sender source (https://wasp-lang.dev/docs/auth/email#5-set-up-an-email-sender).
As for the second error, it's related to the first one. The Wasp deploy command failed because your project failed to compile due to the Dummy
email provider issue.
If you still encounter issues after removing the emailSender
field, it might be due to other parts of your code. For example, if you have the email
method specified with all the fields but missing the emailSender
property, it could cause issues source (https://github.com/wasp-lang/wasp/issues/1410).
If you need further assistance, consider asking for help in the Wasp community on Discord source (https://discord.com/channels/686873244791210014/1215756032064880711).
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @NEROX, 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?That is all the same error most likely!
If you don't need any auth, you can remove the
auth
block from main.wasp, and you can also remove a lot of functionality connected to it in the app. But yeah, it will be quite some things to remove! Maybe you would be better suited than to start with just a simpler template, something like basic
template? You can pick the template when you type wasp new
.
How is that you don't need any auth btw?In the end I have integrated SendGrid since I will need those functionalities later on.
Regarding authentication, I am launching some online tools (later I will implement more features).
@kapa.ai What went wrong?:
๐ Validating environment variables...
โฒ [WARNING] Cannot find base config file "@tsconfig/vite-react/tsconfig.json" [tsconfig.json]
tsconfig.json:2:13:
2 โ "extends": "@tsconfig/vite-react/tsconfig.json",
โต ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
failed to load config from /home/rootall/apps/minisaas-boilerplate/app/.wasp/build/web-app/vite.config.ts
error during build:
Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@vitejs/plugin-react' imported from /home/rootall/apps/minisaas-boilerplate/app/.wasp/build/web-app/vite.config.ts.timestamp-1728901095770-eeb2f349b469c.mjs
at new NodeError (node:internal/errors:405:5)
at packageResolve (node:internal/modules/esm/resolve:916:9)
at moduleResolve (node:internal/modules/esm/resolve:973:20)
at defaultResolve (node:internal/modules/esm/resolve:1206:11)
at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:404:12)
at ModuleLoader.resolve (node:internal/modules/esm/loader:373:25)
at ModuleLoader.getModuleJob (node:internal/modules/esm/loader:250:38)
at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:76:39)
at link (node:internal/modules/esm/module_job:75:36)
๐ There was an error running "wasp deploy fly deploy". Please review the error and try again (if appropriate).
โ --- [Error] Deploy command failed: ---------------------------------------------
Deploy command failed with exit code: 1
Let me check the knowledge base for you. One moment! :books:
----------------------
The error message indicates that the build process is unable to find the
@vitejs/plugin-react
package and the @tsconfig/vite-react/tsconfig.json
file. These are likely dependencies of your project that need to be installed or correctly referenced.
Here are a few steps you can take to resolve this issue:
1. Ensure that @vitejs/plugin-react
is installed in your project. You can do this by running npm install @vitejs/plugin-react
or yarn add @vitejs/plugin-react
in your project directory.
2. Check your tsconfig.json
file. The error message indicates that it's trying to extend from @tsconfig/vite-react/tsconfig.json
, which it can't find. Make sure that @tsconfig/vite-react
is installed and correctly referenced in your tsconfig.json
file.
3. If you're still encountering issues, it might be helpful to clean your project and start fresh. You can do this by running the wasp clean
command and then starting your project again with wasp start
.
If you're still encountering issues after trying these steps, consider asking for help in the Wasp community on Discord. They might be able to provide more specific guidance based on your project setup.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @NEROX, 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 Already deployed in my domain! But the google auth button points to the "-app-server.fly.dev/auth/google/login"
How can I change that to point to my domain?
Let me check the knowledge base for you. One moment! :books:
----------------------
To change the domain that the Google Auth button points to, you need to set your domain as the
WASP_WEB_CLIENT_URL
environment variable for your server app. This is done to keep your CORS configuration up to date. You can do this by running the following command:
Make sure to replace <https://mycoolapp.com
> with your domain.
After setting this environment variable, your app should be available at your custom domain and the Google Auth button should point to your domain source (https://wasp-lang.dev/docs/advanced/deployment/cli#using-a-custom-domain-for-your-app).
Also, ensure that you have added your custom domain in the Authorized redirect URIs of your Google OAuth app settings source (https://wasp-lang.dev/docs/auth/social-auth/google#3-creating-a-google-oauth-app).
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @NEROX, 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 WARNING The app is not listening on the expected address and will not be reachable by fly-proxy.
You can fix this by configuring your app to listen on the following addresses:
- 0.0.0.0:8080
Found these processes inside the machine with open listening sockets:
PROCESS | ADDRESSES
-----------------*-------------------------------------
/.fly/hallpass | [fdaa๐
ฐ๏ธ7f67:a7b:2c6:88:aa72:2]:22
Let me check the knowledge base for you. One moment! :books:
----------------------
The warning message you're seeing indicates that your application is not listening on the expected address (
0.0.0.0:8080
), which is required for it to be reachable by the fly-proxy
.
To resolve this issue, you need to configure your application to listen on 0.0.0.0:8080
. The exact steps to do this will depend on the specifics of your application, but generally, you would need to modify your server configuration to bind to this address and port.
If you're using Express.js for your server, for example, you might have something like this in your code:
You would need to change it to:
This tells your server to listen on all network interfaces (0.0.0.0
), not just localhost
, and on port 8080
.
Please note that this is a general solution and might not apply directly to your situation. If you're still encountering issues, consider asking for help in the Wasp community on Discord. They might be able to provide more specific guidance based on your project setup.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @NEROX, 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 Check this:
WARNING The app is not listening on the expected address and will not be reachable by fly-proxy.
You can fix this by configuring your app to listen on the following addresses:
- 0.0.0.0:8080
Found these processes inside the machine with open listening sockets:
PROCESS | ADDRESSES
---------------------------------*---------------------------------------
/goStatic -fallback index.html | [::]:8043
/.fly/hallpass | [fdaa๐
ฐ๏ธ7f67:a7b:2c4:e9ef:1768:2]:22
> [1/2] Running smoke checks on machine 1781512dc11628
> [1/2] Running machine checks on machine 1781512dc11628
> [1/2] Checking health of machine 1781512dc11628
โ [1/2] Machine 1781512dc11628 is now in a good state
> [2/2] Clearing lease for e7843e5eb3d1e8
> [1/2] Clearing lease for 1781512dc11628
โ [2/2] Cleared lease for e7843e5eb3d1e8
โ [1/2] Cleared lease for 1781512dc11628
Checking DNS configuration for xxx-app-client.fly.dev
Visit your newly deployed app at https://xxx-app-client.fly.dev/
My fly.client.toml
:
# fly.toml app configuration file generated for toograded-app-client on 2024-10-14T12:13:37+02:00
#
# See https://fly.io/docs/reference/configuration/ for information about how to use this file.
#
app = 'xxx-app-client'
primary_region = 'mia'
[build]
[http_service]
internal_port = 8080
force_https = true
auto_stop_machines = 'stop'
auto_start_machines = true
min_machines_running = 0
processes = ['app']
[[vm]]
memory = '1gb'
cpu_kind = 'shared'
cpus = 1
My fly.server.toml
:
# fly.toml app configuration file for toograded-app-server
app = 'xxx-app-server'
primary_region = 'mia'
[build]
[http_service]
internal_port = 8080
force_https = true
auto_stop_machines = true
auto_start_machines = true
min_machines_running = 0
processes = ['app']
[[vm]]
memory = '1gb'
cpu_kind = 'shared'
cpus = 1
[env]
PORT = "8080"
What I'm doing wrong?Let me check the knowledge base for you. One moment! :books:
----------------------
The warning message you're seeing indicates that your application is not listening on the expected address (
0.0.0.0:8080
), which is required for it to be reachable by the fly-proxy
.
Your fly.toml
files seem to be correctly configured with internal_port = 8080
. However, the application itself also needs to be configured to listen on 0.0.0.0:8080
.
If you're using Express.js for your server, for example, you might have something like this in your code:
You would need to change it to:
This tells your server to listen on all network interfaces (0.0.0.0
), not just localhost
, and on port 8080
.
Please note that this is a general solution and might not apply directly to your situation. If you're still encountering issues, consider asking for help in the Wasp community on Discord. They might be able to provide more specific guidance based on your project setup.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------@NEROX have you been following the docs for deployment?
- https://wasp-lang.dev/docs/advanced/deployment/cli (general info)
- https://wasp-lang.dev/docs/project/env-vars (general env var info)
- https://wasp-lang.dev/docs/auth/social-auth/google (google env var info)
I'd advise commenting out the auth methods (besides email) so you don't have to specify env vars for e.g. Google.
If you get stuck at some point - the best course of action for you might be: delete all the apps in Fly's dashboard, delete all TOML files and try deploying from scratch again.
Deploying with the Wasp CLI | Wasp
Wasp CLI can deploy your full-stack application with only a single command.
Env Variables | Wasp
Environment variables are used to configure projects based on the context in which they run. This allows them to exhibit different behaviors in different environments, such as development, staging, or production.
Google | Wasp
Wasp supports Google Authentication out of the box.
I have followed all the steps (I have both login with google and active mail), locally everything works perfectly.
I just deleted the TOML files and Fly apps.
I have deployed again from scratch and I am having the path problem.
https://www.loom.com/share/b7cb85626fff497fb652cf51eeb01872
Loom
Troubleshooting Server Setup Process ๐ ๏ธ
In this video, I troubleshoot the server setup process step by step, highlighting key actions and providing insights into the configuration. I address errors encountered, demonstrate problem-solving skills, and ensure the server is correctly configured for operation. Viewers are encouraged to follow along and take note of the troubleshooting tec...
Some things stop working when they are deployed
https://www.loom.com/share/58f6414c1e434eed94be345719e26a63
Loom
Troubleshooting and Testing Web Application Features
In this video, I troubleshoot and test various features of our web application. I encounter issues initially but manage to resolve them, showcasing the functionality of auto-complete and Google login. No specific action is requested from viewers.
Great video man! I can see you did all the required steps. The DNS usually takes a few minutes to work properly after you change it - so that was normal. The HTTPS being red - that's also something that resolves by itself as Fly generates a new certificate and it takes one or two visits so it turns on properly, in my experience at least.
When I try to visit the backend directly: https://toograded-app-server.fly.dev - it doesn't load. Which means it's not up. This means, we should check the server logs to see the errors there and see why it maybe crashed.
Btw. you are very professional in your attitude towards development ๐ keep doing what you are doing!
Thank you for your support Miho! You are right, something causes the server to shut down :(
I have gone through the process again step by step capturing logs:
https://www.loom.com/share/392577f3533a41afa9bcf43578ed684a
At least I have the front:smugboi: https://toograded-client.fly.dev/
Too Graded
I made a SaaS App. Buy my stuff.
It says you are missing the
GOOGLE_CLIENT_ID
env var on Fly. You need to set all the env vars your app needs. The best way to do this is to set all the env vars you had locally (check the .env.server
) and set them on Fly.
If you copy paste the errors you see here, I think Kapa will also pick it up and give a similar answer ๐@kapa.ai Whats wrong with my deploy? Why it says about my
GOOGLE_CLIENT_ID
? I have it configured in my .env.server
? Why doesn't fly have it? How can I set it on Fly? Check this logs:
2024-10-14T18:41:35.104 app[17815121ad0978] mia [info] INFO Starting init (commit: 04656915)...
2024-10-14T18:41:35.166 app[17815121ad0978] mia [info] INFO Preparing to run: npm run start-production
as root
2024-10-14T18:41:35.176 app[17815121ad0978] mia [info] INFO [fly api proxy] listening at /.fly/api
2024-10-14T18:41:35.181 runner[17815121ad0978] mia [info] Machine started in 836ms
2024-10-14T18:41:35.182 proxy[17815121ad0978] mia [info] machine started in 840.252229ms
2024-10-14T18:41:35.402 app[17815121ad0978] mia [info] 2024/10/14 18:41:35 INFO SSH listening listen_address=[fdaa๐
ฐ๏ธ7f67:a7b:2c5:793d:a2d6:2]:22 dns_server=[fdaa::3]:53
2024-10-14T18:41:36.253 app[17815121ad0978] mia [info] > [email protected] start-production
2024-10-14T18:41:36.253 app[17815121ad0978] mia [info] > npm run db-migrate-prod && NODE_ENV=production npm run start
2024-10-14T18:41:36.998 app[17815121ad0978] mia [info] > [email protected] db-migrate-prod
2024-10-14T18:41:36.998 app[17815121ad0978] mia [info] > prisma migrate deploy --schema=../db/schema.prisma
2024-10-14T18:41:37.782 app[17815121ad0978] mia [info] Prisma schema loaded from ../db/schema.prisma
2024-10-14T18:41:37.801 app[17815121ad0978] mia [info] Datasource "db": PostgreSQL database "toograded_server", schema "public" at "toograded-db.flycast:5432"
2024-10-14T18:41:37.959 app[17815121ad0978] mia [info] 11 migrations found in prisma/migrations
2024-10-14T18:41:38.023 app[17815121ad0978] mia [info] No pending migrations to apply.
2024-10-14T18:41:38.798 app[17815121ad0978] mia [info] > [email protected] start
2024-10-14T18:41:38.798 app[17815121ad0978] mia [info] > npm run validate-env && node --enable-source-maps -r dotenv/config bundle/server.js
2024-10-14T18:41:39.302 app[17815121ad0978] mia [info] > [email protected] validate-env
2024-10-14T18:41:39.302 app[17815121ad0978] mia [info] > node -r dotenv/config ./scripts/validate-env.mjs
2024-10-14T18:41:39.392 app[17815121ad0978] mia [info] ๐ Validating environment variables...
2024-10-14T18:41:40.423 app[17815121ad0978] mia [info] /app/.wasp/out/sdk/wasp/server/auth/oauth/env.ts:10
2024-10-14T18:41:40.423 app[17815121ad0978] mia [info] throw new Error(${envVarName} env variable is required when using the ${providerName} auth provider.
);
2024-10-14T18:41:40.423 app[17815121ad0978] mia [info] ^
2024-10-14T18:41:40.423 app[17815121ad0978] mia [info] Error: GOOGLE_CLIENT_ID env variable is required when using the Google auth provider.
2024-10-14T18:41:40.423 app[17815121ad0978] mia [info] at ensureEnvVarsForProvider (/app/.wasp/out/sdk/wasp/server/auth/oauth/env.ts:10:13)
2024-10-14T18:41:40.423 app[17815121ad0978] mia [info] at <anonymous> (/app/.wasp/out/sdk/wasp/server/auth/oauth/providers/google.ts:10:13)Let me check the knowledge base for you again. One moment! :books:
----------------------
The error message indicates that the
GOOGLE_CLIENT_ID
environment variable is not set in your production environment. This environment variable is required for Google OAuth to work.
Even though you have it set in your .env.server
file, this file is not used in the production environment. Instead, you need to set it directly in your deployment environment.
Since you're deploying with Fly, you can set environment variables using the flyctl secrets set
command. Here's how you can set the GOOGLE_CLIENT_ID
:
Replace <your-google-client-id>
with your actual Google client ID and <your-app-name>
with the name of your Fly app.
After setting this environment variable, you should be able to deploy your app without this error source (https://wasp-lang.dev/docs/project/env-vars#defining-env-vars-in-production).
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @NEROX, 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 my https://toograded-client.fly.dev/ and my https://toograded-server.fly.dev/ are active, I did the cert generation, updated the A and AAAA records, and I changed the
WASP_WEB_CLIENT_URL
secret to : https://toograded.com As you can see below:
๐ Client has been deployed! Your Wasp app is accessible at: https://toograded-client.fly.dev
rootall@Nerox-LpTp:~/apps/minisaas-boilerplate/app$ wasp deploy fly cmd --context client certs create toograded.com
$ flyctl version
flyctl v0.3.18 linux/amd64 Commit: 283170a44f19153850fcd8d830f2e27ce4ebfe18 BuildDate: 2024-10-09T17:38:08Z
$ flyctl auth whoami
[email protected]
๐ Running client command: flyctl certs create toograded.com
$ cd /home/rootall/apps/minisaas-boilerplate/app/.wasp/build/web-app
$ flyctl certs create toograded.com
A Record (66.241.125.54) does not match app's IP (66.241.125.36)
AAAA Record (2a09:8280:1::4a:de87:0) does not match app's IP (2a09:8280:1::4a:dfa8:0)
Address resolution (66.241.125.54) does not match app's IP (66.241.125.36/2a09:8280:1::4a:dfa8:0)
Address resolution (2a09:8280:1::4a:de87:0) does not match app's IP (66.241.125.36/2a09:8280:1::4a:dfa8:0)
You are creating a certificate for toograded.com
We are using lets_encrypt for this certificate.
You can direct traffic to toograded.com by:
1: Adding an A record to your DNS service which reads
A @ 66.241.125.36
You can validate your ownership of toograded.com by:
2: Adding an AAAA record to your DNS service which reads:
AAAA @ 2a09:8280:1::4a:dfa8:0
rootall@Nerox-LpTp:~/apps/minisaas-boilerplate/app$ wasp deploy fly cmd --context server secrets set WASP_WEB_CLIENT_URL=https://toograded.com
$ flyctl version
flyctl v0.3.18 linux/amd64 Commit: 283170a44f19153850fcd8d830f2e27ce4ebfe18 BuildDate: 2024-10-09T17:38:08Z
$ flyctl auth whoami
[email protected]
๐ Running server command: flyctl secrets set WASP_WEB_CLIENT_URL=https://toograded.com
$ cd /home/rootall/apps/minisaas-boilerplate/app/.wasp/build
$ flyctl secrets set WASP_WEB_CLIENT_URL=https://toograded.com
Updating existing machines in 'toograded-server' with rolling strategy
> [1/2] Updating 68301e1b432948 [app]
> [1/2] Updating 68301e1b432948 [app]
> [2/2] Updating 287172df031718 [app]
> [2/2] Updating 287172df031718 [app]
> [1/2] Waiting for 68301e1b432948 [app] to have state: started
โ [2/2] Machine 287172df031718 [app] update succeeded
> [1/2] Machine 68301e1b432948 [app] has state: started
> [1/2] Checking that 68301e1b432948 [app] is up and running
โ [1/2] Machine 68301e1b432948 [app] update succeeded
Checking DNS configuration for toograded-server.fly.dev
rootall@Nerox-LpTp:~/apps/minisaas-boilerplate/app$
But I cannot access through https://toograded.com
What's going wrong?Too Graded
I made a SaaS App. Buy my stuff.
Let me check the knowledge base for you again. One moment! :books:
----------------------
The issue seems to be related to your DNS configuration. The logs indicate that the A and AAAA records do not match the app's IP.
You need to update your DNS records to match the IP addresses provided by the
flyctl certs create
command.
According to the logs, you should set:
- An A record for @
pointing to 66.241.125.36
- An AAAA record for @
pointing to 2a09:8280:1::4a:dfa8:0
The process to update these records will depend on your DNS provider, but generally, you would need to:
1. Log in to your DNS provider's website.
2. Navigate to the DNS settings for your domain.
3. Update the A and AAAA records with the values provided by the flyctl certs create
command.
After updating the DNS records, it might take some time for the changes to propagate. Once the DNS changes have propagated, you should be able to access your app at <https://toograded.com
.>
If you're still having issues after updating the DNS records, consider asking for help in the Wasp community on Discord. They might be able to provide more specific guidance based on your project setup source (https://wasp-lang.dev/docs/advanced/deployment/cli#using-a-custom-domain-for-your-app).
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @NEROX, 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 what about ttl values?
Let me check the knowledge base for you again. One moment! :books:
----------------------
The TTL (Time to Live) value for a DNS record determines how long the record is cached by DNS resolvers and browsers. After the TTL expires, the DNS resolver or browser will fetch the record again from the DNS server.
The exact TTL value you should use can depend on various factors, but a common default value is 3600 seconds (1 hour). If you're making frequent changes to your DNS records, you might want to use a lower TTL to ensure the changes propagate more quickly.
However, keep in mind that a lower TTL can result in more DNS lookups, which could potentially impact performance. On the other hand, a higher TTL can result in changes taking longer to propagate.
In your case, since you're changing the A and AAAA records for your domain, you might want to use a lower TTL initially. Once you've confirmed that everything is working correctly, you could then increase the TTL to a higher value.
To set the TTL, you would typically specify it when creating or updating the DNS record. The exact process will depend on your DNS provider. If you're unsure, check the documentation for your DNS provider or contact their support.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @NEROX, 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 Just checked https://www.whatsmydns.net/#AAAA/toograded.com & https://www.whatsmydns.net/#A/toograded.com and the DNS are spreaded correctly, but still not working https://toograded.com
DNS Propagation Checker - Global DNS Checker Tool
Instant DNS Propagation Check. Global DNS Propagation Checker - Check DNS records around the world.
Let me check the knowledge base for you again. One moment! :books:
----------------------
If your DNS records have propagated correctly but you're still unable to access your site at
<https://toograded.com
,> there could be a few potential issues:
1. SSL/TLS Certificate: Ensure that the SSL/TLS certificate for your domain has been correctly configured and issued. You can check this in your Fly dashboard. If there are any issues with the certificate, you might need to reissue it.
2. CORS Configuration: Make sure that your CORS configuration is up to date. You've set the WASP_WEB_CLIENT_URL
environment variable to <https://toograded.com
,> which should handle this, but it's worth double-checking.
3. Browser Cache: Sometimes, your browser might cache the old DNS records. Try clearing your browser's cache, or try accessing the site in a private/incognito window, or from a different device.
4. Propagation Time: Even though the DNS checkers are showing the correct records, DNS changes can sometimes take up to 48 hours to fully propagate. It's possible that some DNS servers haven't updated yet.
If you've checked all of these and are still having issues, it might be worth reaching out to Fly's support or the Wasp community on Discord for further assistance. They might be able to provide more specific guidance based on your setup source (https://wasp-lang.dev/docs/advanced/deployment/cli#using-a-custom-domain-for-your-app).
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @NEROX, 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?did you follow these steps succesfully @NEROX ?
Yes, you can see the logs above
You've set the WASP_WEB_CLIENT_URL environment variable to https://toograded.com?
Yes, I just did it again like the 8 time:
rootall@Nerox-LpTp:~/apps/minisaas-boilerplate/app$ wasp deploy fly cmd --context server secrets set WASP_WEB_CLIENT_URL=https://toograded.com
$ flyctl version
flyctl v0.3.18 linux/amd64 Commit: 283170a44f19153850fcd8d830f2e27ce4ebfe18 BuildDate: 2024-10-09T17:38:08Z
$ flyctl auth whoami
[email protected]
๐ Running server command: flyctl secrets set WASP_WEB_CLIENT_URL=https://toograded.com
$ cd /home/rootall/apps/minisaas-boilerplate/app/.wasp/build
$ flyctl secrets set WASP_WEB_CLIENT_URL=https://toograded.com
Updating existing machines in 'toograded-server' with rolling strategy
> [1/2] Updating 68301e1b432948 [app]
> [1/2] Updating 68301e1b432948 [app]
> [2/2] Updating 287172df031718 [app]
> [2/2] Updating 287172df031718 [app]
> [1/2] Waiting for 68301e1b432948 [app] to have state: started
โ [2/2] Machine 287172df031718 [app] update succeeded
> [1/2] Machine 68301e1b432948 [app] has state: started
> [1/2] Checking that 68301e1b432948 [app] is up and running
โ [1/2] Machine 68301e1b432948 [app] update succeeded
Checking DNS configuration for toograded-server.fly.dev
rootall@Nerox-LpTp:~/apps/minisaas-boilerplate/app$
ok looks correct. hmm
Maybe @martinsos has a better idea. I don't have much experience with these issues
Wasp version (0.14.0 instead of 0.15.0) could be the cause or could it be ruled out?
Edit: I don't see anything related to deploy or Fly in the 0.15 changelog, I think I would auto-discard this.
@NEROX don't run the
certs
command anymore after you set the A
and AAAA
records - the IPs change each time. Set it and then wait for 1 h, up to 24 h. Have you done this?Yes, the certificate has been created more than 12 hours ago.
In this case, no matter how much I run the โcertsโ command, it tells me that the certificate already exists, so nothing changes.
As far as I have seen it changed the ip when I deleted the apps and deployed them again (yesterday morning). But since more than 12 hours ago I have the same ip and the same certificate and DNS records and still the same.
It still doesn't make sense because yesterday for a few moments I succeeded (i.e. the DNS change took a matter of seconds minutes).
so nothing changes.It seems that the IP address changes - that's what we saw in the error message above:
A Record (66.241.125.54) does not match app's IP (66.241.125.36) AAAA Record (2a09:8280:1::4a:de87:0) does not match app's IP (2a09:8280:1::4a:dfa8:0)
But since more than 12 hours ago I have the same ip and the same certificate and DNS records and still the same.Ok, this is a good start! I'm super confused with why it doesn't work. I did the steps you did many times and it usually it was enough. In these kind of weird situations, it's usually small details that go wrong - that's why we are checking everything.
1๏ธโฃ DNS checkers seems to agree that the
A
records is set to the value you showed in Fly's dashboard2๏ธโฃ DNS checker agrees that the
AAAA
is set to the value you showed in the Fly's dashboard3๏ธโฃ cURL says:
Trying 66.241.125.36:443...This says it's not a DNS issue. No need to touch DNS anymore. @NEROX Do you have any errors in your server logs?
Just this I think
And your client app logs? ๐
๐
Wohooo @NEROX, you just became a Waspeteer level 9!
Let's try removing the cert and readding it:
-
wasp deploy fly cmd --context client certs remove mycoolapp.com
- wasp deploy fly cmd --context client certs create mycoolapp.com
It's cool because Plausible it's working
rootall@Nerox-LpTp:~/apps/minisaas-boilerplate/app$ wasp deploy fly cmd --context client certs create toograded.com
$ flyctl version
flyctl v0.3.18 linux/amd64 Commit: 283170a44f19153850fcd8d830f2e27ce4ebfe18 BuildDate: 2024-10-09T17:38:08Z
$ flyctl auth whoami
[email protected]
๐ Running client command: flyctl certs create toograded.com
$ cd /home/rootall/apps/minisaas-boilerplate/app/.wasp/build/web-app
$ flyctl certs create toograded.com
Your certificate for toograded.com is being issued. Status is Awaiting certificates. Make sure to create another certificate for www.toograded.com when the current certificate is issued.
I think nothing
Deleted fly apps, dns,
.toml
files, did wasp clean
, every start is a new beginning๐And did it work? ๐
Already deploying, we'll see soon
Take it with a grain of salt, I got mine to work, but I did the steps relatively slowly and it took 20 minutes or so to see the change on the domain I bought
Woah, 20 minutes, I've been here for 24 hours:laughboi:
What I did wrong now? https://www.loom.com/share/4e05659103744e04a602bbce25c8d53e
I will go to the beach to swim with the fishes
You did everything 100% correctly as far as I can see, I'm not sure what is going on - other then maybe some local cache on your PC that remembered old IPs or something like that.
1๏ธโฃ What do you get for this command:
wasp deploy fly cmd --context client certs show toograded.com
2๏ธโฃ Second thing you could try is to verify the domain by adding a CNAME record (this guy had issue with that: https://community.fly.io/t/ssl-not-working-when-using-custom-domain/10776/7)The verification CNAME details are here under the client app.
Here is:
๐ Running client command: flyctl certs show toograded.com
$ cd /home/rootall/apps/minisaas-boilerplate/app/.wasp/build/web-app
$ flyctl certs show toograded.com
The certificate for toograded.com has not been issued yet.
Hostname = toograded.com
DNS Provider = dns-parking
Certificate Authority = Let's Encrypt
Issued =
Added to App = 2 hours ago
Source = fly
Your certificate for toograded.com is being issued. Status is Awaiting certificates. Make sure to create another certificate for www.toograded.com when the current certificate is issued.
I did it a few hours ago
I do not understand anything, I do not understand how yesterday I managed to get it to work well for a few moments (the problem seems to be with the certificate), what I have read on Fly is that it takes at most a few minutes, if not, there is some configuration error. I reverted to yesterday's commit to see if I had touched something I shouldn't have but I still can't do it.
OK, Something is wrong with either the certificate or the domain, I just created a certificate for another parked domain and it works (just with the
A
& AAAA
records + set WASP_WEB_CLIENT_URL
): https://nazzaworld.com/Too Graded
I made a SaaS App. Buy my stuff.
I was about to reinstall my entire OS
And I have even tested that the subscriptions work (stripe test key in production:be: ).
Edit: Technically, I can already say that I have a SaaS.
Edit2: I am changing my Linkedin position to CEO.
Your certificate for toograded.com is being issued. Status is Awaiting certificates. Make sure to create another certificate for www.toograded.com when the current certificate is issued.This is the reason why it doesn't work - for some reason Fly or Let's Encrypt is still working on issuing your certificate. Dunno why that happens ๐คทโโ๏ธ
โ
Solved! https://toograded.com/
Finally! ๐ Did you do anything differently or things just worked out?
The certificate for the domain, for some reason, is not issued๐คทโโ๏ธ
So, as it appears here, everything must be green even though the DNS tab says that everything is OK.