wasp deploy fly deploy fails with DATABASE_URL error even though secret exists - v0.15.2
Getting this error when running wasp deploy fly deploy:
🚀 Your server app does not have a DATABASE_URL secret set. Perhaps you need to create or attach your
database?
The problem: DATABASE_URL IS set on Fly and the app is running fine:
$ fly secrets list -a myapp-server | grep DATABASE_URL
DATABASE_URL 44432e8ef938bde0
$ fly ssh console -a myapp-server -C 'printenv DATABASE_URL'
postgres://myapp_server:***@myapp-db.flycast:5432/myapp_server?sslmode=disable
I've tried:
- Setting DATABASE_URL in .env.server ❌
- Removing it from .env.server ❌
- Running DATABASE_URL=... wasp deploy fly deploy ❌
- Re-setting secret with fly secrets set ❌
- wasp clean and rebuild ❌
All give the same error. The deployment check fails before even reaching Fly.
Current workaround:
wasp build
cd .wasp/build && fly deploy -a myapp-server
cd web-app && REACT_APP_API_URL=https://myapp-server.fly.dev npm run build
# manually create Dockerfile with port 8043
fly deploy -a myapp-client
Setup:
- Wasp 0.15.2
- Everything was working fine until recent changes to add redirects and robots.txt
- Server is still running perfectly in production with database connected
My hypothesis:
Wasp's deploy script might be running flyctl secrets list -j without the -a myapp-server flag, causing it to
not find the DATABASE_URL even though it's properly set.
Is this a known bug? Any fixes? I would like to continue using wasp
deploy fly deploy as intended if possible!
18 Replies
Hi @Spacepope. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Thanks for the detailed report — you’re not alone in hitting DATABASE_URL confusion during Fly deploys.
What we know from the sources:
- Wasp requires DATABASE_URL at runtime on the server; it’s expected to be provided as a Fly secret (along with other required env vars). [Env vars]
- There’s a history of Prisma/Wasp surfacing DATABASE_URL errors during build/deploy even when things are correctly set on Fly. In some cases users could ignore it; in others it blocked deploy, and people worked around it by injecting DATABASE_URL inline or deploying with raw flyctl. [Error during build; Prisma warning; Discord thread]
- Wasp CLI can run arbitrary Fly commands with an explicit context; there’s also an open issue to improve error handling during Fly deploy to make failures clearer and more actionable. [CLI cmd; Improve Fly deploy errors] What I can’t confirm from the sources: - I don’t see a documented bug specifically for v0.15.2 where wasp deploy fly deploy checks secrets without scoping to the server app (-a myapp-server). Your hypothesis is plausible, but I can’t find an issue or commit that confirms it. The knowledge sources do not explicitly mention this as a known bug. Practical next steps you can try (based on docs and known patterns): 1) Verify the secret via Wasp CLI passthrough (scoped to server)
- Run: wasp deploy fly cmd secrets list --context server and check DATABASE_URL is present. This ensures the Wasp CLI is talking to the server app context you expect. [CLI cmd] 2) Double-check other required server env vars exist on Fly
- Missing required vars (WASP_WEB_CLIENT_URL, WASP_SERVER_URL, JWT_SECRET) can also derail deploys; make sure they’re set as Fly secrets on the server app. [Env vars] 3) If build-time Prisma still complains, confirm it’s not blocking deploy due to a local DATABASE_URL check
- Historically, Prisma emits “Environment variable not found: DATABASE_URL” during build when not needed yet. If this blocks, your current workaround (manual fly deploy from .wasp/build) is consistent with what others did. [Error during build; Discord thread] 4) If the Wasp CLI still reports “Your server app does not have a DATABASE_URL secret set”
- Given your secret is clearly set and readable via flyctl and fly ssh, this points to a CLI-side detection issue. There’s an open issue to improve Fly deploy error handling; if this is a mis-scoped secrets check, it would fit that category. I recommend opening an issue with your logs so the team can fix it (include Wasp version, command used, and output of wasp deploy fly cmd secrets list --context server). [Improve Fly deploy errors] Workable paths until fixed: - Keep using your manual deployment flow (build with wasp build, then fly deploy from .wasp/build) — that’s valid and aligns with others’ temporary workarounds when the CLI mis-detects env. [Error during build]
- Ensure Fly secrets are set exactly as the docs require (server app secrets). [Env vars] If you’d like, paste the output of: - wasp --version - wasp deploy fly cmd secrets list --context server - The exact CLI error text from wasp deploy fly deploy I can help pinpoint whether it’s a scoping/detection bug in the CLI versus a missing var. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Spacepope, 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?
- There’s a history of Prisma/Wasp surfacing DATABASE_URL errors during build/deploy even when things are correctly set on Fly. In some cases users could ignore it; in others it blocked deploy, and people worked around it by injecting DATABASE_URL inline or deploying with raw flyctl. [Error during build; Prisma warning; Discord thread]
- Wasp CLI can run arbitrary Fly commands with an explicit context; there’s also an open issue to improve error handling during Fly deploy to make failures clearer and more actionable. [CLI cmd; Improve Fly deploy errors] What I can’t confirm from the sources: - I don’t see a documented bug specifically for v0.15.2 where wasp deploy fly deploy checks secrets without scoping to the server app (-a myapp-server). Your hypothesis is plausible, but I can’t find an issue or commit that confirms it. The knowledge sources do not explicitly mention this as a known bug. Practical next steps you can try (based on docs and known patterns): 1) Verify the secret via Wasp CLI passthrough (scoped to server)
- Run: wasp deploy fly cmd secrets list --context server and check DATABASE_URL is present. This ensures the Wasp CLI is talking to the server app context you expect. [CLI cmd] 2) Double-check other required server env vars exist on Fly
- Missing required vars (WASP_WEB_CLIENT_URL, WASP_SERVER_URL, JWT_SECRET) can also derail deploys; make sure they’re set as Fly secrets on the server app. [Env vars] 3) If build-time Prisma still complains, confirm it’s not blocking deploy due to a local DATABASE_URL check
- Historically, Prisma emits “Environment variable not found: DATABASE_URL” during build when not needed yet. If this blocks, your current workaround (manual fly deploy from .wasp/build) is consistent with what others did. [Error during build; Discord thread] 4) If the Wasp CLI still reports “Your server app does not have a DATABASE_URL secret set”
- Given your secret is clearly set and readable via flyctl and fly ssh, this points to a CLI-side detection issue. There’s an open issue to improve Fly deploy error handling; if this is a mis-scoped secrets check, it would fit that category. I recommend opening an issue with your logs so the team can fix it (include Wasp version, command used, and output of wasp deploy fly cmd secrets list --context server). [Improve Fly deploy errors] Workable paths until fixed: - Keep using your manual deployment flow (build with wasp build, then fly deploy from .wasp/build) — that’s valid and aligns with others’ temporary workarounds when the CLI mis-detects env. [Error during build]
- Ensure Fly secrets are set exactly as the docs require (server app secrets). [Env vars] If you’d like, paste the output of: - wasp --version - wasp deploy fly cmd secrets list --context server - The exact CLI error text from wasp deploy fly deploy I can help pinpoint whether it’s a scoping/detection bug in the CLI versus a missing var. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Spacepope, 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
$ wasp --version 0.15.2 $ wasp deploy fly cmd secrets list --context server NAME DIGEST JWT_SECRET 4eaf5486b1a49d2d PORT 331687776d319529 WASP_SERVER_URL b18102bda943f71b WASP_WEB_CLIENT_URL 490534b7235a1c10 DATABASE_URL 44432e8ef938bde0 $ wasp deploy fly deploy [... build output ...] $ flyctl secrets list -j [ { "name": "DATABASE_URL", "digest": "44432e8ef938bde0" }, [... other secrets ...] ] 🚀 Your server app does not have a DATABASE_URL secret set. Perhaps you need to create or attach your database? ❌ --- [Error] Deploy command failed: --------------------------------------------- Deploy command failed with exit code: 1 I think Wasp runs flyctl secrets list -j, receives DATABASE_URL in the response, but still reports it as missing. This appears to be a parsing bug in Wasp v0.15.2?
$ wasp --version 0.15.2 $ wasp deploy fly cmd secrets list --context server NAME DIGEST JWT_SECRET 4eaf5486b1a49d2d PORT 331687776d319529 WASP_SERVER_URL b18102bda943f71b WASP_WEB_CLIENT_URL 490534b7235a1c10 DATABASE_URL 44432e8ef938bde0 $ wasp deploy fly deploy [... build output ...] $ flyctl secrets list -j [ { "name": "DATABASE_URL", "digest": "44432e8ef938bde0" }, [... other secrets ...] ] 🚀 Your server app does not have a DATABASE_URL secret set. Perhaps you need to create or attach your database? ❌ --- [Error] Deploy command failed: --------------------------------------------- Deploy command failed with exit code: 1 I think Wasp runs flyctl secrets list -j, receives DATABASE_URL in the response, but still reports it as missing. This appears to be a parsing bug in Wasp v0.15.2?
Let me check the knowledge base for you again. One moment! :books:
----------------------
Thanks for providing the exact outputs — that’s really helpful.
What your logs show:
- The secret clearly exists on the server app (both via wasp deploy fly cmd … and via the JSON snippet during deploy). [cmd]
- Yet the deploy step still reports “Your server app does not have a DATABASE_URL secret set,” and exits. From the knowledge sources, this matches a class of issues where Wasp’s Fly deploy flow mis-detects env/secrets and fails early, even though Fly has the correct secret. There are open threads about confusing/misleading DATABASE_URL errors and calls to improve error handling in the Fly deploy path, but I don’t see a source explicitly documenting this exact v0.15.2 parsing bug. So I can’t confirm it as a known, tracked bug by version. [Improve Fly deploy errors; Env var error threads; Prisma warning] Given your evidence, your hypothesis (the CLI gets the secret but mis-evaluates it) is plausible. What you can do now: - Continue using your manual flow (wasp build → fly deploy from .wasp/build) — this is a valid workaround when the CLI’s deploy path mis-detects secrets. [Deploy manually; Env vars] - Use Wasp’s passthrough to double-check context anytime:
wasp deploy fly cmd secrets list --context server — you’ve already done this and it confirms DATABASE_URL is present for the server app. [cmd] - If you haven’t already, please open an issue with the exact snippet you shared (showing flyctl secrets list -j returning DATABASE_URL, followed by the CLI claiming it’s missing). The team is already tracking improvements to error handling in Fly deploys, and this would be a concrete repro to address. [Improve Fly deploy errors] If you’d like, I can help draft a minimal repro summary for the issue based on your outputs. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Spacepope, 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?
- Yet the deploy step still reports “Your server app does not have a DATABASE_URL secret set,” and exits. From the knowledge sources, this matches a class of issues where Wasp’s Fly deploy flow mis-detects env/secrets and fails early, even though Fly has the correct secret. There are open threads about confusing/misleading DATABASE_URL errors and calls to improve error handling in the Fly deploy path, but I don’t see a source explicitly documenting this exact v0.15.2 parsing bug. So I can’t confirm it as a known, tracked bug by version. [Improve Fly deploy errors; Env var error threads; Prisma warning] Given your evidence, your hypothesis (the CLI gets the secret but mis-evaluates it) is plausible. What you can do now: - Continue using your manual flow (wasp build → fly deploy from .wasp/build) — this is a valid workaround when the CLI’s deploy path mis-detects secrets. [Deploy manually; Env vars] - Use Wasp’s passthrough to double-check context anytime:
wasp deploy fly cmd secrets list --context server — you’ve already done this and it confirms DATABASE_URL is present for the server app. [cmd] - If you haven’t already, please open an issue with the exact snippet you shared (showing flyctl secrets list -j returning DATABASE_URL, followed by the CLI claiming it’s missing). The team is already tracking improvements to error handling in Fly deploys, and this would be a concrete repro to address. [Improve Fly deploy errors] If you’d like, I can help draft a minimal repro summary for the issue based on your outputs. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Spacepope, 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?
Maybe this is a bug I have created somehow?
wasp deploy fly deploy fails with DATABASE_URL error even though secret exists (v0.15.2)
I'm getting a deployment blocker where wasp deploy fly deploy fails with:
🚀 Your server app does not have a DATABASE_URL secret set. Perhaps you need to create or attach your
database?
The issue: DATABASE_URL IS set and the app is running fine in production. The bug is that Wasp runs flyctl
secrets list -j, receives DATABASE_URL in the response, but still reports it missing.
Evidence:
# DATABASE_URL exists in Fly secrets
$ wasp deploy fly cmd secrets list --context server | grep DATABASE_URL
DATABASE_URL 44432e8ef938bde0
# But wasp deploy fails, even though it gets DATABASE_URL back
$ wasp deploy fly deploy
[... builds successfully ...]
$ flyctl secrets list -j
[{"name": "DATABASE_URL", "digest": "44432e8ef938bde0"}, ...]
🚀 Your server app does not have a DATABASE_URL secret set.
❌ Deploy command failed with exit code: 1
What I've tried:
- ✅ Verified DATABASE_URL exists with fly secrets list -a myapp-server
- ✅ Set DATABASE_URL in .env.server
- ✅ Exported DATABASE_URL before running deploy
- ✅ Re-set the secret with fly secrets set
All produce the same error. Manual deployment with fly deploy works perfectly.
Environment: Wasp 0.15.2, Fly.io, PostgreSQL
Is this a known issue? Currently using manual deployment as a workaround.
Wohooo @Spacepope, you just became a Waspeteer level 1!
@Wasp Computer Persons any idea? @miho ?
@Spacepope What is your Fly version? I have a feeling this is related to newer Fly versions returning secrets in a different way which broke older Wasp CLI versions... which we fixed since 0.16.4 https://github.com/wasp-lang/wasp/releases/tag/v0.16.4
I'd suggest upgrading to Wasp 0.16.7 as the best course of action. The migration from 0.15.X to 0.16.X is really painless: https://wasp.sh/docs/migration-guides/migrate-from-0-15-to-0-16#1-bump-the-wasp-version
GitHub
Release v0.16.4 · wasp-lang/wasp
🐞 Bug fixes
Adds support for the latest version of Fly.io CLI (v0.3.121 or greater) (#2760)
Thank you for your reply:
fly v0.3.180 darwin/arm64 Commit: 5c11421b5f562b2032f4c6fde217a76e919de095 BuildDate: 2025-09-15T20:58:40Z
Yes, it got broken with Fly version
0.3.121 so you should upgrade Wasp IMHO 🙂Yes, this worked thank you so much!
Sweet, I'm glad it worked out!
@kapa.ai #16 [server-builder 8/11] RUN npm install && cd .wasp/build/server && npm install
#16 22.19 npm WARN EBADENGINE Unsupported engine {
#16 22.19 npm WARN EBADENGINE package: 'undici@7.11.0',
#16 22.19 npm WARN EBADENGINE required: { node: '>=20.18.1' },
#16 22.19 npm WARN EBADENGINE current: { node: 'v20.0.0', npm: '9.6.4' }
#16 22.19 npm WARN EBADENGINE }
#16 34.36 npm WARN deprecated oslo@1.2.1: Package is no longer supported. Please see https://oslojs.dev for the successor project.
#16 53.41 npm WARN deprecated abab@2.0.6: Use your platform's native atob() and btoa() methods instead
#16 157.2 npm WARN deprecated q@1.5.1: You or someone you depend on is using Q, the JavaScript Promise library that gave JavaScript developers strong feelings about promises. They can almost certainly migrate to the native JavaScript promise now. Thank you literally everyone for joining me in this bet against the odds. Be excellent to each other.
#16 157.2 npm WARN deprecated #16 157.2 npm WARN deprecated (For a CapTP with native promises, see @endo/eventual-send and @endo/captp) #16 275.8 npm WARN deprecated domexception@4.0.0: Use your platform's native DOMException instead I've switched between npm versions and wasp versions for a bit, got back to 0.16.7 and got this error on deployment on fly. Can you help me out?
#16 157.2 npm WARN deprecated #16 157.2 npm WARN deprecated (For a CapTP with native promises, see @endo/eventual-send and @endo/captp) #16 275.8 npm WARN deprecated domexception@4.0.0: Use your platform's native DOMException instead I've switched between npm versions and wasp versions for a bit, got back to 0.16.7 and got this error on deployment on fly. Can you help me out?
Oslo
Oslo
Oslo is an open-source project that aims to provide simple, high-quality auth
packages for server-side JS.
Let me check the knowledge base for you again. One moment! :books:
----------------------
Thanks for sharing the build log. Let's break down what's happening:
The core issue
Your Fly deployment is failing during the Docker build step because the Node.js version in the build container (v20.0.0) doesn't meet the requirements of one of your dependencies (
After running
While this shouldn't directly affect the Fly build (which uses its own container), make sure your local environment is using Node >= 20.18.1 to avoid any local build issues: [Requirements] 3. Try the manual deployment flow to inspect the Dockerfile
If it's using an old Node 20.0.0 base image, that's the root cause. What I cannot confirm from the sources The knowledge sources do not contain information about: - The exact Node version used in Wasp 0.16.7's generated Dockerfile - Whether there's a known issue with Wasp 0.16.7 pinning Node to 20.0.0 in the build container - How to override the Node version in Wasp's generated Dockerfile for Fly deployments Recommended next step Since the npm warning is non-fatal (it's a WARN, not an error), did the deployment actually fail, or did it complete despite the warning? The warnings you showed (deprecated packages, engine mismatch) are common and usually don't block deployment. If the deployment truly failed, please share: - The actual error message that stopped the build (after the warnings) - The output of
undici@7.11.0, which requires Node >= 20.18.1).
What Wasp requires
According to the documentation, Wasp requires Node.js version >= 18. The docs specifically mention that "A version of Node.js must be >= 18" and recommend using nvm to manage versions. [Requirements]
From the knowledge sources, I can see that:
- Wasp previously had stricter Node version requirements (only LTS versions)
- As of recent versions, Wasp relaxed this to allow any Node version >= 18 (no upper limit) [Upgrade Node version requirement to 20; Getting Started Issues]
- The change to support Node >= 18 (including Node 20+) was merged and released in versions after 0.11.x [Upgrade Node version requirement to 20]
Your specific problem
The build container is using Node v20.0.0, but your dependency tree includes undici@7.11.0 which requires Node >= 20.18.1. This is a mismatch between:
1. What Wasp's Dockerfile specifies for the build environment
2. What your transitive dependencies require
What you can try
1. Check which Dockerfile Wasp is generating for your deploymentAfter running
wasp build, inspect .wasp/build/Dockerfile to see which Node version is being used in the base image. Wasp 0.16.7 should be generating a Dockerfile with a recent Node 20.x version, but if it's pinned to 20.0.0, that would explain the issue.
2. Ensure your local Node version is up to dateWhile this shouldn't directly affect the Fly build (which uses its own container), make sure your local environment is using Node >= 20.18.1 to avoid any local build issues: [Requirements] 3. Try the manual deployment flow to inspect the Dockerfile
If it's using an old Node 20.0.0 base image, that's the root cause. What I cannot confirm from the sources The knowledge sources do not contain information about: - The exact Node version used in Wasp 0.16.7's generated Dockerfile - Whether there's a known issue with Wasp 0.16.7 pinning Node to 20.0.0 in the build container - How to override the Node version in Wasp's generated Dockerfile for Fly deployments Recommended next step Since the npm warning is non-fatal (it's a WARN, not an error), did the deployment actually fail, or did it complete despite the warning? The warnings you showed (deprecated packages, engine mismatch) are common and usually don't block deployment. If the deployment truly failed, please share: - The actual error message that stopped the build (after the warnings) - The output of
cat .wasp/build/Dockerfile | grep "FROM node" after running wasp build
That will help pinpoint whether this is a Dockerfile base image issue or something else.
----------------------
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 FROM node:20.0.0-alpine3.17 AS node
Let me check the knowledge base for you again. One moment! :books:
----------------------
Thanks for confirming — that's the root cause.
Your Wasp 0.16.7 deployment is using Node 20.0.0 in the Dockerfile base image (
FROM node:20.0.0-alpine3.17), but your dependency undici@7.11.0 requires Node >= 20.18.1.
Why this is happening
The knowledge sources show that Wasp has historically pinned specific Node versions in its generated Dockerfile. For example:
- There was an issue to upgrade from Node 14 to Node 16 in the Dockerfile [Change Node base image version in Dockerfile to 16]
- The Dockerfile template is maintained by Wasp and can change between versions [Customizing the Dockerfile]
However, I don't see information in the knowledge sources about when Wasp 0.16.7 specifically updated its Dockerfile to use a newer Node 20.x patch version.
How to fix it
You can customize the Dockerfile to use a newer Node 20 base image. According to the docs, if you create a Dockerfile in your project root, Wasp will append its contents to the generated Dockerfile (or you can override stages entirely). [Customizing the Dockerfile]
Option 1: Override the base Node image
Create a Dockerfile in your project root (same directory as main.wasp) with:
This will override Wasp's FROM node:20.0.0-alpine3.17 AS node line, since "the last definition in a Dockerfile wins." [Customizing the Dockerfile]
Option 2: Verify the combined Dockerfile before deploying
After creating your custom Dockerfile, run:
This shows you the final combined Dockerfile that will be used, so you can confirm the Node version is correct. [Customizing the Dockerfile]
Then deploy:
Important notes
- Make sure your custom Dockerfile only overrides the node stage; don't accidentally break later stages unless you reproduce them.
- The generated Dockerfile's content is dynamic and can change in future Wasp releases, so verify it periodically. [Customizing the Dockerfile]
This should resolve the undici engine warning and allow your deployment to proceed. Let me know if you hit any issues after trying this!
----------------------
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 This is the full message: > [server-builder 8/11] RUN npm install && cd .wasp/build/server && npm install:
463.2 npm notice
463.2 npm ERR! code ERR_SOCKET_TIMEOUT
463.2 npm ERR! network Socket timeout
463.2 npm ERR! network This is a problem related to network connectivity.
463.2 npm ERR! network In most cases you are behind a proxy or have bad network settings.
463.2 npm ERR! network
463.2 npm ERR! network If you are behind a proxy, please make sure that the
463.2 npm ERR! network 'proxy' config is set properly. See: 'npm help config'
463.2
463.2 npm ERR! A complete log of this run can be found in: /root/.npm/_logs/2025-11-05T14_01_46_109Z-debug-0.log
------ 2025/11/05 16:09:29 error releasing builder: deadline_exceeded: context deadline exceeded Error: failed to fetch an image or build from source: error building: failed to solve: process "/bin/sh -c npm install && cd .wasp/build/server && npm install" did not complete successfully: exit code: 1 at Proxy.set (/home/lazi/.local/share/wasp-lang/0.16.7/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.7/data/packages/deploy/node_modules/zx/build/core.cjs:416:41) at EventEmitter.emit (node:events:530:35) at ChildProcess.<anonymous> (/home/lazi/.local/share/wasp-lang/0.16.7/data/packages/deploy/node_modules/zx/build/vendor-core.cjs:502:16) at Object.onceWrapper (node:events:633:26) at ChildProcess.emit (node:events:518:28) at maybeClose (node:internal/child_process:1104: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], _combined: [Getter], _duration: [Getter] ❌ --- [Error] Deploy command failed: ---------------------------------------------
Deploy command failed with exit code: 1
------ 2025/11/05 16:09:29 error releasing builder: deadline_exceeded: context deadline exceeded Error: failed to fetch an image or build from source: error building: failed to solve: process "/bin/sh -c npm install && cd .wasp/build/server && npm install" did not complete successfully: exit code: 1 at Proxy.set (/home/lazi/.local/share/wasp-lang/0.16.7/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.7/data/packages/deploy/node_modules/zx/build/core.cjs:416:41) at EventEmitter.emit (node:events:530:35) at ChildProcess.<anonymous> (/home/lazi/.local/share/wasp-lang/0.16.7/data/packages/deploy/node_modules/zx/build/vendor-core.cjs:502:16) at Object.onceWrapper (node:events:633:26) at ChildProcess.emit (node:events:518:28) at maybeClose (node:internal/child_process:1104: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], _combined: [Getter], _duration: [Getter] ❌ --- [Error] Deploy command failed: ---------------------------------------------
Deploy command failed with exit code: 1
Let me check the knowledge base for you again. One moment! :books:
----------------------
Thanks for sharing the full error — this is a different issue from the Node version mismatch.
The actual problem
Your deployment is failing because
Network timeouts during remote builds are often transient. Simply run: again. Fly's remote builder may have better connectivity on the next attempt. 2. Build locally instead of using Fly's remote builder
Wasp's Fly deployment defaults to using a remote builder on Fly's infrastructure. You can switch to building the Docker image locally (on your machine) and then pushing it to Fly: This bypasses Fly's remote builder network and uses your local network for npm installs. [Building Locally] 3. If local builds also fail with network errors
- Check your own network/proxy settings - Try
npm install is timing out during the Docker build on Fly.io. The error is:
This is a network connectivity issue during the remote build process on Fly's infrastructure, not a problem with your Wasp configuration or Dockerfile.
What the knowledge sources say
From the documentation and issues, this type of npm network error during builds is a known class of problems:
- Users have reported similar npm ERR! network errors (like ECONNRESET, aborted) during wasp start and deployment builds [Discord thread]
- The npm error message itself states: "This is a problem related to network connectivity. In most cases you are behind a proxy or have bad network settings." [Discord thread]
- There's discussion about improving how Wasp handles long-running npm installs and network issues, but these are typically transient infrastructure problems [Get npm install to output more details; Show indicator during long npm install]
What you can try
1. Retry the deploymentNetwork timeouts during remote builds are often transient. Simply run: again. Fly's remote builder may have better connectivity on the next attempt. 2. Build locally instead of using Fly's remote builder
Wasp's Fly deployment defaults to using a remote builder on Fly's infrastructure. You can switch to building the Docker image locally (on your machine) and then pushing it to Fly: This bypasses Fly's remote builder network and uses your local network for npm installs. [Building Locally] 3. If local builds also fail with network errors
- Check your own network/proxy settings - Try
wasp clean in your project directory, then retry deployment [Discord thread]
- Ensure you're not behind a restrictive firewall or proxy that blocks npm registry access
Recommended immediate action
Run:
This should work around the Fly remote builder's network timeout by building on your local machine instead. [Building Locally]
Let me know if the local build succeeds or if you hit a different error!
----------------------
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?Thanks buddy - Building it locally did it for me 😄