Brand new docker install, web interface returns 'Connection reset by peer' despite no errors in the gateway

[jerkstorecaller]

What I did:

1. Clone the repo
2. git checkout v0.2.2 (latest as of writing)
3. Edited docker-compose.yml just to add 'user: 1000:1000' and change the volume to './nanobot-data:/home/nanobot/.nanobot' so I don't have permission issues in my backups
4. 'docker compose up' until it built then CTRL+C
5. docker compose run --rm nanobot-cli onboard
6. Edited the generated config.json from step 5 to add local llama.cpp custom provider and model. Just the basic stuff from https://github.com/HKUDS/nanobot/blob/main/docs/providers.md#vllm-or-other-local-openai-compatible-server to add Gemma 4.

Then I launch it as shown below, but I can't open http://ip-of-desktop:8765 with Firefox.

test commands on the host:

$ docker compose up nanobot-gateway
Attaching to nanobot-gateway
nanobot-gateway  | Starting nanobot gateway version 0.2.2 on port 18790...
nanobot-gateway  | 2026-07-21 02:01:38 | INFO  | - | Runtime model switched for next turn: gemma-4-12b-it -> gemma-4-12b-it
nanobot-gateway  | 2026-07-21 02:01:38 | INFO  | - | Registered 19 tools: ['apply_patch', 'run_cli_app', 'complete_goal', 'cron', 'edit_file', 'exec', 'find_files', 'grep', 'list_dir', 'list_exec_sessions', 'long_task', 'message', 'read_file', 'spawn', 'web_fetch', 'web_search', 'write_file', 'write_stdin', 'my']
nanobot-gateway  | Warning: No channels enabled
nanobot-gateway  | ✓ Cron: 2 scheduled jobs
nanobot-gateway  | ✓ Heartbeat: every 1800s
nanobot-gateway  | 2026-07-21 02:01:38 | INFO  | - | Cron: registered system job 'dream' (dream)
nanobot-gateway  | ✓ Dream: every 2h
nanobot-gateway  | 2026-07-21 02:01:38 | INFO  | - | Cron: registered system job 'heartbeat' (heartbeat)
nanobot-gateway  | 2026-07-21 02:01:38 | INFO  | - | Cron service started with 2 jobs
nanobot-gateway  | 2026-07-21 02:01:38 | INFO  | - | Agent loop started
nanobot-gateway  | 2026-07-21 02:01:38 | WARNING | - | No channels enabled
nanobot-gateway  | ✓ Health endpoint: http://127.0.0.1:18790/health
<NO FURTHER LOGS EVER AGAIN>

$ docker ps
CONTAINER ID   IMAGE                     COMMAND                  CREATED          STATUS          PORTS                                                                                          NAMES
27a90821c743   nanobot-nanobot-gateway   "entrypoint.sh gatew…"   45 minutes ago   Up 55 seconds   0.0.0.0:8765->8765/tcp, [::]:8765->8765/tcp, 0.0.0.0:18790->18790/tcp, [::]:18790->18790/tcp   nanobot-gateway

$ curl http://localhost:8765
curl: (56) Recv failure: Connection reset by peer

There are no errors appearing in the nanobot-gateway docker logs. Nothing added, in fact.

I also ran the following commands inside the container:

$ docker exec -it nanobot-gateway bash

I have no name!@27a90821c743:/app$ curl http://localhost:8765
curl: (7) Failed to connect to localhost port 8765 after 0 ms: Couldn't connect to server

I have no name!@27a90821c743:/app$ curl http://localhost:18790/health
{"status": "ok"}

Since a curl to localhost:8765 from inside the container fails, then that's clearly a a Nanobot bug, right?

[darekwojciechowski]

Not a bug — nothing is listening on 8765. Your log already says it:

Warning: No channels enabled

The WebUI is served by the websocket channel, not the gateway. 18790 answers because that's the health endpoint. With no channel enabled, nothing binds 8765, so Docker accepts the connection on the host, finds no backend, and resets it.

There's a second trap right behind it: the channel defaults to host 127.0.0.1, which inside a container means the container itself. Set both in your config.json:

{
  "channels": {
    "websocket": {
      "enabled": true,
      "host": "0.0.0.0",
      "port": 8765,
      "tokenIssueSecret": "long-random-string",
      "websocketRequiresToken": true
    }
  }
}

Restart and you should see WebSocket server listening on ws://0.0.0.0:8765/.

Heads up: the shipped compose publishes 8765 to all interfaces, so once you set 0.0.0.0 your whole LAN can reach the UI. Keep the token on and make the secret a real random one (openssl rand -hex 32).

[jerkstorecaller]

Thanks.

Shouldn't something like this be in the README's Quick Start? Part 2 (Configure) doesn't mention that websocket channel needs to be enabled, it only covers LLM providers. Then it goes straight to part 3, 'open the WebUI' like it's no biggie. So the README is giving a non-working path.

Oh, and after I enabled websocket, I got this (and fixed it already):

nanobot-gateway  | 2026-07-21 18:20:56 | WARNING | - | websocket channel not available: 1 validation error for WebSocketConfig
nanobot-gateway  |   Value error, host is 0.0.0.0 (all interfaces) but neither token nor token_issue_secret is set — set one to prevent unauthenticated access [type=value_error, input_value={'enabled': True, 'host':...': '', 'sslKeyfile': ''}, input_type=dict]

This is mentioned later in the README as a footnote in the WebUI doc, but it should be part of the Quick Start config.

If I update the README to provide the correct list of steps in the Quick Start, are you open to a PR? The idea is to explain both paths: localhost, and having to set a token if they want LAN access. I'm asking first because I'm intimidated by the 600 open PRs and I will update the doc carefully so I don't want to put in the effort for nothing.

P.S. I feel it's just not intuitive that to the enable the web UI you have to enable a channel called websocket. A normal person doesn't know what websocket is, and a more techie person will assume the websocket channel is for some sort of real-time API rather than thinking this is for a web UI. I suggest the channel be renamed to 'webui', leaving 'websocket' as a backwards-compatible alias. Websocket is just a very bad name, up there with calling it 'tcp'.