Orphaned Docker Layers in CLI with docker-compose #309

Closed
opened 2026-02-20 17:36:01 -05:00 by yindo · 3 comments
Owner

Originally created by @davies-a on GitHub (Nov 11, 2024).

Originally assigned to: @dqbd on GitHub.

Checked other resources

  • I added a very descriptive title to this issue.
  • I searched the LangGraph/LangChain documentation with the integrated search.
  • I used the GitHub search to find a similar question and didn't find it.
  • I am sure that this is a bug in LangGraph/LangChain rather than my code.
  • I am sure this is better as an issue rather than a GitHub discussion, since this is a LangGraph bug and not a design question.

Example Code

# langgraph.json
{
  "docker_compose_file": "configs/default.docker-compose.yml",
  "graphs": {
    "chat_response": "./app/graphs/chat_response.py:graph",
  },
  "env": ".env",
  "python_version": "3.12",
  "dependencies": ["."]
}

Error Message and Stack Trace (if applicable)

No response

Description

Hey, Apologies if you don't consider this a bug, it's in that grey area where devex performance issues cause degredation that could be considered either. But sorry if this is in the wrong place!

We're encountering an issue when using langgraph up --watch with the above langgraph.json.

Essentially the compiled dockerfile lines produced by the CLI in this region create an uncacheable layer in faux_pkgs_str, meaning that the subsequent pip installs can't use the docker build cache. That then means that if you are repetitively saving, you can easily balloon the HD space usage dramatically. I've had quite a few instances where it's exhausted the 50GB volume assigned to my docker VM and the postgres sidecar no longer inserts records. I ended up tearing down regularly and using docker builder prune about once a day on my development machine, meaning we lost traces etc.

In our instance, we've resorted to creating a static pyproject.toml file and a static docker-compose.yml using what the CLI creates; however this is a potential maintenance headache long-term.

It appears that the package name isn't used for anything outside the install and is the only dynamic content; as such I'd suggest swapping to a static pyproject.toml file that can be added to the container, so that docker can cache it.

Very happy to open a PR if it would help, but wanted to make the observation/issue report first to gather your thoughts!

System Info

❯ python -m langchain_core.sys_info

System Information

OS: Darwin
OS Version: Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:30 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6030
Python Version: 3.12.3 (v3.12.3:f6650f9ad7, Apr 9 2024, 08:18:47) [Clang 13.0.0 (clang-1300.0.29.30)]

Package Information

langchain_core: 0.3.8
langchain: 0.3.1
langchain_community: 0.3.1
langsmith: 0.1.130
langchain_anthropic: 0.2.1
langchain_aws: 0.2.1
langchain_groq: 0.2.0
langchain_openai: 0.2.1
langchain_text_splitters: 0.3.0
langgraph: 0.2.34

Optional packages not installed

langserve

Other Dependencies

aiohttp: 3.10.8
anthropic: 0.34.2
async-timeout: Installed. No version info available.
boto3: 1.35.32
dataclasses-json: 0.6.7
defusedxml: 0.7.1
groq: 0.11.0
httpx: 0.27.2
jsonpatch: 1.33
langgraph-checkpoint: 2.0.0
numpy: 1.26.4
openai: 1.51.0
orjson: 3.10.7
packaging: 24.1
pydantic: 2.9.2
pydantic-settings: 2.5.2
PyYAML: 6.0.2
requests: 2.32.3
requests-toolbelt: 1.0.0
SQLAlchemy: 2.0.35
tenacity: 8.5.0
tiktoken: 0.7.0
typing-extensions: 4.12.2

