Add Dockerfile and docker compose files specifically for a development by TomK32 · Pull Request #207 · xemle/home-gallery

TomK32 · 2025-11-21T06:52:38Z

Give it a try and I'll update the docs once this is merged.

I'd recommend that you first get nginx-proxy working, I use it both on my dev machine, homelab and staging servers.

export COMPOSE_FILE="docker-compose-development.yml:docker-compose-development.nginx-proxy.yml"                                                                                                               
export HOME_GALLERY_HOST=dev.home-gallery.example.com                                                                                                                                                         
docker compose build && docker compose up

(obviously change the HOST)

…t environment

xemle · 2025-11-22T22:22:39Z

Hi @TomK32

Thank you for your PR

I can see your motivation to move the development into docker containers.

My question is:

What is the purpose of using nginx here? Are you using is to provide local domain names instead of anonymous localhost + port access?
How does your PR simplify your development on HomeGallery?

Which IDE are you using for development so that this setup helps you to get things done?

Why I am asking: For this project I am using Visual Studio Code. To run only the setup in containers does not help me to setup the full environment with the IDE. I've heard that dev containers should be awesome and gives so also control for your (recommended and used) IDE extensions.

So I imagine a dev setup completely in containers including the IDE. The only external thing I would leave at the host system would be the git handling (because I do not know how to move this into the container as well. Well I would know but never thought about all the details...)

And since you seem to be good dev I want to challenge this PR if you like.

So what about having additional https://docs.linuxserver.io/images/docker-code-server as compose service so that the user can code directly in the browser without installing an IDE? So the user has just to checkout this repo and run one docker compose command and can code right away without any dependency except git and docker compose? And since VS Code has great support for dev containser I do not know if it would helpful to span the dev setup by a dev container definition instead of a bunch of docker compose files? (well, dev containers might use docker compose, too but I have the feeling that it comes with some sugar and spices around docker compose). And with dev container the user can decide to use his favorite IDE or the vscode in the browser...

xemle · 2025-11-22T22:25:07Z

Dockerfile-development

+
+EXPOSE 3000 5173
+
+CMD npm install --verbose && npm run build && node gallery.js run server


install and build is run on every start.

I recommend to move it to a RUN step so that the user can just build the image and then start the development when starting the container. Otherwise the container startup time will long at the first start and laggy on sequential starts.

With CMD it is a one-step startup and years ago I was prone to forget the docker compose build step...
Removing node_modules from the .dockerignore will speed up sequential starts but... why restart the container in the first place? I have angular dev containers running without restarts for weeks and months. I see the webapp doing a fast recompile when I make small changes, gallery and api-server surely do the same?

I have angular dev containers running without restarts for weeks and months

HomeGallery lacks of such setup. Currently it is more hand crafted and there is not a hot reloading mechanism for the server. So there is a big gap between frontend code and backend code. Also JS/TS, code style and documentation varies between the sub packages.

I see the webapp doing a fast recompile when I make small changes

This works since the recent change to the awesome vite.

gallery and api-server surely do the same?

Unfortunatly not.

why restart the container in the first place?

Depends for the audience.

For me as maintainer I work on my bare metal on the sources. No need for containerizing the dev environment.

The community is quite small and I think the experience should be as smooth as possible. I expect more that people try it on a daily basis. While it is safer to install and build the things on the container start, I have the impression it will slow down sequential starts.

Anyway, the containerizing the dev environment is a huge win and if we do not share where to run npm install and npm build it is a lower prio.

gallery and api-server surely do the same?

Unfortunatly not.

Isn't nodemon the way to go for that? I gave it a try last week and while I'm not done yet with other changes, it does work as intended.

xemle · 2025-11-22T22:27:06Z

docker-compose-development.nginx-proxy.yml

+  webapp:
+    environment:
+      VIRTUAL_HOST: '${HOME_GALLERY_HOST:-home-gallery.localhost}'
+      VIRTUAL_PORT: 5173


vite.config.ts in packages/webapp has hardcoded proxy route to the server on local host. This hard coded route can be improved by a environment variable with fallback to localhost.

So maybe this nginx proxy rule becomes obsolete?

An env variable in vite.config.ts would be sweet and might indeed make some nginx proxy wizard obsolete.

nginx-proxy gets the requests to /api and /files before the webapp does so I added the VIRTUAL_HOST_MULTIPORTS rules above to point them to the correct container directly instead of having them go through the webapp/vite. What web servers are others using besides nginx? Or do you run it without one?

I've added GALLERY_SERVER_URL env for the webapp package which can be used.

IMHO the GALLERY_SERVER_URL env with build in http proxy via vite is better than an extra nginx container.

Can you update your compose accordingly?

xemle · 2025-11-22T22:28:31Z

packages/api-server/Dockerfile-development

+
+EXPOSE 3000
+
+CMD sh -c 'npm install && node download-models.js && node index.js'


Also here: npm install and node download-models.js should be moved to a RUN step to improve container startup time.

Currently the dev container of api-server has no difference to the docker image of production. So I think we can skip this for the beginning.

TomK32 · 2025-11-22T23:44:11Z

@xemle I use vim, running on the host. If you find that having whatever extra plugins your use for VSCode to be useful, add another docker-compose file or even a Dockerfile if that's the only way to add more plugins, why not? But I'd never force that on anyone else. Starting it all with three files in COMPOSE_FILE will work, let me know if you run into problems.

You can run git in a container as well, but it's getting a bit silly once you want to respect the user/group ownership:

docker run --user $(id -u):$(id -g) -ti --rm -v ${HOME}:${HOME} -v $(pwd):/git -v /etc/passwd:/etc/passwd -v /etc/group:/etc/group alpine/git clone git@github.com:xemle/home-gallery.git
see https://hub.docker.com/r/alpine/git#optional-usage-3

xemle · 2025-11-24T19:52:26Z

Dockerfile-development

+
+WORKDIR /app
+
+ENV HOME=/data


Why providing the env vars not in the compose files? It would be more flexible in a dev environment which is not baked into the image

xemle · 2025-11-24T20:05:47Z

Could you

Rename Dockerfile-development to Dockerfile-dev
Drop docker-compose-development.nginx-proxy.yml in favor of GALLERY_SERVER_URL
Rename docker-compose-development.yml to compose-dev.yml
Rename gallery.config-development.yml to gallery.config-dev.yml
Update the references in files of the renames

Add Dockerfile and docker compose files specifically for a developmen…

9937e0c

…t environment

xemle reviewed Nov 22, 2025

View reviewed changes

xemle reviewed Nov 24, 2025

View reviewed changes


		EXPOSE 3000 5173

		CMD npm install --verbose && npm run build && node gallery.js run server


		EXPOSE 3000

		CMD sh -c 'npm install && node download-models.js && node index.js'


		WORKDIR /app

		ENV HOME=/data

Conversation

TomK32 commented Nov 21, 2025

Uh oh!

xemle commented Nov 22, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TomK32 commented Nov 22, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xemle commented Nov 24, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants