What is the best way to store image resource for ur dapp?

In case to build a custom dapp, we may need to upload lot of resources like images, gifs, videos, etc.

what is the best way to manage it for a business scale useage?


Upload them on IPFS, and then save the CID in canister.

1 Like

@Hazel has something that works directly on the IC: https://xe5ii-jiaaa-aaaaf-qaaya-cai.raw.ic0.app/


To clarify; I’m not suggesting you depend on that, I just wanted to demonstrate that it’s possible.

This imo presents a solid use case for badlands - as computational and storage costs will be relatively more affordable it could be used to host data like images etc. Using a hashing method in JS this could be setup to ensure images being server are correct. Utilise the IC for more secure computation (token logic, immutable data storage etc) and badlands for images, files and non-important data.


According the maturity of your development, BigMap could be an option see also CanCan application.

This is a nice one~! :grinning: :grinning: :grinning:

To follow up on this, is the recommended approach of storing dynamic, user-generated images to use the asset canister or to roll out your own chunking + canister storage solution à la CanCan?

One great thing about the asset canister is apparently it isn’t restrained by the 2 MB message limit that regular canister calls are limited by.

But is it possible to upload assets to the asset canister during runtime?

It is restrained by the 2mb limit, but we abstract it by using chunking. You can make calls to it using an agent; I’ve done some early experiments in the browser and found it pretty simple

1 Like

Hmm, if it’s restrained by the 2 MB limit, then doesn’t the chunking need to be done client-side? How does the asset canister’s chunking help in that case?

The canister knows how to receive chunked assets and assemble them in the canister, so it’s just a matter of managing it in the frontend.

Not a high priority for me, but if I get time down the road I’ll create a npm package to make it easier


Sorry, I’m not quite sure I understand. When you say that the 2MB limit was removed, was that only if you used DFX to upload assets to an asset canister? If I’m uploading assets dynamically at runtime, then I would need to implement chunking myself, right?

By the way, is the 2MB limit only for requests or also for responses? I’m hoping it’s fine to fetch an asset (from the asset canister) that is larger than 2MB.

It is for responses as well(also inter canister calls). There is the http streaming api if you can figure it out.

1 Like

Gotcha, that’s what I figured.

I wrote up what I found looking into the different solutions for storing/serving large assets. Seems like implementing my own http_request canister with streaming enabled (similar but not identical to the asset canister) is the way to go.

1 Like

You’re also welcome to implement streaming on the main asset canister, now that it’s open source!

1 Like

I think it already supports streaming out of the box?

have a look at this example… GitHub - pattad/imgTank