Could we deploy a canister on a specified subnet?

Could we deploy a canister on a specified subnet?
If we can, when can we deploy a canister on a specified subnet?

This is currently not possible but we recognise that this is a problem. We hope to be able to allow users to deploy canisters to specific subnets in the near future.

1 Like

This would be the opposite of the serverless philosophy. Ideally, I’d want to just deploy to the IC and have it figure out the details. I imagine people want to deploy to specific subnets to subvert the issues plaguing pjljw or the like. While other seemingly empty subnets are available.

1 Like

While not a perfect solution, you can use the dfx ledger create-canister command to create an empty canister (which will be created on a random subnet), check on ic.rocks or the ICA dashboard to see where the canister has been created, and if it was created on a desired subnet, deploy a cycles wallet to that canister using dfx identity --network ic deploy-wallet <canister id>. Once the cycles wallet is deployed, any canisters created from that cycles wallet will be on the same subnet. I’ve done this and it works! More info on the create-canister command here: dfx ledger :: Internet Computer

4 Likes

I consider this a bug (or missing feature): If I create a new canister through a wallet, and the subnet with that wallet is already full, or generally more busy than some other subnet, then I would expect the new canister to be transparently be installed on that subnet (echoing @saikatdas0790’s sentiments). At least “create that canister wherever possible” should be the default, and “create that canister on the same subnet as canister X” or “create this canister on a subnet other than canister X, Y, Z (for load balancing)” or “create this canister on a subnet with at least n nodes” or other subnet indications an optional setting. And I hope we aim for such declarative settings, and not just a blunt and inflexible “create on subnet X”.

1 Like