Dfx deploy locally with a new Dfx identity

Hello, i am new in IC Network, and i want to understand why I am not able to deploy locally a project if I set a new Internet Identity with Dfx identity new cmd with passphrase encryption. When I test to deploy the simple hello dapp I can deploy only if i use the default Dfx identity with no encryption or if i create one with --disable-encryption option, otherwise i am stuck at the dfx build phase like this :

$ dfx deploy
Please enter the passphrase for your identity: [hidden]
Decryption complete.
Creating a wallet canister on the local network.
The wallet canister on the “local” network for user “ic_yangshuei” is “rkp4c-7iaaa-aaaaa-aaaca-cai”
Deploying all canisters.
Creating canisters…
Creating canister hello_backend…
hello_backend canister created with canister id: rno2w-sqaaa-aaaaa-aaacq-cai
Creating canister hello_frontend…
hello_frontend canister created with canister id: renrk-eyaaa-aaaaa-aaada-cai
Building canisters…
Shrink WASM module size.
Building frontend…

No error message either so I wasn’t able to figure it out where is the issue.

1 Like

The build step does not access your identity in any way, so would guess that the problem lies somewhere else. Since the frontend build hangs: Is there a chance you have a problem with node/npm? We generally recommend that you use Node version 16.

yea it’s really strange, I am using already Node 16, I try again with dfx start --clean to clean up and redeploy I still got the same issue and stuck at the building phase, however if I try to redeploy with a new identity without encryption it work fine.

I looked at the code once more, and there’s really no way for the identity to influence anything once Creating a wallet appears. Can you try nuking everything generated in the project?

dfx stop
rm -r .dfx
rm -r node_modules
# if Rust:
rm -r target

If this doesn’t work, my next attempt would be to try with a different version of dfx (or reinstalling).

well after nuking everthing, I even uninstall and reinstall a clean version of dfx (0.12.0) with the cmd line in the doc it still doesn’t work, I also think the issue is somewhere else.

Does your ‘everything’ include node as well? That would be my next try if you haven’t done that yet

if you mean the cmd line rm -r node_modules as you mention to remove node module directory yea it’s already done.

I meant brew remove node && brew install node or apt remove node && apt install node

Oh sry, yea I already reinstall node, I even try node 18 and 19 but still the same issue… but it’s not really a big deal for now as I can still work with it and play around, it’s just a weird issue that’s why I am asking, and sry for taking your time >.>

1 Like

Hi! I also have the same problem. What I did is to really stick with the “default” identity. If you have problems while deploying the canister. I suggest to use “dfx canister update-settings” to add a default controller (–add-controller ) then set it to the default controller (–set-controller ). Make sure to use the “–all” arguments so you don’t repeat yourself. Try deploying it again it should work.


  1. dfx canister update-settings --add-controller --all
  2. dfx canister update-settings --set-controller --all

Hope this helps!


I’m having the same issue. However, I had already used different identities before and never encountered this issue. Now, after having created a new identity, building the frontend canister stops without an error message. Deleting .dfx and node_modules didn’t help either. Any solution to this other than using the default identity?

@dindog18, @karim, does this also happen to you if you use the default dfx new project? Or is it something bigger? I can’t reproduce this on my machine, so any information would be very helpful

I just double-checked and tried deploying a new default project. Same issue here, but again only on mainnet. dfx deploy on the local replica does work. dfx version is 0.12.1. If the issue was related to insufficient cycles, would dfx tell me so?

Yes, you would see an error message that talks about cycles. Most likely it would say insufficient cycles.

Just tried the same, and it worked. Can you maybe try dfx deploy with the flag -vv? This would enable debugging output and maybe would include some relevant information.

I did some more testing. The issue arises with newly created identities both when trying to deploy locally and on mainnet, but only in certain projects including new default projects created with dfx new. Apparently, it’s hanging at npm run build. This is a new default project created with dfx new:

