Docker

Memory limits

trile comes with the above resources limits set, preventing from eating machine resources beyond reasonale.
These limits were established balancing the need for trile to operate without throttling whilst leaving sufficient hardware resources for other host processes as well.
More in detail: backend and specially ipfs instances, are expected to grow beyond reasonable over time due to their internal memory models.
By setting these limits, the components become more context aware and adapt accordignly.

Lowering might be your best bet when running a federation member instance on pretty resource-constrained machines like Raspberry PIs.
Increasing will likely be the way to go if you are running a busy federation controller.

Why using docker commands for adding files to IPFS?

In IPFS files are, by default, added to IPFS internal storage and the local files are not required.
There is an option (--nocopy) that enables using local files directly and avoids using IPFS internal storage.
This option is key in trile since it allows users to manage their files transparently and at the same time prevents data duplication when files are shared by multiple members of the federation.

However, this option --nocopy comes with 1 drawback. Although it can be used in the IPFS' API, it requires sending the binary over the network.
Considering how the federation member backend & IPFS mount the same sharing folder, sending such binaries over network it's highly inefficient.

The compromise solution in this case is making the backend perform a ipfs add command though a docker exec.
Slightly complex setup at the gain of a performant behavior.