coleam00
🐛 [Bug]:Backend Service Startup Failure
Archon Version
v0.1.0
Bug Severity
🔴 Critical - App unusable
Bug Description
Get started on the most exciting piece of software Ive heard of in awhile.
Steps to Reproduce
Load UI website. Wait 7s Error Click retry UI loads Wait 7s Error
Rinse and repeat
Expected Behavior
Site should have loaded and become usable.
Actual Behavior
UI Loads just fine, about ten second laters this pop up restricts UI. I can retry connection and all seems well for another 5-10 seconds and it repeats ad nauseum.
Logs - Clean Issue on multiple installs on different computers. Both Linux OS.
Error Details (if any)
Backend Service Startup Failure
The Archon backend service failed to start. This is typically due to a configuration issue.
Check Docker Logs
Check the Archon API server container logs in Docker Desktop for detailed error information.
1. Open Docker Desktop
2. Go to Containers tab
3. Look for the Archon server container (typically named archon-server or similar)
4. View the logs for the specific error message
Common issue: Using an ANON key instead of SERVICE key in your .env file
After fixing the issue in your .env file, recreate the Docker containers:
docker compose down && docker compose up -d
Note: Use 'down' and 'up', not 'restart' - containers need to be recreated to load new environment variables
Retry Connection
Affected Component
🖥️ User Interface
Browser & OS
Synology and Debian 12
Additional Context
Firstly, thanks everyone for this effort here. Very exciting stuff.
I installed on my Synology and had to grapple with it for many hours, before trying it on a Debian install which displayed the same issues.
Ive been around the bend and back, undoing, redoing, Wiped Supabase, reconfigured. (the only thing I havent done yet, is delete the entire Supabase project.)
Ive had issues with containers talking this or that etc etc, usually something in the log I can resolve. I often created these issues from the error at which I find myself now. i.e., making it worse, then fixing what i broke before getting it back to where it was.
Which is that I get this backend error. It pops up after a few seconds. Saying there's no access to the backend.
I can retry and I get access to the UI for a few seconds at the time.
I can create projects, and then I can see the projects I created in the UI in the database. I've tried changing settings directly in supabase, e.g., adding an API key there since I cant on the UI. The python tests pass on the UI, but the React test fails before even starting (only clue) The logs seem clean, without any clues. The issue occured for me on my synology over several wipes, and rebuilts, and also a clean install on Debian 12
Service Status (check all that are working)
- [x] 🖥️ Frontend UI (http://localhost:3737)
- [x] ⚙️ Main Server (http://localhost:8181)
- [x] 🔗 MCP Service (localhost:8051)
- [x] 🤖 Agents Service (http://localhost:8052)
- [x] 💾 Supabase Database (connected)
Not sure if this is helpful or not, but i made progress by eventually starting a new project in Supabase. And giving the new URL and Service Key to archon.
The script to wipe the dbase, and start over didnt work at all, but the new project seems to be doing better. Im grappling a bit with getting Kilo connected via MCP tho.
MCP errors I cant figure out!
PS C:\WINDOWS\system32> curl.exe -i -N -H "Accept: text/event-stream" "http://172.17.20.2:8051/mcp?session_id=$session" HTTP/1.1 400 Bad Request date: Tue, 26 Aug 2025 16:05:27 GMT server: uvicorn content-type: application/json mcp-session-id: 3a1e04b75a5748ba870306c7be8f3a8e content-length: 105
and my logs seem to just stop. WHereas before when the UI wasnt working, the logs seemed continuous.
But now they dont show errors, but they seem suspiciously short/quiet
docker logs archon-ui
[email protected] dev npx vite
VITE v5.4.19 ready in 409 ms
➜ Local: http://localhost:3737/ ➜ Network: http://172.22.0.10:3737/
Hey @moshin34 - could you share the logs of your Archon-Server and Archon-MCP containers?
Hello I found that already having an Environment Variable OPENAI_API_KEY set to a value that didn't start "sk-xxxxxxx etc" caused the server to take this value on the docker build and break the setting environment from starting up. Instead of removing this Env Var I updated it to contain the correct key. Rebuilt the docker and this fixed my issue.
hey @coleam00 thanks for the reply and all your hard work on this project.
I actually nuked that whole setup, and was able to "Resolve" this pop issue by creating an entirely new supabase project (the wipe dbase setup dbase script routine didnt work) But now I have other issues (also logged here) with MCP, and the logs don't show errors, but seem..... quiet. Too quiet.
Anyhow, back to this issue, I do have some logs I saved, so I will share those with hopes they might be helpful.
Note: I was running the containers on a separate host on the LAN, not on the localhost.
archon-agents_logs.txt archon-mcp_logs.txt archon-server_logs.txt archon-ui_logs.txt
Similar issue here - even with a freshly-created Supabase project with the migrations run, and a fresh clone and build of archon, I get constant disconnects and "Backend Service Startup Failure" errors.
Looking at reports in the Supabase WebUI, the only response error I'm seeing is a 404 at /rest/v1/archon_settings?select=*. All other API Gateway requests show successful.
The primary problem in the logs is a recurring pattern where a connection is established and then immediately closed by the underlying server (Uvicorn), while the Socket.IO layer only registers the disconnect much later.
Observe this sequence for the second session:
# 20:31:51 - Connection is established successfully
INFO: 172.20.0.3:46798 - "WebSocket /socket.io/..." [accepted]
INFO: connection open
...
INFO: Client KxSx6LhggghEh42LAAAD joined chat room ...
# Immediately after joining, the connection is closed
INFO: connection closed
# 20:32:08 - 17 seconds later, Socket.IO realizes the client is gone
INFO: 🔌 [SOCKETIO] Client disconnected: KxSx6LhggghEh42LAAAD...
This pattern repeats for almost every session in the log.
What this means: The connection open and connection closed logs come from Uvicorn, the web server. The [SOCKETIO] Client connected/disconnected logs come from the Socket.IO library.
The disconnect: The server is terminating the raw WebSocket connection moments after it's made. The Socket.IO application layer doesn't know this until a timeout or heartbeat fails, which is why the official [SOCKETIO] Client disconnected message appears many seconds later. This could be caused by an issue in the application's handshake/setup logic, a middleware problem, or a proxy/load balancer configuration that is prematurely closing connections.
I am also having this issue.
Claude Code fixed it and a few other errors and submitted a pull request to you @coleam00 -
https://github.com/coleam00/Archon/pull/565
i encountered this issue as well. my setup: archon running on headless docker server at 192.168.1.10.
resolved the issue with the following in the .env:
HOST=192.168.1.10
and leaving
VITE_ALLOWED_HOSTS=
make sure you run
docker compose down && docker compose up --build -d
after making changes.
I have tried using my personal laptop, and everything is working fine. However, with the office-provided laptop, I am encountering the same issue. I believe there might be a DNS problem. I'm not sure why this is happening; it could be that some ports are being blocked silently.
I'm excited to share that adding DNS settings in Docker resolved the issue. There's no need to proceed with a headless Docker setup. Please follow the guide below.
Fix: Add reliable DNS in Docker Desktop (Windows/macOS)
Why this matters: Every Docker container asks a tiny internal resolver (127.0.0.11) to translate names like abc.supabase.co into IP addresses. That resolver forwards the request to whatever DNS servers Docker Desktop is configured to use. If those servers are unreachable (VPN policy, corporate filters, flaky router), your app inside the container can’t find supabase.co and crashes with errors like:
[Errno -2] Name or service not known httpx.ConnectError: Name or service not known
The fix is simply to tell Docker which DNS servers to use.
Step-by-step (with context)
Open the Docker Engine JSON editor
Docker Desktop → Settings → Docker Engine (left sidebar).
This screen shows Docker’s low-level config as JSON. You’ll edit it directly.
Add the dns section You’ll insert a small list of DNS servers Docker should use for all containers. Example (safe defaults using Cloudflare + Google):
{ "builder": { "gc": { "defaultKeepStorage": "20GB", "enabled": true } }, "experimental": false, "dns": [ "1.1.1.1", "8.8.8.8" ] }
Tips while editing JSON (to avoid “failed to parse” errors):
Keep commas exactly right—no trailing comma after the last item.
If your file already has other keys, just add "dns": [...] alongside them.
If you mess up, Docker will refuse to restart; just fix the JSON and apply again.
Which DNS should I use?
1.1.1.1 → Cloudflare DNS (fast, privacy-focused)
8.8.8.8 → Google DNS (reliable, everywhere)
On corporate networks that block external DNS: use your company DNS IP instead.
Find it in PowerShell:
Get-DnsClientServerAddress
Pick the IPv4 address you normally use on your PC (often something like 192.168.x.x) and put that in the list.
Apply & restart Docker Click Apply & Restart. Docker Desktop will restart with your new DNS settings. (If you use WSL2 on Windows and something still feels stuck, you can also run wsl --shutdown in PowerShell to fully reset the WSL network, then reopen Docker Desktop.)
Rebuild and restart Archon (what each command does)
After Docker comes back up, recreate your containers so they inherit the new DNS:
docker compose down
Stops and removes the containers/networks so you start clean.
docker compose up -d --build
Rebuilds images if needed and starts everything in the background (-d).
docker compose logs -f archon-server
Streams live logs so you can watch Archon finish its startup.
You should no longer see the “Name or service not known” error.
hi.
update this script in the docker.
{ "builder": { "gc": { "defaultKeepStorage": "20GB", "enabled": true } }, "experimental": false, "dns": [ "1.1.1.1", "8.8.8.8" ] } then use the following in archon root path with powershell
git pull
then
docker compose up -d --build [image: image.png]
its should work after this
On Fri, Sep 5, 2025 at 3:32 PM Hyunsung Kim @.***> wrote:
hysuki left a comment (coleam00/Archon#485) https://github.com/coleam00/Archon/issues/485#issuecomment-3258031390
i have same issue, image.png (view on web) https://github.com/user-attachments/assets/fabe7d75-45f9-4420-b279-05c881187a2e image.png (view on web) https://github.com/user-attachments/assets/f35e8bc6-e7cd-4360-9355-be6f28d7d661
— Reply to this email directly, view it on GitHub https://github.com/coleam00/Archon/issues/485#issuecomment-3258031390, or unsubscribe https://github.com/notifications/unsubscribe-auth/BV7SOO7XEJBSN7Q2CQTFOU33RFYFJAVCNFSM6AAAAACEZK2B2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENJYGAZTCMZZGA . You are receiving this because you commented.Message ID: @.***>