[karim@archlvm test]$ dfx deploy -vv
Trace mode enabled. Lots of logs coming up.
Please enter the passphrase for your identity: [hidden]
Decryption complete.
Deploying all canisters.
All canisters have already been created.
Building canisters...
No canister of type 'rust' found. Not trying to run 'cargo audit'.
Building canister 'test_backend'.
Running "/home/karim/.cache/dfinity/versions/0.12.1/moc" "/home/karim/test/src/test_backend/main.mo" "-o" "/home/karim/test/.dfx/local/canisters/test_backend/test_backend.wasm" "-c" "--debug" "--idl" "--stable-types" "--public-metadata" "candid:service" "--actor-idl" "/home/karim/test/.dfx/local/canisters/idl/" "--actor-alias" "test_backend" "rrkah-fqaaa-aaaaa-aaaaq-cai" "--actor-alias" "test_frontend" "ryjl3-tyaaa-aaaaa-aaaba-cai" "--package" "base" "/home/karim/.cache/dfinity/versions/0.12.1/base"...
Shrink WASM module size.
Building canister 'test_frontend'.
Building frontend...
Running "npm" "run" "build"...

I’m getting this warning when creating a new default project:

npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: 'test_frontend@0.1.0',
npm WARN EBADENGINE   required: { node: '^12 || ^14 || ^16 || ^18' },
npm WARN EBADENGINE   current: { node: 'v17.9.1', npm: '8.11.0' }

Running npm run build --progress works however:

[karim@archlvm test]$ npm run build --progress

> test_frontend@0.1.0 prebuild
> npm run generate

> test_frontend@0.1.0 generate
> dfx generate test_backend

Please enter the passphrase for your identity: [hidden]
Decryption complete.
Building canisters before generate for Motoko
Shrink WASM module size.
Generating type declarations for canister test_backend:

> test_frontend@0.1.0 build
> webpack

No production canister_ids.json found. Continuing with local
asset index.js 622 KiB [emitted] (name: index) 1 related asset
asset index.html 689 bytes [emitted]
runtime modules 1.16 KiB 6 modules
modules by path ./node_modules/@dfinity/ 234 KiB 38 modules
modules by path ./node_modules/borc/ 113 KiB
  ./node_modules/borc/src/index.js 647 bytes [built] [code generated]
  + 9 modules
modules by path ./src/ 1.89 KiB
  ./src/test_frontend/src/index.js 547 bytes [built] [code generated]
  + 2 modules
modules by path ./node_modules/simple-cbor/src/*.js 17.5 KiB
  ./node_modules/simple-cbor/src/index.js 595 bytes [built] [code generated]
  + 2 modules
modules by path ./node_modules/iso-url/ 4.36 KiB
  ./node_modules/iso-url/index.js 285 bytes [built] [code generated]
  + 2 modules
+ 7 modules
webpack 5.75.0 compiled successfully in 953 ms

This means that I can avoid the issue by running npm run build and then dfx canister create test_frontend followed by dfx build test_frontend and dfx canister install test_frontend.

I’ve also tried dfx 0.12.0 but the issue persists. Node version is v17.9.1, npm version is 8.11.0. Btw: Does dfx look for a ‘rust’ canister by default when deploying? I’ve never noticed this line before and I don’t use Rust: No canister of type 'rust' found. Not trying to run 'cargo audit'.

1 Like

Thank you very much for the thorough investigation, @karim! Can you maybe try once more with a stable node version? v17 is not stable and we’ve seen best success with v16 and v18.

Not quite. It looks for any canister of type rust, not a canister that is called rust. If it finds one, it will run cargo audit to notify the developer of vulnerable dependencies.

1 Like

I’m having this same issue with node 16 and 18 on my mac and linux machines. But, if I try to run dfx build <canister-name> it hangs as well (frontend only, backend builds fine). However, npm run build runs fine by itself if I manually run it.

It’s really just running npm run build on its own (see source code). Can you maybe try once more with -vv to enable debug output? I feel there has to be something else going on…

I just heard this may be because npm run build tries to access (for some questionable reason) the identity. Can you test if this only happens if you use a non-plaintext identity? (i.e. a keyring or password-protected one)

wow i thought i was the only one with this weird issue but looks like it’s not >.> I also try with a plaintext identity there is still the same issue, and when i run dfx deploy -vv i have more or less the same log as karim, and although getting stuck at the npm run build phase, it looks like the build continues to proceed behind the scene… because when i run npm start after forcing the exit, it work.

1 Like