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!
11 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!