@AntekMnm Just a quick follow-up to my previous reply! I realized my manual Python script approach for swapping IDs between staging and production is actually outdated now. Someone more up-to-date with the new icp-cli could probably give you a deeper technical dive, but I wanted to make sure you’re aware of the new native way to handle this.
The new icp-cli tool completely changes the game for staging deployments by decoupling the physical network from your logical setup:
-
Network (The physical layer): Where the code actually runs. This can be
local(your PC), a Docker node, oric(the real mainnet). -
Environment (The logical layer): A grouping of canisters and settings. You can create custom environments like
prodandstaging.
Inside the new icp.yaml configuration file, you can explicitly tell icp-cli that both your staging and prod environments should be published to the ic network (the real mainnet).
This natively solves the exact problem I was patching with my custom script:
-
No more hard-coded IDs: The CLI dynamically manages Canister IDs per environment and injects them at runtime (e.g., via
ic_envcookies for the frontend). You don’t have to find-and-replace anything. -
Environment-specific variables: You can define different initialization arguments or settings for your staging environment versus production directly in the YAML file.
-
Build once, deploy many: You compile the
.wasmonce, deploy it to your mainnetstagingenvironment for live testing, and if it passes, you use that exact same verified hash for theproddeployment.
I highly recommend looking into this rather than my old dfx workaround.
You can find all the details and ask the devs directly in the icp-cli announcements and feedback discussion. PocketIC still remains valid regardless.