Argon2 deployment issue on macOS ARM → Alpine Linux
Hi! I'm facing a deployment issue after developing on macOS ARM (Apple Silicon, M1).
My app crashes on startup with:
Error: Cannot find module './argon2.linux-x64-musl.node
Error: Cannot find module '@node-rs/argon2-linux-x64-musl
What I've tried:
Wasp versions: 0.16.6 → 0.17.1 → 0.16.0 (same errors)
wasp clean + rebuild
--build-locally (fails with Prisma SIGTRAP error)
docker builder prune -a
Modified .dockerignore
All deployment attempts loop with the same argon2 error
Setup:
Dev: macOS ARM (darwin/arm64)
Prod: Fly.io (with the Wasp deploy fly deploy command)
Issue: ARM binaries cached/bundled, incompatible with x64 production
The Docker cache (local + remote) seems to persist the wrong native binaries despite clean attempts. Currently running on rollback, but need to fix this for future deployments.
Any suggestions for forcing proper x64 argon2 binaries or invalidating the cache completely?
Thanks! 🙏
2 Replies
Hi @VerreD0. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
It looks like native binaries built for the wrong target are ending up in your image (musl x64 expected on Fly’s Alpine, but ARM-compiled artifacts leak in). Two concrete things from our docs/issues can help:
- Build on Fly’s remote builder (default) rather than locally, so the container is compiled in a consistent x64/musl environment. If you switched to local builds, revert to remote, or use the flag only when you truly need local builds. You can force a local/remote choice with the CLI flags; by default we use Fly’s remote builder for reproducibility (see “Building Locally”) (Deploy CLI docs).
- Ensure Alpine has the right OpenSSL for Prisma/Node native addons when using musl. There was a known issue where Prisma on Alpine required OpenSSL 1.1; the fix was to add openssl1.1-compat to the apk add line in the generated Dockerfile. We shipped a Wasp release that includes this fix, but if you’re on an affected version, add it manually to the server builder stage and rebuild to avoid crashes at generate/startup (railway build issue).
Given your symptoms, try: 1) Use the default remote build (no --build-locally) to avoid ARM host influence, and redeploy. If you previously built locally, this should refresh artifacts on Fly’s x64 builder (consistent musl). If you still want local builds, pass the flag explicitly and ensure your Docker build sets the correct platform (not covered in our docs for Fly, so I can’t provide exact flags from sources). 2) If your generated Dockerfile is from a version before the OpenSSL fix, add openssl1.1-compat to the apk add line in the server builder stage, then redeploy (this addresses Prisma/OpenSSL on Alpine) (railway build issue). 3) Clear out Wasp and node modules locally before the next build so no ARM-native artifacts are copied into the Docker context: - wasp clean - reinstall dependencies, then deploy again (the clean step helped similar “cannot find wasp/* modules” and Prisma issues) (Discord: missing wasp/* modules, Discord: Prisma error resolved by wasp clean). Notes/limits: - Our sources don’t document a Wasp CLI option to force x64 for Fly builds or a cache-busting toggle beyond using remote builders and cleaning the project. They also don’t include Argon2-specific steps.
- If you must build on Apple Silicon, Heroku required explicit linux/amd64 with buildx; similar flags might help, but we don’t have Fly-specific instructions in the sources to cite for that approach (Heroku M1 note). If after switching back to remote builds and cleaning you still get the Argon2 musl-x64 module error, please share the generated Dockerfile’s apk dependencies and confirm whether openssl1.1-compat is present, plus the exact Wasp version used to generate the Dockerfile, so we can check if you’re on the fixed template (railway build issue). ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @VerreD0, 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?
Given your symptoms, try: 1) Use the default remote build (no --build-locally) to avoid ARM host influence, and redeploy. If you previously built locally, this should refresh artifacts on Fly’s x64 builder (consistent musl). If you still want local builds, pass the flag explicitly and ensure your Docker build sets the correct platform (not covered in our docs for Fly, so I can’t provide exact flags from sources). 2) If your generated Dockerfile is from a version before the OpenSSL fix, add openssl1.1-compat to the apk add line in the server builder stage, then redeploy (this addresses Prisma/OpenSSL on Alpine) (railway build issue). 3) Clear out Wasp and node modules locally before the next build so no ARM-native artifacts are copied into the Docker context: - wasp clean - reinstall dependencies, then deploy again (the clean step helped similar “cannot find wasp/* modules” and Prisma issues) (Discord: missing wasp/* modules, Discord: Prisma error resolved by wasp clean). Notes/limits: - Our sources don’t document a Wasp CLI option to force x64 for Fly builds or a cache-busting toggle beyond using remote builders and cleaning the project. They also don’t include Argon2-specific steps.
- If you must build on Apple Silicon, Heroku required explicit linux/amd64 with buildx; similar flags might help, but we don’t have Fly-specific instructions in the sources to cite for that approach (Heroku M1 note). If after switching back to remote builds and cleaning you still get the Argon2 musl-x64 module error, please share the generated Dockerfile’s apk dependencies and confirm whether openssl1.1-compat is present, plus the exact Wasp version used to generate the Dockerfile, so we can check if you’re on the fixed template (railway build issue). ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @VerreD0, 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?
@VerreD0 are you using the
wasp deploy command for deploying to Fly? https://wasp.sh/docs/deployment/deployment-methods/cli