All-Hands-AI
Improve docker file to reduce data transfer on project update
What problem or use case are you trying to solve? Reduce the amount of data that is transferred when a new version is released by doing docker pull.
Describe the UX of the solution you'd like Optimising the dockerfile to have the docker layers that are updated to come later in the docker build process so the developers only need to pull the last layers.
Do you have thoughts on the technical implementation?
Describe alternatives you've considered
Additional context
If you find this feature request or enhancement useful, make sure to add a š to the issue
This was done at some point but not sure if it was fully optimized. Thanks for the suggestion.
Hmmm I don't see any commits related to that recently. Do you get long docker pulls and builds when you run in Development Workflow? Because yeah that for sure is a known issue but we've looked at it and it's not that straight forward.
Or are you running into this just with the regular docker command to run README?
Now its great, new version pull with max 100mb for me.
docker pull docker.all-hands.dev/all-hands-ai/runtime:main-nikolaik
docker compose pull
services:
openhands:
image: docker.all-hands.dev/all-hands-ai/openhands:main
stdin_open: true
tty: true
pull_policy: always
environment:
- SANDBOX_RUNTIME_CONTAINER_IMAGE
- LOG_ALL_EVENTS=true
- SANDBOX_USER_ID
- WORKSPACE_MOUNT_PATH=$WORKSPACE_BASE
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- $OPENHANDS_STATE:/.openhands-state
- $WORKSPACE_BASE:/opt/workspace_base:rw
ports:
- "3963:3000"
extra_hosts:
- "host.docker.internal:host-gateway"
networks:
default:
external: true
name: $NETWORK_NAME
altho now its back to downloading everything so it probably depends on how much was updated when a new docker image is built. i think there is still some optimising required.
@raymyers you didn't do anything on your recent improvements of build time right?
@mamoodi, Good question. No I don't believe there was a change to how the layering should work with caching. However, in the short term there were several changes that could have invalidated the cache. So maybe what you're seeing is not a rebuild on every change to main, but more than usual happening at that time? Updates to the base image can also affect this.
We should expect those 1gb+ plus downloads to be uncommon, not on every change. I wonder if there's a good way to monitor this.
Here is recent history of the file that most affects this behavior, openhands/runtime/utils/runtime_templates/Dockerfile.j2
https://github.com/All-Hands-AI/OpenHands/commits/main/openhands/runtime/utils/runtime_templates/Dockerfile.j2
This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.
This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.
Yeah sure! On Aug 3, 2025 at 07:45 +0200, Aravindan M @.***>, wrote:
aravindan888 left a comment (All-Hands-AI/OpenHands#7664) hey @cwirz , can I work on this issue? ā Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
@cwirz Iām working on optimizing the Dockerfile. Do you have any previous data on how long the build took or the size of the image?
Not really. The pull of the docker image was often the whole image for a new version even though not much changed. Also for the runtime image. On Aug 3, 2025 at 19:47 +0200, Aravindan M @.***>, wrote:
aravindan888 left a comment (All-Hands-AI/OpenHands#7664) @cwirz Iām working on optimizing the Dockerfile. Do you have any previous data on how long the build took or the size of the image? ā Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
@cwirz I went through and cleaned up the Docker setup, added multi-stage builds, a proper .dockerignore, and made sure not copying anything unnecessary. Even after all that, the final image size is still about 1.89 GB. I think the bulk is coming from the base image and some heavy dependencies. Might need to explore a lighter base or split things up if we want to reduce it further
@aravindan888 yeah i think that size ok. the main issue is that when files change (new features etc) it rebuilt way to many layers. we should make sure that the files that are actually changing as are late copied into the docker image as possible so the users that pull new images only need to pull the very small last layers. did you check this scenario?
@cwirz yes, I looked into that. I reordered the Dockerfile so the files that change most often like entrypoint.sh, source code, and the frontend build are copied late as possible. That way, when you push new features, only the last few layers are rebuilt and pulled. The earlier (heavier) layers like dependencies, base installs, etc., are cached. So even though the final image size is around ~1.8GB, the layer should now be minimal
to solve this issue @cwirz my pr :10114 needs your review approval for codereview
@aravindan888 sorry i think i cant review this since i dont have write access to the repo. I looked at the changes and it looked ok to me.
This issue is stale because it has been open for 40 days with no activity. Remove the stale label or leave a comment, otherwise it will be closed in 10 days.
This issue was automatically closed due to 50 days of inactivity. We do this to help keep the issues somewhat manageable and focus on active issues.