A problem is, it seeds only the first time. That is might not what you expect.
EDIT: A workaround,
incus-compose upincus-compose down --no-deps <service>, incus-compose incus storage volume rm default vol-seed-XXXXX, incus-compose upCan you run a standalone javascript file on your OS?
I would write one that seeds your volume on demand with optional restart.
I thought again about this, Iâll implement this feature differently than docker.
incus-compose watch --restart service1 --restart service2
This will watch all seeded bind files/directories upload and restart service1/service2 on demand, other services will get updates as well but wont be restarted.
What do you think @tort ?
good to know I gave you food for thought
i think the cli option route is good but the power of compose comes from the life cycle being explicit in yaml thatâs why the watch in yaml is a good idea. for ex right now I am trying to send traefik/caddy routes as files. I will do this often so having it in yaml is useful. I expect it to push and erase the old file (sync) on every compose up and for it to ne picked up by traefik without having to stop the container.
what do you think?
Thanks, yes you gave me thinking food 
up will sync on each run with Implement a `watch` command · Issue #73 · lxc/incus-compose · GitHub
The watch command is for developers than run something like devcontainers.
Iâm working with the Maintainer / Developer of dnsweaver for first class incus and incus-compose support.
The goal is to have a proxy like caddy/traefik, dnsweaver and incus work together - you start a compose project - you have a service online.
I think a lot people will have fun with such a solution.
Well dnsweaver is not rely needed for compose hosting but its a nice to have.
Or you can use buildah, which I believe is what underlies podman build.
I thought about this as well, buildah is heavy dependency and maybe hard to maintain while installing podman is easy and doesnât conflict with anything.
What do you think?
Btw. on a fresh trixie container I have to do this to make podman work:
mkdir -p ~/.config/containers/
echo -e '[engine]\ncgroup_manager = "cgroupfs"' > ~/.config/containers/containers.conf
loginctl enable-linger runner
# reboot the container
I guessed that installing buildah would be a less heavy dependency than podman, since it does fewer things.
But I suppose theyâre both going to require some sort of container runtime for any RUN statements in the Dockerfile. AFAICS buildah depends on runc, but podman depends on runc too.
I donât know why buildah would be any harder to install or have more potential conflicts than podman - as far as I can see itâs packaged conveniently.
If someone wants to write an incus-build they could do that Probably by borrowing code from buildah, which is what podman-build did.
I think we are talking about 2 different things - having buildah as a library part of of incus-compose or as an external dependency.
For the second, that is maybe simple - just switch the binary name in code and go.
Iâll think about this.
This is what I do internally for anyone looking into building a standalone solution:
nitpicking here idk your stance on keeping close to the compose spec but in theory watch anchors only activate on compose up âwatch
I also noticed that incus-compose up acts like an implicit -d option instead being a foreground process that destroys the stack on CTRL+c
I wish incus-compose to be a drop-in for docker compose, so yes your arguments arenât ânitpickingâ.
Based on your feedback @tort Iâm gonna close the issue and implement up --watch, thank you.
As Iâm not using incus-compose up as a service and I always disliked the -d I didnât implement the no-detach default yet.
In scripts please always use incus-compose up --detach the no-detach default will follow.