Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-19 22:23:50 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #3736] [question/bug?]: how can anythingllm be set up on non-avx2 cpu? crash on initial onboarding #2404

New Issue
Closed
opened 2026-02-22 18:29:31 -05:00 by yindo · 14 comments
yindo commented 2026-02-22 18:29:31 -05:00
Owner
Copy Link
Copy Source

Originally created by @thejjw on GitHub (Apr 29, 2025).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/3736

How are you running AnythingLLM?

Docker (local)

What happened?

Hello,
I know that the default lancedb have avx2 requirement [#1331] which prevents setup on old pc/server, whether run or docker or not. My server is on non-avx2 cpu so I have been using mintplexlabs/anythingllm:lancedb_revert image.
Today however I wanted to try out new version by connecting it to chroma.
I pulled and ran chromadb/chroma and mintplexlabs/anythingllm:latest image, all using new mount location for fresh setup.
I noticed that I can't actually use chroma since I can't get past first screen for llm preference, which probably fails because it tries to save to lancedb.
I understand lancedb requiring avx2. However the current setup flow prevents users from switching to alternatives especially if you run on non-avx2 cpu.
Please see if the flow can be changed to allow setting db selection before other preference settings, which will hopefully allow users to run it on more hardware.
In the meantime, are there any environment flag or other means I can pass to docker run for me to force anythingllm use chroma or other non-lancedb at runtime? I'd appreciate any help.
Thanks.

Are there known steps to reproduce?

you run current version of anythingllm on this cpu1 this will always happen

  1. {"lscpu":[{"field":"Architecture:","data":"x86_64"},{"field":"CPU op-mode(s):","data":"32-bit, 64-bit"},{"field":"Address sizes:","data":"46 bits physical, 48 bits virtual"},{"field":"Byte Order:","data":"Little Endian"},{"field":"CPU(s):","data":"24"},{"field":"On-line CPU(s) list:","data":"0-23"},{"field":"Vendor ID:","data":"GenuineIntel"},{"field":"Model name:","data":"Intel(R) Xeon(R) CPU E5-2630L 0 @ 2.00GHz"},{"field":"CPU family:","data":"6"},{"field":"Model:","data":"45"},{"field":"Thread(s) per core:","data":"2"},{"field":"Core(s) per socket:","data":"6"},{"field":"Socket(s):","data":"2"},{"field":"Stepping:","data":"7"},{"field":"CPU(s) scaling MHz:","data":"60%"},{"field":"CPU max MHz:","data":"2500.0000"},{"field":"CPU min MHz:","data":"1200.0000"},{"field":"BogoMIPS:","data":"3990.19"},{"field":"Flags:","data":"fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm epb pti ssbd ibrs ibpb stibp tpr_shadow flexpriority ept vpid xsaveopt dtherm ida arat pln pts vnmi md_clear flush_l1d"},{"field":"Virtualization:","data":"VT-x"},{"field":"L1d cache:","data":"384 KiB (12 instances)"},{"field":"L1i cache:","data":"384 KiB (12 instances)"},{"field":"L2 cache:","data":"3 MiB (12 instances)"},{"field":"L3 cache:","data":"30 MiB (2 instances)"},{"field":"NUMA node(s):","data":"2"},{"field":"NUMA node0 CPU(s):","data":"0-5,12-17"},{"field":"NUMA node1 CPU(s):","data":"6-11,18-23"},{"field":"Vulnerability Gather data sampling:","data":"Not affected"},{"field":"Vulnerability Itlb multihit:","data":"KVM: Mitigation: Split huge pages"},{"field":"Vulnerability L1tf:","data":"Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable"},{"field":"Vulnerability Mds:","data":"Mitigation; Clear CPU buffers; SMT vulnerable"},{"field":"Vulnerability Meltdown:","data":"Mitigation; PTI"},{"field":"Vulnerability Mmio stale data:","data":"Unknown: No mitigations"},{"field":"Vulnerability Reg file data sampling:","data":"Not affected"},{"field":"Vulnerability Retbleed:","data":"Not affected"},{"field":"Vulnerability Spec rstack overflow:","data":"Not affected"},{"field":"Vulnerability Spec store bypass:","data":"Mitigation; Speculative Store Bypass disabled via prctl"},{"field":"Vulnerability Spectre v1:","data":"Mitigation; usercopy/swapgs barriers and __user pointer sanitization"},{"field":"Vulnerability Spectre v2:","data":"Mitigation; Retpolines; IBPB conditional; IBRS_FW; STIBP conditional; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected"},{"field":"Vulnerability Srbds:","data":"Not affected"},{"field":"Vulnerability Tsx async abort:","data":"Not affected"}]} ↩︎

Originally created by @thejjw on GitHub (Apr 29, 2025). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/3736 ### How are you running AnythingLLM? Docker (local) ### What happened? Hello, I know that the default lancedb have avx2 requirement [[#1331](https://github.com/Mintplex-Labs/anything-llm/issues/1331)] which prevents setup on old pc/server, whether run or docker or not. My server is on non-avx2 cpu so I have been using mintplexlabs/anythingllm:lancedb_revert image. Today however I wanted to try out new version by connecting it to chroma. I pulled and ran chromadb/chroma and mintplexlabs/anythingllm:latest image, all using new mount location for fresh setup. I noticed that I can't actually use chroma since I can't get past first screen for llm preference, which probably fails because it tries to save to lancedb. I understand lancedb requiring avx2. However the current setup flow prevents users from switching to alternatives especially if you run on non-avx2 cpu. Please see if the flow can be changed to allow setting db selection *before* other preference settings, which will hopefully allow users to run it on more hardware. In the meantime, are there any environment flag or other means I can pass to docker run for me to force anythingllm use chroma or other non-lancedb at runtime? I'd appreciate any help. Thanks. ### Are there known steps to reproduce? you run current version of anythingllm on this cpu[^1] this will always happen [^1]: {"lscpu":[{"field":"Architecture:","data":"x86_64"},{"field":"CPU op-mode(s):","data":"32-bit, 64-bit"},{"field":"Address sizes:","data":"46 bits physical, 48 bits virtual"},{"field":"Byte Order:","data":"Little Endian"},{"field":"CPU(s):","data":"24"},{"field":"On-line CPU(s) list:","data":"0-23"},{"field":"Vendor ID:","data":"GenuineIntel"},{"field":"Model name:","data":"Intel(R) Xeon(R) CPU E5-2630L 0 @ 2.00GHz"},{"field":"CPU family:","data":"6"},{"field":"Model:","data":"45"},{"field":"Thread(s) per core:","data":"2"},{"field":"Core(s) per socket:","data":"6"},{"field":"Socket(s):","data":"2"},{"field":"Stepping:","data":"7"},{"field":"CPU(s) scaling MHz:","data":"60%"},{"field":"CPU max MHz:","data":"2500.0000"},{"field":"CPU min MHz:","data":"1200.0000"},{"field":"BogoMIPS:","data":"3990.19"},{"field":"Flags:","data":"fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm epb pti ssbd ibrs ibpb stibp tpr_shadow flexpriority ept vpid xsaveopt dtherm ida arat pln pts vnmi md_clear flush_l1d"},{"field":"Virtualization:","data":"VT-x"},{"field":"L1d cache:","data":"384 KiB (12 instances)"},{"field":"L1i cache:","data":"384 KiB (12 instances)"},{"field":"L2 cache:","data":"3 MiB (12 instances)"},{"field":"L3 cache:","data":"30 MiB (2 instances)"},{"field":"NUMA node(s):","data":"2"},{"field":"NUMA node0 CPU(s):","data":"0-5,12-17"},{"field":"NUMA node1 CPU(s):","data":"6-11,18-23"},{"field":"Vulnerability Gather data sampling:","data":"Not affected"},{"field":"Vulnerability Itlb multihit:","data":"KVM: Mitigation: Split huge pages"},{"field":"Vulnerability L1tf:","data":"Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable"},{"field":"Vulnerability Mds:","data":"Mitigation; Clear CPU buffers; SMT vulnerable"},{"field":"Vulnerability Meltdown:","data":"Mitigation; PTI"},{"field":"Vulnerability Mmio stale data:","data":"Unknown: No mitigations"},{"field":"Vulnerability Reg file data sampling:","data":"Not affected"},{"field":"Vulnerability Retbleed:","data":"Not affected"},{"field":"Vulnerability Spec rstack overflow:","data":"Not affected"},{"field":"Vulnerability Spec store bypass:","data":"Mitigation; Speculative Store Bypass disabled via prctl"},{"field":"Vulnerability Spectre v1:","data":"Mitigation; usercopy/swapgs barriers and __user pointer sanitization"},{"field":"Vulnerability Spectre v2:","data":"Mitigation; Retpolines; IBPB conditional; IBRS_FW; STIBP conditional; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected"},{"field":"Vulnerability Srbds:","data":"Not affected"},{"field":"Vulnerability Tsx async abort:","data":"Not affected"}]}
yindo added the possible bug label 2026-02-22 18:29:31 -05:00
yindo closed this issue 2026-02-22 18:29:31 -05:00
yindo commented 2026-02-22 18:29:31 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Apr 29, 2025):