Originally created by @davies-a on GitHub (Nov 11, 2024). Originally assigned to: @dqbd on GitHub. ### Checked other resources - [X] I added a very descriptive title to this issue. - [X] I searched the [LangGraph](https://langchain-ai.github.io/langgraph/)/LangChain documentation with the integrated search. - [X] I used the GitHub search to find a similar question and didn't find it. - [X] I am sure that this is a bug in LangGraph/LangChain rather than my code. - [X] I am sure this is better as an issue [rather than a GitHub discussion](https://github.com/langchain-ai/langgraph/discussions/new/choose), since this is a LangGraph bug and not a design question. ### Example Code ```python # langgraph.json { "docker_compose_file": "configs/default.docker-compose.yml", "graphs": { "chat_response": "./app/graphs/chat_response.py:graph", }, "env": ".env", "python_version": "3.12", "dependencies": ["."] } ``` ### Error Message and Stack Trace (if applicable) _No response_ ### Description Hey, Apologies if you don't consider this a bug, it's in that grey area where devex performance issues cause degredation that could be considered either. But sorry if this is in the wrong place! We're encountering an issue when using `langgraph up --watch` with the above `langgraph.json`. Essentially the compiled dockerfile lines produced by the CLI in [this region](https://github.com/langchain-ai/langgraph/blob/main/libs/cli/langgraph_cli/config.py#L214-L286) create an uncacheable layer in `faux_pkgs_str`, meaning that the subsequent `pip install`s can't use the docker build cache. That then means that if you are repetitively saving, you can easily balloon the HD space usage dramatically. I've had quite a few instances where it's exhausted the 50GB volume assigned to my docker VM and the postgres sidecar no longer inserts records. I ended up tearing down regularly and using `docker builder prune` about once a day on my development machine, meaning we lost traces etc. In our instance, we've resorted to creating a static `pyproject.toml` file and a static `docker-compose.yml` using what the CLI creates; however this is a potential maintenance headache long-term. It appears that the package name isn't used for anything outside the install and is the only dynamic content; as such I'd suggest swapping to a static `pyproject.toml` file that can be added to the container, so that docker can cache it. Very happy to open a PR if it would help, but wanted to make the observation/issue report first to gather your thoughts! ### System Info ❯ python -m langchain_core.sys_info System Information ------------------ > OS: Darwin > OS Version: Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:30 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6030 > Python Version: 3.12.3 (v3.12.3:f6650f9ad7, Apr 9 2024, 08:18:47) [Clang 13.0.0 (clang-1300.0.29.30)] Package Information ------------------- > langchain_core: 0.3.8 > langchain: 0.3.1 > langchain_community: 0.3.1 > langsmith: 0.1.130 > langchain_anthropic: 0.2.1 > langchain_aws: 0.2.1 > langchain_groq: 0.2.0 > langchain_openai: 0.2.1 > langchain_text_splitters: 0.3.0 > langgraph: 0.2.34 Optional packages not installed ------------------------------- > langserve Other Dependencies ------------------ > aiohttp: 3.10.8 > anthropic: 0.34.2 > async-timeout: Installed. No version info available. > boto3: 1.35.32 > dataclasses-json: 0.6.7 > defusedxml: 0.7.1 > groq: 0.11.0 > httpx: 0.27.2 > jsonpatch: 1.33 > langgraph-checkpoint: 2.0.0 > numpy: 1.26.4 > openai: 1.51.0 > orjson: 3.10.7 > packaging: 24.1 > pydantic: 2.9.2 > pydantic-settings: 2.5.2 > PyYAML: 6.0.2 > requests: 2.32.3 > requests-toolbelt: 1.0.0 > SQLAlchemy: 2.0.35 > tenacity: 8.5.0 > tiktoken: 0.7.0 > typing-extensions: 4.12.2
yindo added the question label 2026-02-20 17:36:01 -05:00
yindo closed this issue 2026-02-20 17:36:01 -05:00
Author
Owner

@vbarda commented on GitHub (Jan 14, 2025):

@davies-a are you still running into this issue?

@vbarda commented on GitHub (Jan 14, 2025): @davies-a are you still running into this issue?
Author
Owner

@davies-a commented on GitHub (Jan 15, 2025):

@davies-a are you still running into this issue?

Hi @vbarda - thanks for responding.

To be honest, I gave up and started using a custom docker-compose file with a different layer order and so I've not continued to use the CLI 'in anger' because I was just using docker-compose directly. That said, I've just tried running langgraph up, ctrl+C, making some file changes, and re-running it, and it seems to rebuild much more quickly now (albeit running with --watch wasn't triggering a rebuild on file changes within the directory).

As such, it seems like this issue may be worth closing as I can't replicate the issue any further? Especially as I'm not actively working on this I'm not sure I could give helpful input on what causes/affects it.

Sorry I can't be of more help!

@davies-a commented on GitHub (Jan 15, 2025): > [@davies-a](https://github.com/davies-a) are you still running into this issue? Hi @vbarda - thanks for responding. To be honest, I gave up and started using a custom docker-compose file with a different layer order and so I've not continued to use the CLI 'in anger' because I was just using docker-compose directly. That said, I've just tried running `langgraph up`, ctrl+C, making some file changes, and re-running it, and it seems to rebuild much more quickly now (albeit running with `--watch` wasn't triggering a rebuild on file changes within the directory). As such, it seems like this issue may be worth closing as I can't replicate the issue any further? Especially as I'm not actively working on this I'm not sure I could give helpful input on what causes/affects it. Sorry I can't be of more help!
Author
Owner

@vbarda commented on GitHub (Jan 15, 2025):

@davies-a Got it, appreciate your patience and glad you were able to find a different solution! Will close this for now.

Also, check out langgraph dev for running a local development server -- it is meant to be more lightweight and avoids docker altogether (although might not be what you need) https://langchain-ai.github.io/langgraph/tutorials/langgraph-platform/local-server/

@vbarda commented on GitHub (Jan 15, 2025): @davies-a Got it, appreciate your patience and glad you were able to find a different solution! Will close this for now. Also, check out `langgraph dev` for running a local development server -- it is meant to be more lightweight and avoids docker altogether (although might not be what you need) https://langchain-ai.github.io/langgraph/tutorials/langgraph-platform/local-server/
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langchain-ai/langgraph#309