Is your feature request related to a problem? Please describe.
Following discussion in #3458 (comment) which introduced local dev/prod docker container image building and docker compose, it would be great to also host/publish the built docker container image (to ghcr.io or docker-hub).
Describe the solution you'd like
Publishing this container-image, it would let people publish/deploy the demo-app via a simple docker-compose yaml, similar to the one of the linked PR, but without the need to clone the repo, or use the build/context flags and entries.
A comment by @igorDykhta
The main thing to figure out is how to handle tokens (like MapboxAccessToken) Right now they're baked in at build time, so we'd need to switch to runtime injection for a published image to be useful. Feel free to open an issue to track this.
These could probably either be passed:
- either as
container environment (variables or file), good if there are not too many variables to setup
- or stored in a config (json, yaml etc) file that would be passed via
volume to the container. This second option is often used for self-hosted stacks, and in addition to storing keys, could also let people configure eg the modules to use (AI assistant, duckdb etc), eventually pass custom kepler.gl-data sample datasets, or owerwrite some assets of the demo-app (logo/favicon etc)
Describe alternatives you've considered
Don't publish the container images and let people build themselves
Additional context
See related discussion: #2836 and closed thread #2024.
Is your feature request related to a problem? Please describe.
Following discussion in #3458 (comment) which introduced local dev/prod docker container image building and
docker compose, it would be great to also host/publish the built docker container image (to ghcr.io or docker-hub).Describe the solution you'd like
Publishing this container-image, it would let people publish/deploy the demo-app via a simple docker-compose yaml, similar to the one of the linked PR, but without the need to clone the repo, or use the build/context flags and entries.
A comment by @igorDykhta
These could probably either be passed:
container environment(variables or file), good if there are not too many variables to setupvolumeto the container. This second option is often used for self-hosted stacks, and in addition to storing keys, could also let people configure eg the modules to use (AI assistant, duckdb etc), eventually pass custom kepler.gl-data sample datasets, or owerwrite some assets of the demo-app (logo/favicon etc)Describe alternatives you've considered
Don't publish the container images and let people build themselves
Additional context
See related discussion: #2836 and closed thread #2024.