I noticed that I can't actually use chroma since I can't get past first screen for llm preference, which probably fails because it tries to save to lancedb.

Ah, that likely is the case. In that case, open the storage folder you are binding for the Docker container

# in this case storage folder is $HOME/anythingllm 
export STORAGE_LOCATION=$HOME/anythingllm && \
mkdir -p $STORAGE_LOCATION && \
touch "$STORAGE_LOCATION/.env" && \
# ... rest of docker cmd

Locate the STORAGE_LOCATION/.env file - add or update these lines in the file:

LLM_PROVIDER="openai" # or whatever
EMBEDDING_ENGINE="native"
VECTOR_DB="chroma"
CHROMA_ENDPOINT="http://host.docker.internal:8000"

This will basically allow you to skip onboarding on startup. Notice how I use host.docker.internal and not localhost when in the docker container so the AnythingLLM container can reach out of the container and reach the host localhost address.

As for the lancedb_revert image - simply put that is an unmaintained image we have simply as an escape hatch for people on older CPUs. We dont prioritize it or often update it. I think at this point it was last updated ~11 months ago!

We used to have onboarding have the embedder selection as part of it, but changes since then have removed that onboarding step so that is why you can get stuck in this loop now. When we made that image it was not the case.

@timothycarambat commented on GitHub (Apr 29, 2025): > I noticed that I can't actually use chroma since I can't get past first screen for llm preference, which probably fails because it tries to save to lancedb. Ah, that likely is the case. In that case, open the storage folder you are binding for the [Docker container](https://docs.anythingllm.com/installation-docker/local-docker#recommend-way-to-run-dockerized-anythingllm) ```bash # in this case storage folder is $HOME/anythingllm export STORAGE_LOCATION=$HOME/anythingllm && \ mkdir -p $STORAGE_LOCATION && \ touch "$STORAGE_LOCATION/.env" && \ # ... rest of docker cmd ``` Locate the `STORAGE_LOCATION/.env` file - add or update these lines in the file: ```env LLM_PROVIDER="openai" # or whatever EMBEDDING_ENGINE="native" VECTOR_DB="chroma" CHROMA_ENDPOINT="http://host.docker.internal:8000" ``` This will basically allow you to skip onboarding on startup. Notice how I use `host.docker.internal` and not localhost when in the docker container so the AnythingLLM container can reach out of the container and reach the host localhost address. As for the `lancedb_revert` image - simply put that is an unmaintained image we have simply as an escape hatch for people on older CPUs. We dont prioritize it or often update it. I think at this point it was last updated ~11 months ago! We used to have onboarding have the embedder selection as part of it, but changes since then have removed that onboarding step so that is why you can get stuck in this loop now. When we made that image it was not the case.
yindo commented 2026-02-22 18:29:32 -05:00
Author
Owner
Copy Link
Copy Source

@thejjw commented on GitHub (Apr 29, 2025):

Thank you.
Just adding below lines you suggested to .env file worked:

EMBEDDING_ENGINE="native"
VECTOR_DB="chroma"
CHROMA_ENDPOINT="http://host.docker.internal:8000"

Please do however consider providing more friendly workaround if possible in the future (i.e. can docker query lscpu output and alert user+set db to non-lancedb if avx2 not found?)

@thejjw commented on GitHub (Apr 29, 2025): Thank you. Just adding below lines you suggested to `.env` file worked: ``` EMBEDDING_ENGINE="native" VECTOR_DB="chroma" CHROMA_ENDPOINT="http://host.docker.internal:8000" ``` Please do however consider providing more friendly workaround if possible in the future (i.e. can docker query lscpu output and alert user+set db to non-lancedb if avx2 not found?)
yindo commented 2026-02-22 18:29:32 -05:00
Author
Owner
Copy Link
Copy Source

@thejjw commented on GitHub (Apr 29, 2025):

I thought that change would resolve all, since I was able to configure llm, create user, etc.
Apparently not, since I got this error on first chat:

Image

I had to give more tweaks to get it working via docker. First I tried setting CHROMA_SERVER_CORS_ALLOW_ORIGINS.. no luck, even with "*" (-e CHROMA_SERVER_CORS_ALLOW_ORIGINS='["*"]') same error persisted. I don't know why it doesn't work that way, but I got it working with docker network configuration.
I'm leaving my configuration here that worked for me currently, hope it might help others:

[0] apply .env changes as noted above (VECTOR_DB="chroma", etc.)

[1] create docker network
docker network create anythingllm-net

[2] run new container with network attached

docker run -d \
	--name anythingllm-chromadb \
	-p 8000:8000 \
	--network anythingllm-net \
	-v $HOME/chroma/:/chroma/chroma \
	chromadb/chroma &&\
STORAGE_LOCATION=$HOME/anythingllm docker run -d \
	--name anythingllm-anythingllm \
	-p 2222:3001 \
	--network anythingllm-net \
	--cap-add SYS_ADMIN \
	-v ${STORAGE_LOCATION}:/app/server/storage \
	-v ${STORAGE_LOCATION}/.env:/app/server/.env \
	-e STORAGE_DIR="/app/server/storage" \
	mintplexlabs/anythingllm

this assumes data directories are already set up 1

[3] set chromadb as vector database (optional?)
I changed to http://anythingllm-chromadb:8000 , but it may have worked without anyway (leaving it as http://host.docker.internal:8000) , not sure.

  1. mkdir -pv $HOME/chroma && export STORAGE_LOCATION=$HOME/anythingllm && mkdir -pv $STORAGE_LOCATION && touch "$STORAGE_LOCATION/.env" && chmod -Rv 777 $STORAGE_LOCATION ↩︎

@thejjw commented on GitHub (Apr 29, 2025): I thought that change would resolve all, since I was able to configure llm, create user, etc. Apparently not, since I got this error on first chat: ![Image](https://github.com/user-attachments/assets/413fb577-3c02-4ba8-ac85-46434472e3cb) I had to give more tweaks to get it working via docker. First I tried setting `CHROMA_SERVER_CORS_ALLOW_ORIGINS`.. no luck, even with "*" (`-e CHROMA_SERVER_CORS_ALLOW_ORIGINS='["*"]'`) same error persisted. I don't know why it doesn't work that way, but I got it working with docker network configuration. I'm leaving my configuration here that worked for me currently, hope it might help others: [0] apply `.env` changes as noted above (`VECTOR_DB="chroma"`, etc.) [1] create docker network `docker network create anythingllm-net` [2] run new container with network attached ``` docker run -d \ --name anythingllm-chromadb \ -p 8000:8000 \ --network anythingllm-net \ -v $HOME/chroma/:/chroma/chroma \ chromadb/chroma &&\ STORAGE_LOCATION=$HOME/anythingllm docker run -d \ --name anythingllm-anythingllm \ -p 2222:3001 \ --network anythingllm-net \ --cap-add SYS_ADMIN \ -v ${STORAGE_LOCATION}:/app/server/storage \ -v ${STORAGE_LOCATION}/.env:/app/server/.env \ -e STORAGE_DIR="/app/server/storage" \ mintplexlabs/anythingllm ``` this assumes data directories are already set up [^1] [3] set chromadb as vector database (optional?) I changed to `http://anythingllm-chromadb:8000` , but it may have worked without anyway (leaving it as `http://host.docker.internal:8000`) , not sure. --- [^1]: `mkdir -pv $HOME/chroma && export STORAGE_LOCATION=$HOME/anythingllm && mkdir -pv $STORAGE_LOCATION && touch "$STORAGE_LOCATION/.env" && chmod -Rv 777 $STORAGE_LOCATION`
yindo commented 2026-02-22 18:29:32 -05:00
Author
Owner
Copy Link
Copy Source

@thejjw commented on GitHub (Apr 30, 2025):

ok...it works for llm usage. i do notice a quirk that might or might not have to do with my configuration.

do tell me if i better create a new issue for this. for now i'm not sure whether this has to do with my configuration or if this is more general issue.

I can't invoke agent for questions--getting Could not respond to message. / POST predict: Post "http://127.0.0.1:36591/completion": EOF message instead. I mean, I didnt set up web search option but it does have scrape websites feature on by default..so getting an error was the least of what I was expecting.

Image

What is going on? my windows desktop anythingllm doesnt produce this message.

Image

this is docker logs

:~$ docker logs anythingllm-anythingllm | tail -n30
┌─────────────────────────────────────────────────────────┐
│  Update available 5.3.1 -> 6.7.0                        │
│                                                         │
│  This is a major update - please follow the guide at    │
│  https://pris.ly/d/major-version-upgrade                │
│                                                         │
│  Run the following to update                            │
│    npm i --save-dev prisma@latest                       │
│    npm i @prisma/client@latest                          │
└─────────────────────────────────────────────────────────┘
    at async Ollama.processStreamableRequest (/app/server/node_modules/ollama/dist/browser.cjs:252:22)
    at async #handleFunctionCallChat (/app/server/utils/agents/aibitat/providers/ollama.js:35:22)
    at async OllamaProvider.functionCall (/app/server/utils/agents/aibitat/providers/helpers/untooled.js:113:22)
    at async OllamaProvider.complete (/app/server/utils/agents/aibitat/providers/ollama.js:56:36)
    at async AIbitat.handleExecution (/app/server/utils/agents/aibitat/index.js:594:24)
    at async AIbitat.reply (/app/server/utils/agents/aibitat/index.js:576:21)
    at async AIbitat.chat (/app/server/utils/agents/aibitat/index.js:374:15)
[backend] info: [AgentHandler] End 8225ee98-d58c-4804-820f-6434fd26dd73::ollama:gemma3:12b-it-q4_K_M
[backend] info: [Event Logged] - sent_chat
[backend] info: [AgentHandler] Start 6ab1440f-6724-4777-bf19-dc9a674a446c::ollama:gemma3:12b-it-q4_K_M
[backend] info: [AgentHandler] Attached websocket plugin to Agent cluster
[backend] info: [AgentHandler] Attached chat-history plugin to Agent cluster
[backend] info: [AgentHandler] Attaching user and default agent to Agent cluster.
[backend] info: [MCPCompatibilityLayer] Successfully started 0 MCP servers: []
[backend] info: [MCPCompatibilityLayer] Successfully started 0 MCP servers: []
[backend] info: [AgentHandler] Attached rag-memory plugin to Agent cluster
[backend] info: [AgentHandler] Attached document-summarizer plugin to Agent cluster
[backend] info: [AgentHandler] Attached web-scraping plugin to Agent cluster
[backend] error: POST predict: Post "http://127.0.0.1:36591/completion": EOF ResponseError: POST predict: Post "http://127.0.0.1:36591/completion": EOF
    at checkOk (/app/server/node_modules/ollama/dist/browser.cjs:74:9)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async post (/app/server/node_modules/ollama/dist/browser.cjs:120:3)
    at async Ollama.processStreamableRequest (/app/server/node_modules/ollama/dist/browser.cjs:252:22)
    at async #handleFunctionCallChat (/app/server/utils/agents/aibitat/providers/ollama.js:35:22)
    at async OllamaProvider.functionCall (/app/server/utils/agents/aibitat/providers/helpers/untooled.js:113:22)
    at async OllamaProvider.complete (/app/server/utils/agents/aibitat/providers/ollama.js:56:36)
    at async AIbitat.handleExecution (/app/server/utils/agents/aibitat/index.js:594:24)
    at async AIbitat.reply (/app/server/utils/agents/aibitat/index.js:576:21)
    at async AIbitat.chat (/app/server/utils/agents/aibitat/index.js:374:15)
[backend] info: [AgentHandler] End 6ab1440f-6724-4777-bf19-dc9a674a446c::ollama:gemma3:12b-it-q4_K_M

this is trying to see if anything was available at 36591 port in the container...i guess not. is it supposed to be available?

anythingllm@1bf41b1db54c:~$ curl http://127.0.0.1:3001/ | tail -n3
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1690  100  1690    0     0   455k      0 --:--:-- --:--:-- --:--:--  550k
            <div id="root" class="h-screen"></div>                                                                                </body>                                                                                                               </html>
anythingllm@1bf41b1db54c:~$ curl http://127.0.0.1:36591/completion
curl: (7) Failed to connect to 127.0.0.1 port 36591 after 0 ms: Connection refused

my anythingllm image:

$ docker inspect --format "{{.Image}}" anythingllm-anythingllm
sha256:4d88beef5467ecf37653800f425a315f1d89a070b4259cf3aacb2d57a6ea4a02

For now I'm just using local LLM as-is and that is fine for most cases...but I'd appreciate any help.
Thanks.

@thejjw commented on GitHub (Apr 30, 2025): ok...it works for llm usage. i do notice a quirk that might or might not have to do with my configuration. do tell me if i better create a new issue for this. for now i'm not sure whether this has to do with my configuration or if this is more general issue. I can't invoke agent for questions--getting ` Could not respond to message. / POST predict: Post "http://127.0.0.1:36591/completion": EOF` message instead. I mean, I didnt set up web search option but it does have scrape websites feature on by default..so getting an error was the least of what I was expecting. ![Image](https://github.com/user-attachments/assets/06c914e8-d5ae-4d20-b78c-0f310cfe16a1) What is going on? my windows desktop anythingllm doesnt produce this message. ![Image](https://github.com/user-attachments/assets/a3db6c6a-67b0-4894-8c12-c7c45f8a5907) this is docker logs ``` :~$ docker logs anythingllm-anythingllm | tail -n30 ┌─────────────────────────────────────────────────────────┐ │ Update available 5.3.1 -> 6.7.0 │ │ │ │ This is a major update - please follow the guide at │ │ https://pris.ly/d/major-version-upgrade │ │ │ │ Run the following to update │ │ npm i --save-dev prisma@latest │ │ npm i @prisma/client@latest │ └─────────────────────────────────────────────────────────┘ at async Ollama.processStreamableRequest (/app/server/node_modules/ollama/dist/browser.cjs:252:22) at async #handleFunctionCallChat (/app/server/utils/agents/aibitat/providers/ollama.js:35:22) at async OllamaProvider.functionCall (/app/server/utils/agents/aibitat/providers/helpers/untooled.js:113:22) at async OllamaProvider.complete (/app/server/utils/agents/aibitat/providers/ollama.js:56:36) at async AIbitat.handleExecution (/app/server/utils/agents/aibitat/index.js:594:24) at async AIbitat.reply (/app/server/utils/agents/aibitat/index.js:576:21) at async AIbitat.chat (/app/server/utils/agents/aibitat/index.js:374:15) [backend] info: [AgentHandler] End 8225ee98-d58c-4804-820f-6434fd26dd73::ollama:gemma3:12b-it-q4_K_M [backend] info: [Event Logged] - sent_chat [backend] info: [AgentHandler] Start 6ab1440f-6724-4777-bf19-dc9a674a446c::ollama:gemma3:12b-it-q4_K_M [backend] info: [AgentHandler] Attached websocket plugin to Agent cluster [backend] info: [AgentHandler] Attached chat-history plugin to Agent cluster [backend] info: [AgentHandler] Attaching user and default agent to Agent cluster. [backend] info: [MCPCompatibilityLayer] Successfully started 0 MCP servers: [] [backend] info: [MCPCompatibilityLayer] Successfully started 0 MCP servers: [] [backend] info: [AgentHandler] Attached rag-memory plugin to Agent cluster [backend] info: [AgentHandler] Attached document-summarizer plugin to Agent cluster [backend] info: [AgentHandler] Attached web-scraping plugin to Agent cluster [backend] error: POST predict: Post "http://127.0.0.1:36591/completion": EOF ResponseError: POST predict: Post "http://127.0.0.1:36591/completion": EOF at checkOk (/app/server/node_modules/ollama/dist/browser.cjs:74:9) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) at async post (/app/server/node_modules/ollama/dist/browser.cjs:120:3) at async Ollama.processStreamableRequest (/app/server/node_modules/ollama/dist/browser.cjs:252:22) at async #handleFunctionCallChat (/app/server/utils/agents/aibitat/providers/ollama.js:35:22) at async OllamaProvider.functionCall (/app/server/utils/agents/aibitat/providers/helpers/untooled.js:113:22) at async OllamaProvider.complete (/app/server/utils/agents/aibitat/providers/ollama.js:56:36) at async AIbitat.handleExecution (/app/server/utils/agents/aibitat/index.js:594:24) at async AIbitat.reply (/app/server/utils/agents/aibitat/index.js:576:21) at async AIbitat.chat (/app/server/utils/agents/aibitat/index.js:374:15) [backend] info: [AgentHandler] End 6ab1440f-6724-4777-bf19-dc9a674a446c::ollama:gemma3:12b-it-q4_K_M ``` this is trying to see if anything was available at 36591 port in the container...i guess not. is it supposed to be available? ``` anythingllm@1bf41b1db54c:~$ curl http://127.0.0.1:3001/ | tail -n3 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 1690 100 1690 0 0 455k 0 --:--:-- --:--:-- --:--:-- 550k <div id="root" class="h-screen"></div> </body> </html> anythingllm@1bf41b1db54c:~$ curl http://127.0.0.1:36591/completion curl: (7) Failed to connect to 127.0.0.1 port 36591 after 0 ms: Connection refused ``` my anythingllm image: ``` $ docker inspect --format "{{.Image}}" anythingllm-anythingllm sha256:4d88beef5467ecf37653800f425a315f1d89a070b4259cf3aacb2d57a6ea4a02 ``` For now I'm just using local LLM as-is and that is fine for most cases...but I'd appreciate any help. Thanks.
yindo commented 2026-02-22 18:29:32 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Apr 30, 2025):

Somewhere in the app you have Ollama set as your LLM provider or your workspaces Agent LLM provider. Then it is looking to connect to http://127.0.0.1:36591/completion which wont work for the exact same reason Chroma couldn't connect.

If you are in Docker, 127.0.0.1 and all localhost routes are inside the container. Use host.docker.internal so you can reach the host network and access services running on the host machine localhost.

This applies to every host-running localhost service, not just chroma. This is just how Docker networking works in the standard config setup without having to mess with networking layers.

That is all that is happening here - you are using 127.0.0.1 instead of the docker<->host special gateway address. We have this documented in several places.

https://docs.anythingllm.com/ollama-connection-troubleshooting
https://github.com/Mintplex-Labs/anything-llm/blob/master/server/utils/AiProviders/ollama/README.md

@timothycarambat commented on GitHub (Apr 30, 2025): Somewhere in the app you have `Ollama` set as your LLM provider or your workspaces `Agent LLM provider`. Then it is looking to connect to `http://127.0.0.1:36591/completion` which wont work for the exact same reason Chroma couldn't connect. If you are in Docker, `127.0.0.1` and all `localhost` routes are _inside the container_. Use `host.docker.internal` so you can reach the host network and access services running on the host machine localhost. This applies to every host-running localhost service, not just chroma. This is just how Docker networking works in the standard config setup without having to mess with networking layers. That is all that is happening here - you are using 127.0.0.1 instead of the docker<->host special gateway address. We have this documented in several places. https://docs.anythingllm.com/ollama-connection-troubleshooting https://github.com/Mintplex-Labs/anything-llm/blob/master/server/utils/AiProviders/ollama/README.md
yindo commented 2026-02-22 18:29:32 -05:00
Author
Owner
Copy Link
Copy Source

@thejjw commented on GitHub (Apr 30, 2025):

Somewhere in the app you have Ollama set as your LLM provider or your workspaces Agent LLM provider. Then it is looking to connect to http://127.0.0.1:36591/completion which wont work for the exact same reason Chroma couldn't connect.

If you are in Docker, 127.0.0.1 and all localhost routes are inside the container. Use host.docker.internal so you can reach the host network and access services running on the host machine localhost.

This applies to every host-running localhost service, not just chroma. This is just how Docker networking works in the standard config setup without having to mess with networking layers.

That is all that is happening here - you are using 127.0.0.1 instead of the docker<->host special gateway address. We have this documented in several places.

https://docs.anythingllm.com/ollama-connection-troubleshooting https://github.com/Mintplex-Labs/anything-llm/blob/master/server/utils/AiProviders/ollama/README.md

  1. Thanks for the assistance.
  2. You are right in that I have set Ollama as my LLM provider. I did not know the http://127.0.0.1:36591/completion was trying to access LLM(Ollama) in this case, because my other non-agent chat requests went fine without problem silently. I was looking at wrong place in that case then.
  3. Why would it want to use 127.0.0.1 though? Just like how you mentioned in docs.. I did not set my Ollama base URL to 127.0.0.1.. I set it to http://172.17.0.1:11434 (since host.docker.internal didn't work on my machine1 2 . could host.docker.internal be a new version thing unsupported by my distribution's package?) In fact it picked up that address automatically if I recall correctly.
  4. To my understanding, anythingllm should have right configuration for local ollama service--which is why non-agent chat works. Ollama service has OLLAMA_HOST=0.0.0.0 set in its config as well too 3 . The error is somewhat different too, since the article mentions port 11434 but it's not that port in my case (it seems randomly picked?).

Thanks.

  1. this is working configuration
    Image ↩︎

  2. this host.docker.internal change does not seem to work on my case
    Image ↩︎

  3. Image ↩︎

@thejjw commented on GitHub (Apr 30, 2025): > Somewhere in the app you have `Ollama` set as your LLM provider or your workspaces `Agent LLM provider`. Then it is looking to connect to `http://127.0.0.1:36591/completion` which wont work for the exact same reason Chroma couldn't connect. > > If you are in Docker, `127.0.0.1` and all `localhost` routes are _inside the container_. Use `host.docker.internal` so you can reach the host network and access services running on the host machine localhost. > > This applies to every host-running localhost service, not just chroma. This is just how Docker networking works in the standard config setup without having to mess with networking layers. > > That is all that is happening here - you are using 127.0.0.1 instead of the docker<->host special gateway address. We have this documented in several places. > > https://docs.anythingllm.com/ollama-connection-troubleshooting https://github.com/Mintplex-Labs/anything-llm/blob/master/server/utils/AiProviders/ollama/README.md 1. Thanks for the assistance. 2. You are right in that I have set Ollama as my LLM provider. I did not know the `http://127.0.0.1:36591/completion` was trying to access LLM(Ollama) in this case, because my **other** non-agent chat requests went fine without problem silently. I was looking at wrong place in that case then. 3. Why would it want to use 127.0.0.1 though? Just like how you mentioned in docs.. I did not set my Ollama base URL to 127.0.0.1.. I set it to `http://172.17.0.1:11434` (since `host.docker.internal` didn't work on my machine[^1][^2]. could `host.docker.internal` be a new version thing unsupported by my distribution's package?) In fact it picked up that address automatically if I recall correctly. 4. To my understanding, anythingllm should have right configuration for local ollama service--which is why non-agent chat works. Ollama service has `OLLAMA_HOST=0.0.0.0` set in its config as well too [^3]. The error is somewhat different too, since [the article](https://github.com/Mintplex-Labs/anything-llm/blob/master/server/utils/AiProviders/ollama/README.md) mentions `port 11434` but it's not that port in my case (it seems randomly picked?). Thanks. --- [^1]: this is working configuration ![Image](https://github.com/user-attachments/assets/f8898006-f0c1-47e4-80ac-18ea9a1a44a7) [^2]: this `host.docker.internal` change does not seem to work on my case ![Image](https://github.com/user-attachments/assets/54e2a527-58b8-4db0-b3a7-6c1a6e08f5c4) [^3]: ![Image](https://github.com/user-attachments/assets/b0e75938-7b8e-4e4c-93ba-46e2c403f519)
yindo commented 2026-02-22 18:29:32 -05:00
Author
Owner
Copy Link
Copy Source

@thejjw commented on GitHub (May 6, 2025):

Hello,
I hope it's okay to continue on this thread(issue).
I updated to newest image and still get the same issue:

$ docker images
REPOSITORY                 TAG              IMAGE ID       CREATED         SIZE
mintplexlabs/anythingllm   latest           307e1732b694   3 hours ago     2.78GB
mintplexlabs/anythingllm   <none>           4d88beef5467   7 days ago      2.78GB

I noticed that it's contacting different port every time actually:
Image

Maybe if it tries 172.17.0.1 instead of 127.0.0.1 it would work? But then it is already configured to use 172.17.0.1 for ollama base url..where else would i configure?

Please advise.

Thanks.

@thejjw commented on GitHub (May 6, 2025): Hello, I hope it's okay to continue on this thread(issue). I updated to newest image and still get the same issue: ``` $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE mintplexlabs/anythingllm latest 307e1732b694 3 hours ago 2.78GB mintplexlabs/anythingllm <none> 4d88beef5467 7 days ago 2.78GB ``` I noticed that it's contacting different port every time actually: ![Image](https://github.com/user-attachments/assets/a27a844c-d7ea-442c-8f56-55e4f49cb7b8) Maybe if it tries 172.17.0.1 instead of 127.0.0.1 it would work? But then it is already configured to use 172.17.0.1 for ollama base url..where else would i configure? Please advise. Thanks.
yindo commented 2026-02-22 18:29:32 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (May 6, 2025):

https://docs.anythingllm.com/ollama-connection-troubleshooting#troubleshooting-docker

Are you running docker on mac, windows, or linux? That doc above shows the right special gateway to use that maps to the host. So if you have Ollama running on 127.0.0.1:11434 on the host and can reach it in browser, then in the AnythingLLM app you just need to use http://172.17.0.1:11434 as the Ollama base URL and it will map correctly.

@timothycarambat commented on GitHub (May 6, 2025): https://docs.anythingllm.com/ollama-connection-troubleshooting#troubleshooting-docker Are you running docker on mac, windows, or linux? That doc above shows the right special gateway to use that maps to the host. So if you have Ollama running on 127.0.0.1:11434 on the host and can reach it in browser, then in the AnythingLLM app you just need to use `http://172.17.0.1:11434` as the Ollama base URL and it will map correctly.
yindo commented 2026-02-22 18:29:32 -05:00
Author
Owner
Copy Link
Copy Source

@thejjw commented on GitHub (May 7, 2025):

Are you running docker on mac, windows, or linux?

I'm running on linux.

            .-/+oossssoo+/-.               
        `:+ssssssssssssssssss+:`           --------------
      -+ssssssssssssssssssyyssss+-         OS: Ubuntu 24.04.2 LTS x86_64
    .ossssssssssssssssssdMMMNysssso.       Host: ProLiant DL360p Gen8
   /ssssssssssshdmmNNmmyNMMMMhssssss/      Kernel: 6.8.0-57-generic
  +ssssssssshmydMMMMMMMNddddyssssssss+     Uptime: 13 days, 21 hours, 15 mins
 /sssssssshNMMMyhhyyyyhmNMMMNhssssssss/    Packages: 1242 (dpkg)
.ssssssssdMMMNhsssssssssshNMMMdssssssss.   Shell: bash 5.2.21
+sssshhhyNMMNyssssssssssssyNMMMysssssss+   Resolution: 1024x768
ossyNMMMNyMMhsssssssssssssshmmmhssssssso   Terminal: /dev/pts/0
ossyNMMMNyMMhsssssssssssssshmmmhssssssso   CPU: Intel Xeon E5-2630L 0 (24) @ 2.500GHz
+sssshhhyNMMNyssssssssssssyNMMMysssssss+   GPU: 01:00.1 Matrox Electronics Systems Ltd. MGA G200EH
.ssssssssdMMMNhsssssssssshNMMMdssssssss.   Memory: 4103MiB / 64344MiB
 /sssssssshNMMMyhhyyyyhdNMMMNhssssssss/
  +sssssssssdmydMMMMMMMMddddyssssssss+
   /ssssssssssshdmNNNNmyNMMMMhssssss/
    .ossssssssssssssssssdMMMNysssso.
      -+sssssssssssssssssyyyssss+-
        `:+ssssssssssssssssss+:`
            .-/+oossssoo+/-.

That doc above shows the right special gateway to use that maps to the host. So if you have Ollama running on 127.0.0.1:11434 on the host and can reach it in browser, then in the AnythingLLM app you just need to use http://172.17.0.1:11434 as the Ollama base URL and it will map correctly.

So just to summarize it's [linux server with (1) ollama service locally installed (2) docker anythingllm container (3) docker chromadb container] (accessed via my pc) setup.
I did use 172.17.0.1:11434 as ollama base url. and in fact it's working fine without agent..
it's just when i activate @agent that things go weird (as seen in https://github.com/Mintplex-Labs/anything-llm/issues/3736#issuecomment-2856654841)

$ docker exec -it anythingllm-anythingllm /bin/bash
anythingllm@873ff3ab1bc1:~$ cat server/.env && echo '\n'
# Auto-dump ENV from system call on 01:07:09 GMT+0000 (Coordinated Universal Time)
LLM_PROVIDER='ollama'
OLLAMA_BASE_PATH='http://172.17.0.1:11434'
OLLAMA_MODEL_PREF='qwen3:latest'
OLLAMA_MODEL_TOKEN_LIMIT='4096'
OLLAMA_PERFORMANCE_MODE='base'
OLLAMA_KEEP_ALIVE_TIMEOUT='300'
EMBEDDING_ENGINE='native'
VECTOR_DB='chroma'
CHROMA_ENDPOINT='http://anythingllm-chromadb:8000'
JWT_SECRET=redacted
STORAGE_DIR='/app/server/storage'
SIG_KEY=redacted
SIG_SALT=redacted
anythingllm@873ff3ab1bc1:~$

I don't think my setup is that abnormal (except that I run on non-avx2 cpu)...
I do believe the project is excellent and it serves me very well personally (on windows)..I wish I could just set this up for shared usage as well.

Thanks for keeping up with me on this.

@thejjw commented on GitHub (May 7, 2025): > Are you running docker on mac, windows, or linux? I'm running on linux. ``` .-/+oossssoo+/-. `:+ssssssssssssssssss+:` -------------- -+ssssssssssssssssssyyssss+- OS: Ubuntu 24.04.2 LTS x86_64 .ossssssssssssssssssdMMMNysssso. Host: ProLiant DL360p Gen8 /ssssssssssshdmmNNmmyNMMMMhssssss/ Kernel: 6.8.0-57-generic +ssssssssshmydMMMMMMMNddddyssssssss+ Uptime: 13 days, 21 hours, 15 mins /sssssssshNMMMyhhyyyyhmNMMMNhssssssss/ Packages: 1242 (dpkg) .ssssssssdMMMNhsssssssssshNMMMdssssssss. Shell: bash 5.2.21 +sssshhhyNMMNyssssssssssssyNMMMysssssss+ Resolution: 1024x768 ossyNMMMNyMMhsssssssssssssshmmmhssssssso Terminal: /dev/pts/0 ossyNMMMNyMMhsssssssssssssshmmmhssssssso CPU: Intel Xeon E5-2630L 0 (24) @ 2.500GHz +sssshhhyNMMNyssssssssssssyNMMMysssssss+ GPU: 01:00.1 Matrox Electronics Systems Ltd. MGA G200EH .ssssssssdMMMNhsssssssssshNMMMdssssssss. Memory: 4103MiB / 64344MiB /sssssssshNMMMyhhyyyyhdNMMMNhssssssss/ +sssssssssdmydMMMMMMMMddddyssssssss+ /ssssssssssshdmNNNNmyNMMMMhssssss/ .ossssssssssssssssssdMMMNysssso. -+sssssssssssssssssyyyssss+- `:+ssssssssssssssssss+:` .-/+oossssoo+/-. ``` > That doc above shows the right special gateway to use that maps to the host. So if you have Ollama running on 127.0.0.1:11434 on the host and can reach it in browser, then in the AnythingLLM app you just need to use http://172.17.0.1:11434 as the Ollama base URL and it will map correctly. So just to summarize it's [linux server with (1) ollama service locally installed (2) docker anythingllm container (3) docker chromadb container] (accessed via my pc) setup. I did use 172.17.0.1:11434 as ollama base url. and in fact it's working fine without agent.. it's just when i activate `@agent` that things go weird (as seen in https://github.com/Mintplex-Labs/anything-llm/issues/3736#issuecomment-2856654841) ``` $ docker exec -it anythingllm-anythingllm /bin/bash anythingllm@873ff3ab1bc1:~$ cat server/.env && echo '\n' # Auto-dump ENV from system call on 01:07:09 GMT+0000 (Coordinated Universal Time) LLM_PROVIDER='ollama' OLLAMA_BASE_PATH='http://172.17.0.1:11434' OLLAMA_MODEL_PREF='qwen3:latest' OLLAMA_MODEL_TOKEN_LIMIT='4096' OLLAMA_PERFORMANCE_MODE='base' OLLAMA_KEEP_ALIVE_TIMEOUT='300' EMBEDDING_ENGINE='native' VECTOR_DB='chroma' CHROMA_ENDPOINT='http://anythingllm-chromadb:8000' JWT_SECRET=redacted STORAGE_DIR='/app/server/storage' SIG_KEY=redacted SIG_SALT=redacted anythingllm@873ff3ab1bc1:~$ ``` I don't think my setup is that abnormal (except that I run on non-avx2 cpu)... I do believe the project is excellent and it serves me very well personally (on windows)..I wish I could just set this up for shared usage as well. Thanks for keeping up with me on this.
yindo commented 2026-02-22 18:29:33 -05:00
Author
Owner
Copy Link
Copy Source

@Sarmingsteiner commented on GitHub (May 8, 2025):

Hi,
I'm also running into issues when trying to use ChromaDB in Docker with AnythingLLM.

AnythingLLM only starts successfully when the storage path is not mapped to a local volume.
If I only map the .env file (preconfigured as described above), it works fine.

However, if I:

  • Run the container once without any volume mapping → anythingllm.db is created.
  • Copy the anythingllm.db file from the running container to a local folder.
  • Map that folder as a volume in Docker (same storage path as used internally).
  • Restart the container.
    …then AnythingLLM fails to start.

Questions:

  • Is anythingllm.db the internal vector database (i.e. LanceDB), or is it only used for application configuration and settings?
  • Is there a recommended way to persist AnythingLLM data using Docker volumes?
  • Could this behavior be related to file permissions, ownership, or locking issues?

Any help or clarification on how to properly map and persist AnythingLLM storage would be greatly appreciated. Thanks!

@Sarmingsteiner commented on GitHub (May 8, 2025): Hi, I'm also running into issues when trying to use ChromaDB in Docker with AnythingLLM. AnythingLLM only starts successfully when the storage path is not mapped to a local volume. If I only map the `.env` file (preconfigured as described above), it works fine. However, if I: - Run the container once without any volume mapping → anythingllm.db is created. - Copy the anythingllm.db file from the running container to a local folder. - Map that folder as a volume in Docker (same storage path as used internally). - Restart the container. …then AnythingLLM fails to start. Questions: - Is anythingllm.db the internal vector database (i.e. LanceDB), or is it only used for application configuration and settings? - Is there a recommended way to persist AnythingLLM data using Docker volumes? - Could this behavior be related to file permissions, ownership, or locking issues? Any help or clarification on how to properly map and persist AnythingLLM storage would be greatly appreciated. Thanks!
yindo commented 2026-02-22 18:29:33 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (May 8, 2025):

AnythingLLM only starts successfully when the storage path is not mapped to a local volume.
Copy the anythingllm.db file from the running container to a local folder.
Is there a recommended way to persist AnythingLLM data using Docker volumes?

All of this is addressed by our docs -> Deploy docker locally this maps the storage and env so it persists constantly between containers

Is anythingllm.db the internal vector database (i.e. LanceDB), or is it only used for application configuration and settings?

That is a regular DB, the default vector datase is in the storage folder you would mount under the lancedb folder. Since you are running chroma on the host, all your vectors will go to the chroma storage folder instead

@timothycarambat commented on GitHub (May 8, 2025): > AnythingLLM only starts successfully when the storage path is not mapped to a local volume. > Copy the anythingllm.db file from the running container to a local folder. > Is there a recommended way to persist AnythingLLM data using Docker volumes? All of this is addressed by our docs -> [Deploy docker locally](https://docs.anythingllm.com/installation-docker/local-docker#recommend-way-to-run-dockerized-anythingllm) this maps the storage and env so it persists constantly between containers > Is anythingllm.db the internal vector database (i.e. LanceDB), or is it only used for application configuration and settings? That is a regular DB, the default vector datase is in the storage folder you would mount under the `lancedb` folder. Since you are running chroma on the host, all your vectors will go to the chroma storage folder instead
yindo commented 2026-02-22 18:29:33 -05:00
Author
Owner
Copy Link
Copy Source

@Sarmingsteiner commented on GitHub (May 8, 2025):

Thanks for the quick reply. After thoroughly reviewing the documentation again, I realized the issue was related to file permissions and ownership.

I followed the advice from issue #1965 and set both the GID and UID to 1000 for the local file paths, which resolved the problem.

Also, it appears that changing the vector database connection only works by editing the .env file directly – modifying it via the GUI doesn't seem to take effect.

@Sarmingsteiner commented on GitHub (May 8, 2025): Thanks for the quick reply. After thoroughly reviewing the documentation again, I realized the issue was related to file permissions and ownership. I followed the advice from issue #1965 and set both the GID and UID to `1000` for the local file paths, which resolved the problem. Also, it appears that changing the vector database connection only works by editing the `.env` file directly – modifying it via the GUI doesn't seem to take effect.
yindo commented 2026-02-22 18:29:33 -05:00
Author
Owner
Copy Link
Copy Source

@thejjw commented on GitHub (May 19, 2025):

In the end I brought in mac mini m4 and everything works including @agent (wasn't for anythingllm in particular but why not)
the lesson is...don't use archaic (disputable...it still mostly works..) hardware?

@thejjw commented on GitHub (May 19, 2025): In the end I brought in mac mini m4 and everything works including `@agent` (wasn't for anythingllm in particular but why not) the lesson is...don't use archaic (disputable...it still mostly works..) hardware?
yindo commented 2026-02-22 18:29:33 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (May 20, 2025):

Image

this is just a joke, but really, though - we cannot support every single piece of decade+ old tech

@timothycarambat commented on GitHub (May 20, 2025): ![Image](https://github.com/user-attachments/assets/4d04ad2e-ce6b-4af7-bcee-aa42a0e64f38) _this is just a joke, but really, though - we cannot support every single piece of decade+ old tech_
yindo changed title from [question/bug?]: how can anythingllm be set up on non-avx2 cpu? crash on initial onboarding to [GH-ISSUE #3736] [question/bug?]: how can anythingllm be set up on non-avx2 cpu? crash on initial onboarding 2026-06-05 14:46:21 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label possible bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#2404
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?