Currently ICP canister has 8 GB limit for stable memory and 4 GB heap limit. Since our audit and verification canister keep growing, there is a possibility of exceeding these limits. We created a static principal controller and managed per day sub canisters using that. Those sub canisters are owned by the principal canister. The issue is we cannot upgrade the sub canisters owned by the principal canister with a new change (fields to the data model). We found 3 ways to overcome it: Remove static principal controller, create multiple canisters for each day, and manage the mapping from our side database Cons - we need to manage all the canisters manually Maintain versioning at the principal container for each sub canisters, and without upgrading old sub canisters use updated smart contract only for newly create sub-canisters Cons - No backward compatibility Create a new instance of the new sub-canister and write a function to get a copy of data from the previous canister and copy that data to the newly create-canister Cons - High data transfers and processing on ICP, will increase the ICP cost Any ideas and thoughts how to ensure future scalability in the most efficient way? Is there any other way?

The Internet Computer Interface Specification :: Internet Computer Internet Computer | Documentation install_code : (record { mode : variant {install; reinstall; upgrade}; got the response from discord someone asked, but didn’t try it.

@bytesun is correct. Your principal canister actually can upgrade the sub canisters by sending messages to the IC management canister. You’ll first want to make sure the canister is stopped (using stop_canister and canister_status), and then do the upgrade with install_code.

@bytesun @abk thank you very much. stop_canister and canister_status work fine with the IC management canister. But in the install_code method, we have to include wasm_module (web assembly file I guess) as a parameter. Do you know how to attach that file to a Motoko canister as wasm_module? Thank you again for your help.

Yes the wasm_module argument is a blob containing the wasm code you want to install on the canister. Since you’re doing the upgrade from your controlling canister, it will need to get that wasm code somehow. So you’ll have to have some method on your controlling canister that lets you upload wasm code. Does that make sense?

I’m guessing you’ll have to serialize the compiled wasm module into a candid blob (perhaps using agent-rs?) that you’ll then need to pass as an argument when calling that “upload” method on your controlling canister. Probably need your own bash script for this…

I think this might help. [image] OpenChat: A Truly Decentralized Alternative to WhatsApp Developers We run a Rust program to install / upgrade canisters. Good timing though… we’ve just this second made the OpenStorage repo public! This is the system we use to store files sent in OpenChat and we install / upgrade canisters using essentially the same technique here as in OpenChat. See here - open-storage/utils.rs at main · open-ic/open-storage · GitHub

@abk @jzxchiang @paulyoung thank you for your help and suggestions, very much appreciated.

Exceeding ICP Canister Storage Limits

Developers Programs & Applications

paulyoung January 31, 2022, 10:06pm 7

I think this might help.

Topic		Replies	Views
How does the upgrading of canister works Developers Discussing	18	660	July 13, 2023
Getting Started with IC Development: What considerations should developers take into account when developing a canister locally and deploying it to the IC Mainnet Developers Discussing	4	160	June 18, 2025
How do I upgrade child canisters that were dynamically created from a parent canister of which I am the controlller (In Motoko)? Developers	33	2538	November 16, 2022
Pocket IC CanisterInstallCodeRateLimited Developers	4	283	May 29, 2025
Upgrade multiple canister at the same time Language Support Motoko	6	459	June 1, 2023

Exceeding ICP Canister Storage Limits

Related topics