Re-Deployment issues with Fly.
Trying to re-deploy a project and running into this problem, at the client deployment
❌ --- [Error] Building of wasp project failed: -----------------------------------
1 errors found.
/home/lazi/.local/share/wasp-lang/0.16.3/data/packages/deploy/node_modules/zx/build/core.cjs:416
const output = self._output = new ProcessOutput(dto);
^
ProcessOutput [Error]:
at Proxy.set (/home/lazi/.local/share/wasp-lang/0.16.3/data/packages/deploy/node_modules/zx/build/core.cjs:277:18)
exit code: 1
at EventEmitter.end (/home/lazi/.local/share/wasp-lang/0.16.3/data/packages/deploy/node_modules/zx/build/core.cjs:416:41)
at EventEmitter.emit (node:events:536:35)
at ChildProcess.<anonymous> (/home/lazi/.local/share/wasp-lang/0.16.3/data/packages/deploy/node_modules/zx/build/vendor-core.cjs:502:16)
at Object.onceWrapper (node:events:639:26)
at ChildProcess.emit (node:events:524:28)
at maybeClose (node:internal/child_process:1101:16)
at ChildProcess._handle.onexit (node:internal/child_process:304:5)
at Process.callbackTrampoline (node:internal/async_hooks:130:17) {
_code: [Getter],
_signal: [Getter],
_stdout: [Getter],
_stderr: [Getter],
_combined: [Getter],
_duration: [Getter]
}
Node.js v22.12.0
I've been deploying using wasp deploy fly deploy
29 Replies
Hi @lazi. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
I can see you're having issues with redeploying your Wasp project to Fly.io. Based on the error message, there seems to be a problem during the client deployment process.
Here are a few potential solutions to try:
1. Update your Wasp version - Some deployment issues were fixed in newer Wasp versions. For example, version 0.12.4 fixed a specific client deployment issue:
Wasp Discord
2. Check your Node.js version - You're using Node.js v22.12.0, which might be too new for Wasp. Wasp has had issues with certain Node versions in the past. Try using an older, more stable version like Node.js 18 using NVM:
Wasp Discord
3. Try cleaning your project before redeploying:
Wasp Discord
4. Check environment variables - Make sure all necessary environment variables are properly set for your deployment.
5. Add organization flag - If you're using WSL on Windows or have multiple Fly.io organizations, try adding the
--org flag:
GitHub Issue
If the issue persists, you might need to check the generated code in the .wasp/build directory to see if there are any specific errors in your client code that might be causing the deployment to fail.
Note that Fly.io deployments can sometimes be flaky, and the Wasp team is aware of issues with error handling during deployment. They're working on improving how deployment errors are handled to make it clearer what went wrong and how to proceed.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @lazi, 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?Which Wasp version are you using? Could you try doing
wasp clean and then try deploying?lazi@Lazi:/mnt/d/Translate/T/app$ wasp version
0.16.3
I did wasp clean, even got a succesful build and it's working locally but when I do re-deploy on fly it fails with that
Could you retry with
0.16.2? Install it with curl -sSL https://get.wasp.sh/installer.sh | sh -s -- -v 0.16.2
Also, what's your OS? Did you update to a newer Node.js recently?
Also, could you paste some more output above the error messaage 😄Windows 11 with WSL2 (Ubuntu) - also on the nodejs i did have some changes.
The problem seemed to be with my client build/deployment - it succesfully passes the server deployment part (and it seems to be error handling errors mostly? )
I tried (and covered all of them) but then I was getting to the above mentioned error that i couldn't get past.
BUT ! This worked for me - I used wasp 0.16.2 and it deployed it properly with no errors (after also reverting my latest changes on fixing the above mentioned errors)
Thank you ❤️
It seems that we have some issues with the deployment command in the latest Wasp version. Could you try one more time deploying with the latest version and share the full error log with me in the DMs? 🙏 thanks
Sure thing, one second 😄
@kapa.ai 🚀 Invalid region code mia. Please specify a valid 3 character region id: https://fly.io/docs/reference/regions
🚀 You can also run "wasp deploy fly cmd platform regions --context server".
how can i fix this? I'm trying to deploy my app to fly for the first time
Let me check the knowledge base for you again. One moment! :books:
----------------------
The error message "Invalid region code mia. Please specify a valid 3 character region id" means that the region code you provided (mia) is not recognized by Fly.io as a valid region. Region codes must be valid 3-character identifiers supported by Fly.io.
How to fix:
1. Find the correct region code:
You can get the list of all available Fly.io regions by running: Or, if you want to do it through Wasp CLI, run: Fly.io Regions in Wasp Docs 2. Use a valid region code:
Once you have the list, pick the region code that best fits your needs (for example, "iad" for US East, "fra" for Frankfurt, etc.), and use it in your deploy command: Replace
Make sure you are using a recent version of Wasp. There have been bug fixes related to deployment and region handling in recent releases. You can check your version with
Discord: Issue with deploying my wasp app to fly.io 2. Region Code Format:
The region code should be a 3-character code, which
Wasp Docs: Fly.io Regions 3. Command Syntax:
The correct syntax for launching is: For your case: Make sure there are no extra spaces or line breaks between the app name and region code. 4. Organization Flag:
If you are a member of multiple Fly.io organizations, you may need to specify the organization with
Wasp Docs: Deploying with the Wasp CLI If you have confirmed all of the above and the error persists, the knowledge sources do not provide a direct solution for this specific issue. It may be a bug or a temporary issue with the Wasp CLI or Fly.io integration. Next Steps: - Double-check your Wasp version and upgrade if necessary. - Try specifying the organization with
You can get the list of all available Fly.io regions by running: Or, if you want to do it through Wasp CLI, run: Fly.io Regions in Wasp Docs 2. Use a valid region code:
Once you have the list, pick the region code that best fits your needs (for example, "iad" for US East, "fra" for Frankfurt, etc.), and use it in your deploy command: Replace
<region> with the valid 3-character code you found.
If you need more details about Fly.io regions, you can also check the Fly.io regions documentation.
Let me know if you need more help!
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @lazi, 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?
Let me check the knowledge base for you again. One moment! :books:
----------------------
Based on your output, you are using the correct region code (fra for Frankfurt) as listed by flyctl platform regions. However, Wasp is still reporting "Invalid region code fra."
From the knowledge sources, here are some things to check:
1. Wasp CLI Version:Make sure you are using a recent version of Wasp. There have been bug fixes related to deployment and region handling in recent releases. You can check your version with
wasp version and upgrade if needed as described in the docs and Discord threads.Discord: Issue with deploying my wasp app to fly.io 2. Region Code Format:
The region code should be a 3-character code, which
fra is. The docs confirm this is the correct format.Wasp Docs: Fly.io Regions 3. Command Syntax:
The correct syntax for launching is: For your case: Make sure there are no extra spaces or line breaks between the app name and region code. 4. Organization Flag:
If you are a member of multiple Fly.io organizations, you may need to specify the organization with
--org <org-slug>.Wasp Docs: Deploying with the Wasp CLI If you have confirmed all of the above and the error persists, the knowledge sources do not provide a direct solution for this specific issue. It may be a bug or a temporary issue with the Wasp CLI or Fly.io integration. Next Steps: - Double-check your Wasp version and upgrade if necessary. - Try specifying the organization with
--org if applicable.
- If the problem continues, consider opening an issue on the Wasp GitHub or asking in the Wasp Discord for further troubleshooting, as this may be an edge case not covered in the current documentation.
Let me know if you need help with any of these steps!
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @lazi, 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?Oupsie daisy - worked now - it Was a problem with the wasp version i was using
@kapa.ai Can you help me out with this? seems like pg-boss fails
Let me check the knowledge base for you again. One moment! :books:
----------------------
Certainly! Based on the knowledge sources, the issue where pg-boss fails to start is a known problem that several Wasp users have encountered, especially on macOS (including M1/M2 chips). The error typically looks like this:
This means that pg-boss (which Wasp uses for background jobs) is unable to connect to your Postgres database. Here are the main findings and troubleshooting steps from the community and Wasp team:
---
1. Database Connectivity
- Ensure your Postgres database is running and accessible on port 5432.
- Run
Change
to
Discord: pg-boss failed to start! 3. Job Configuration - If you do not need background jobs, you can comment out or remove the
- Double-check your database is running and accessible. - Try changing
Github Issue: Pg-boss connection is having hard time establishing itself after app restart ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Grimm, 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?
wasp start db in one terminal and keep it running, then in another terminal run wasp start for your app. Both need to be running in parallel for things to work properly.
- You can check if the database is accessible by running wasp db studio while the DB is running. If it opens the Prisma Studio, your DB is up and reachable.
2. IPv6 vs IPv4 Issue
- Some users have found that changing the database URL from localhost to 127.0.0.1 in their environment variables resolves the issue, as Node.js sometimes fails to resolve localhost correctly on some systems (especially on macOS M1/M2).
- Example:Change
to
Discord: pg-boss failed to start! 3. Job Configuration - If you do not need background jobs, you can comment out or remove the
job declarations (like job emailChecker) in your main.wasp file. This will prevent pg-boss from starting and can be a temporary workaround if you don't need job functionality.
- Several users reported that commenting out the job section allowed their app to start without errors, confirming the issue is isolated to pg-boss and not the database itself.
4. Restarting and Cleaning
- Sometimes, restarting your machine or running wasp clean can help, but for this specific issue, the root cause is usually the database connection details or the way pg-boss interacts with the DB after a restart.
5. Platform-Specific Issues
- The Wasp team has not been able to consistently reproduce this on Linux, but it appears more frequently on macOS, especially with M1/M2 chips. They are investigating further, but no definitive fix is available yet.
---
Summary:- Double-check your database is running and accessible. - Try changing
localhost to 127.0.0.1 in your database URL.
- If you don't need jobs, comment out the job declarations in your Wasp file.
- If the issue persists, it may be a platform-specific bug that the Wasp team is still investigating.
If you can provide logs from wasp start db and your environment details (OS, Node version, Wasp version), it may help further diagnose the issue. Let me know if you need help with any of these steps!
Relevant Discord threadGithub Issue: Pg-boss connection is having hard time establishing itself after app restart ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Grimm, 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'm trying to deploy on fly but i can't seem to be able to re-attach my db properly
Let me check the knowledge base for you again. One moment! :books:
----------------------
If you're having trouble re-attaching your database when deploying your Wasp app to Fly.io, this is a known issue that can occur if the initial deployment or database attachment fails, or if the app/database names get out of sync. Here are the key points and steps from the knowledge sources:
1. Naming Issues & Attachment Problems
If Fly.io generates a unique name for your app (e.g., appending a suffix to avoid name collisions), the Wasp CLI might not correctly attach the database because it expects a certain naming convention. For example, the CLI might look for
CLI deploy fly.io unique name issue 2. Manual Database Attachment
If the automatic process fails, you can manually attach the database using the Fly CLI. The command generally looks like: Make sure you use the exact names as shown in your Fly.io dashboard. 3. Cleaning Up and Retrying
If you encounter persistent issues, you may need to destroy the problematic Fly apps and start over. Use: This ensures you can re-create and re-attach resources cleanly, as Fly.io does not allow multiple apps with the same name.
Manual deployment docs 4. .toml Files and Redeployment
If you have existing
Ensure your environment variables, especially
If Fly.io generates a unique name for your app (e.g., appending a suffix to avoid name collisions), the Wasp CLI might not correctly attach the database because it expects a certain naming convention. For example, the CLI might look for
open-saas-wispy-fire-4715-server but the actual app is named differently, causing the attach command to fail. This is a known issue and can prevent re-attachment from working as expected.CLI deploy fly.io unique name issue 2. Manual Database Attachment
If the automatic process fails, you can manually attach the database using the Fly CLI. The command generally looks like: Make sure you use the exact names as shown in your Fly.io dashboard. 3. Cleaning Up and Retrying
If you encounter persistent issues, you may need to destroy the problematic Fly apps and start over. Use: This ensures you can re-create and re-attach resources cleanly, as Fly.io does not allow multiple apps with the same name.
Manual deployment docs 4. .toml Files and Redeployment
If you have existing
fly.toml files from previous deployments, Wasp may skip some steps or get confused. You can back up or remove these files before retrying, or regenerate them with:
Redeploying after Wasp builds
5. Check Environment VariablesEnsure your environment variables, especially
DATABASE_URL, are set correctly on Fly. You can set them with:
If you continue to have trouble, please provide the exact error message or describe where in the process it fails, as the knowledge sources do not contain a step-by-step fix for every possible scenario. But the above steps should help resolve most re-attachment issues with Fly.io and Wasp.
If the problem is due to a bug in the Wasp CLI's handling of app/database names, you may need to follow the manual steps above until a fix is released.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Grimm, 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 pg-boss failed to start!
2025-09-17T11:20:19.487 app[1781252b572048] mia [info] error: cannot execute DELETE in a read-only transaction
Let me check the knowledge base for you again. One moment! :books:
----------------------
The error message:
indicates that pg-boss is trying to perform a
pg-boss cannot function with a read-only database. You need to ensure your database is writable for Wasp jobs to work. The knowledge sources do not provide a direct solution for this specific error, but this is the logical next step based on how pg-boss operates and the context provided in the sources. If you need more help, please provide details about your database setup and how it is configured on Fly.io. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Grimm, 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?
DELETE operation on your database, but the database is in read-only mode. This is a different issue from the common connection errors discussed in the knowledge sources.
From the available knowledge sources, there is no explicit mention of this specific "read-only transaction" error with pg-boss in Wasp deployments. However, based on the context of similar issues:
- pg-boss requires write access to the database to manage its job queue (it needs to insert, update, and delete records).
- If your database is in read-only mode (for example, if you are connected to a read replica, or your database is in a restricted state on Fly.io), pg-boss will fail to start because it cannot perform the necessary write operations.
What you can do:
- Ensure that your database is not in read-only mode and that the user Wasp/pg-boss connects with has full write permissions.
- Double-check your DATABASE_URL and Fly.io database configuration to make sure you are connecting to the primary (writable) instance, not a read replica.
If you are using Fly.io's managed Postgres, make sure you are connecting to the primary database app, not a replica, and that the database is healthy and accepting writes.
Summary:pg-boss cannot function with a read-only database. You need to ensure your database is writable for Wasp jobs to work. The knowledge sources do not provide a direct solution for this specific error, but this is the logical next step based on how pg-boss operates and the context provided in the sources. If you need more help, please provide details about your database setup and how it is configured on Fly.io. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Grimm, 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 How can i find the proper database URL ?
Let me check the knowledge base for you again. One moment! :books:
----------------------
To find the proper database URL for your Wasp app—especially when deploying to Fly.io—you need the database name, user, and password. Here’s how you can obtain these details according to the knowledge sources:
1. Get the Database Name:
- Connect to your Fly.io Postgres instance:
- Once connected, list the databases:
- The database name is usually in the format of your server app name with underscores (e.g.,
See: Github Issue #1464 2. Get the Database Password: - SSH into your Fly.io Postgres app: - Then run: - This will print the password for the
See: Github Issue #1464 3. Construct the DATABASE_URL: - The format is: - Example: 4. If Connecting Locally via Tunnel: - Open a tunnel to your production database: - Then use the above
- Make sure nothing else is running on port 5432 locally when you open the tunnel. - Remove the production
my_app_server)See: Github Issue #1464 2. Get the Database Password: - SSH into your Fly.io Postgres app: - Then run: - This will print the password for the
postgres userSee: Github Issue #1464 3. Construct the DATABASE_URL: - The format is: - Example: 4. If Connecting Locally via Tunnel: - Open a tunnel to your production database: - Then use the above
DATABASE_URL with localhost:5432 as the host.
Note:- Make sure nothing else is running on port 5432 locally when you open the tunnel. - Remove the production
DATABASE_URL from your local .env.server after you’re done to avoid accidental changes to your production database.
For more details, see the step-by-step workflow in Github Issue #1464.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Grimm, 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?@Wasp Computer Persons any ideas?
@Grimm could you check the disk space your database has? You might have filled the 1GB default disk space.
Go to
https://fly.io/apps/<db-app-name>/volumes where <db-app-name> is your Fly DB app name and check.
I've managed to re-attach the db but I do have some deployment problem now (on wasp 0.16.2) -
@kapa.ai
"name": "DATABASE_URL",
"digest": "83c920085c64dff0"
},
{
"name": "DIRECT_DATABASE_URL",
"digest": "83c920085c64dff0"
}
]
🚀 Your server app does not have a DATABASE_URL secret set. Perhaps you need to create or attach your database?
Let me check the knowledge base for you again. One moment! :books:
----------------------
The error message:
means that your Fly.io server app is missing the
DATABASE_URL secret, which is required for your Wasp app to connect to the database.
How to fix:
You need to set the DATABASE_URL secret for your server app on Fly.io. You can do this with the following command:
Replace <your-database-url> with the correct connection string (as described in previous answers), and <your-server-app-name> with the name of your Fly.io server app.
This step is necessary even if you have re-attached the database, as the secret must be present for the server to connect to the database at runtime. The Wasp deployment process expects this secret to be set, and Fly.io uses secrets to securely provide environment variables to your app at runtime Deploying Manually: Environment Variables.
If you need help constructing the correct DATABASE_URL, see the previous answer or the relevant GitHub issue.
If you continue to see this error after setting the secret, double-check that you are setting it for the correct app and that there are no typos in the secret name.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Grimm, 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 clearly have the Database URL right there (and it works)
Let me check the knowledge base for you again. One moment! :books:
Wohooo @Grimm, you just became a Waspeteer level 9!
----------------------
If you are seeing the error:
even though you have set the
- You must set the secret for the server app specifically, using: See: Deploying Manually: Environment Variables - Even if the database is attached, the secret may not be set automatically, especially if you re-attached the database or changed app names.
See: Github Issue #1464 - The error message is triggered by the absence of the secret in the server app’s environment, not by the actual connectivity to the database. Summary:
You need to explicitly set the
DATABASE_URL and it works, this usually means that the secret is not set in the Fly.io environment for your server app—even if it exists elsewhere (like in your local .env.server or in a different Fly app).
Key points from the knowledge sources:
- Wasp and Fly.io require the DATABASE_URL to be set as a secret in the Fly.io app environment, not just in your local files or in the database app.- You must set the secret for the server app specifically, using: See: Deploying Manually: Environment Variables - Even if the database is attached, the secret may not be set automatically, especially if you re-attached the database or changed app names.
See: Github Issue #1464 - The error message is triggered by the absence of the secret in the server app’s environment, not by the actual connectivity to the database. Summary:
You need to explicitly set the
DATABASE_URL secret for your server app on Fly.io, even if you have already attached the database and the URL is correct elsewhere. This is a requirement for Wasp deployments on Fly.io.
If you have already done this and still see the error, double-check that:
- You are setting the secret for the correct Fly.io app (-a <your-server-app-name>).
- There are no typos in the secret name (DATABASE_URL must be exact).
- The deployment is targeting the correct app.
If the problem persists after confirming all of the above, the knowledge sources do not provide further troubleshooting steps for this specific scenario.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Grimm, 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?This worked for me btw 😄 Forgot to mention. Solved the problem with just upgrading to 0.16.7
AND it was a combo with this too - after a while the DB went into read-only killing my login & some features. But worked with scaling further