How to update an app deployed on the testnet without receiving new canister IDs?

Based on the docs, I have deployed my app on the testnet with:

dfx deploy --network=ic

and I can browse it at https://00000-00000-aaaaa-qaaxq-cai.ic0.app/.

I have then updated my code, tested locally and now I want to update the testnet app. However, when I run the same command as above, I get the following error:

Certificate verification failed.

I noticed that if I delete the canister_ids.json file and retry to run the above command a few times, after a while it succeeds deploying, however, I receive a new canister ID for the frontend canister, resulting in a new URL.

I don’t want to have a new URL every time I want to publish an update on testnet. How do you suggest I proceed?

Thank you for the great work!

3 Likes

I don’t want to have a new URL every time I want to publish an update on testnet.

I think the testnets reserve the right to reset at any point, and any reset is going to result in newly-allocated Canister IDs (and therefore Canister URLs).

Things that would help:

  • Let me choose my preferred Canister ID in my dfx.json (it’s just derrived from a publicKey, right?). On first deploy of canister (e.g. after network reset), use the dfx.json’s suggested publicKey (if not taken) for the Canister ID
  • No more network resets - Required for long-term mainnet anyway
2 Likes

Canister ids are not derived from any public key. Your user id is!

(There was a design in the past where caniser ids could be chosen by the user, but that was dropped, as it made scaling out the platform significantly harder.)

Eventually™, network resets will stop from happening.

Does the mainnet get this kind of reset too?

Thanks for the correction, @nomeata !

OK, so essentially there is no way to achieve fixed IDs on testnet yet.

Thank you for your replies!

I look forward to having the possibility of having staging and feature-branch environments to help with the development workflow!

1 Like