Why is CONTAINER_PRESERVE_CONFIG false by default? Should be true...

[vlaquest]

Hi,
Thanks so much for this job !!!
It makes it clean and easy to run Foundry VTT :) !!!

I could set it up in minutes, just by configuring the mounted volume, and the FOUNDRY_RELEASE_URL.

Now I'm just suprised I had to care about the CONTAINER_PRESERVE_CONFIG. It is false by default, and each time the container restarts it would reset the admin password and options...

Why is this reset behavior the default use case, I feel like for the average people like me, it is important not to lose the config at every startup.
=> the config is easy resetable by erasing manually those files, they can be easy found because they are typically mounted outside the container.

Cheers
Vincent

[felddy]

Good question.

One of the design goals of this image was to allow setting all of FoundryVTT's options via environment variables or secrets. This allows a container administrator to capture and manage all of the configurations in a single place. For example I use a docker-compose.yml file similar to the example in the repository. If I make a change to this file and restart the container, the configuration changes will be applied to Foundry.

Capturing a container's configuration externally allows multiple containers to work together more easily using calculated values for their configurations. A common use case is a TLS proxy container, and a FoundryVTT container: I have an example under development in the cookbook:

https://github.com/felddy/foundryvtt-docker/tree/improvement/cookbooks/docs/cookbooks/caddy

There are other users of the image that have much more complicated deployments that spin up multiple instances of FoundryVTT using multiple licenses and configurations. If you look through the issues, discussions, and forks you'll see people using AWS Fargate, ECS, and Kubernetes for orchestration.

So I understand why you might want CONTAINER_PRESERVE_CONFIG to be true by default. That said, the expected behavior of Docker containers in general is to be ephemeral, have reasonable defaults, and accept the orchestrator as the authoritative source of configuration where possible.

That said, I think I owe the README a more detail explanation of how the configurations are managed and a warning about configuration changes not persisting from the GUI by default. It might be worthwhile to inject a warning directly into the UI similar to the one that appears in the update tab.

Thanks for your question. I hope I answered it to your satisfaction.

[vlaquest]

Hi, and thanks for the explanation ! :)

I'm suprised to find such complex deployments for the VTT Foundry. Now I understand that some people want to share their data and worlds accross multiple licensed instances and so you need a way to override all what is configurable.

But I thought the most commun use case was to simply run one instance. It is the simplest as well.
I thought maybe the simplest use case could match the defaults, which is to preserve config...

But for more complex scenarios, for advanced needs, more advanced solutions can be employed, namely docker compose files, where overriding the defaults feel natural there.

I just wrote this guide : https://foundryvtt.wiki/en/setup/hosting/Synology (the Docker and HTTPS part)
Non technical people can today launch images and they just need to configure a few "parameters".

Your image is magic because with two single parameters and one volume path, you get your own Foundry VTT running, and for good.
You just need : FOUNDRY_RELEASE_URL, and CONTAINER_PRESERVE_CONFIG.

I agree the doc could emphasize on that.

May I suggest you put this scenario as a first citizen in your doc?
FOUNDRY_RELEASE_URL is great because you don't put your password anywhere (you just have 5 minutes but it's fun)
CONTAINER_PRESERVE_CONFIG (if it still defauls to false ;) ) : because otherwise you loose your settings and admin password.
The volume mapping of /data is already there.

Cheers.