Locally Hosted Honcho Failures

[fresh scarab]

Hey! I'm trying to run a locally-hosted Honcho instance, but struggling. Workspace list comes up empty after over a day of operation.

Self-hosted at http://honcho:8000 (set via /etc/hosts).

If I run with no HONCHO_API_KEY, I get no warnings/errors in log, but I get this:

nova@hermes:~/.hermes$ hermes memory status

Memory status
────────────────────────────────────────
  Built-in:  always active
  Provider:  honcho

  Plugin:    installed ✓
  Status:    not available ✗
  Missing:
    ✗ HONCHO_API_KEY  → https://app.honcho.dev

  Installed plugins:
    • byterover  (requires API key)
    • hindsight  (requires API key)
    • holographic  (local)
    • honcho  (requires API key) ← active
    • mem0  (requires API key)
    • openviking  (requires API key)
    • retaindb  (requires API key)

With a dummy API key, I get status: available in the memory command, but then also get WARNING plugins.memory.honcho: Honcho init failed: Invalid API key during gateway startup.

HONCHO_API_KEY=no-key-for-you as the dummy key in .env

{
  "base_url": "http://honcho:8000"
}

[sullen plinth]

Are you self hosting thru your system or docker?

[fresh scarab]

it's in an LXC running by itself, i use Proxmox for the host. not using docker. - and also confirmed that it can connect at least via ssh, i get responses from curl to the internal IP/hostname for it outside the agent:

$ curl -X POST http://honcho:8000/v3/workspaces/list
{"items":[],"total":0,"page":1,"size":50,"pages":0}

[simple prairie]

{
"hosts": {
"hermes": {
"peerName": "chmfar",
"workspace": "hermes",
"aiPeer": "hermes",
"memoryMode": "hybrid",
"writeFrequency": "async",
"recallMode": "hybrid",
"sessionStrategy": "per-directory",
"enabled": true,
"saveMessages": true
}
},
"baseUrl": "http://localhost:8000"
}

use peer name according to your peer

this is json file path is

/home/chmfar/.honcho/config.jso

according to my system

i deploy it in docker

[fresh scarab]

and you have visible data in yours? interesting. that looks like the honcho.json from the original honcho memory setup command before the memory changes

i have no ~/.honcho let alone contents, unusual. - mine stored in ~/.hermes/honcho.json

[simple prairie]

yes .

i didnt run honcho memory setup

just put files manually in above said folder

and then run honcho status

you just run pre flight command at very first hermes honcho setup

[fresh scarab]

i'll have to do that then try this again to verify, idk how else to view data on honcho besides seeing that the workspace exists 🤣

[simple prairie]

here is my status report

Honcho status
????????????????????????????????????????
Host: hermes
Enabled: True
API key: not set
Workspace: hermes
Config path: /home/chmfar/.honcho/config.json
Write path: /home/chmfar/.hermes/honcho.json (instance-local)
AI peer: hermes
User peer: chmfar
Session key: honcho
Recall mode: hybrid
Memory mode: hybrid
Write freq: async

Connection... OK

[fresh scarab]

what command brings that up?

[simple prairie]

simple
hermes honcho status

but orignal repo has a one flaw which i face and dosent works

so i made a helper script because orignal repo clone dosent works the deriver container

will give you errors if you check logs

you also need to run these commands too in folder where you clone the repo

mkdir -p grafana-data
sudo chown -R 472:472 grafana-data
sudo chmod -R 755 grafana-data
sudo chmod o+w grafana-data

mkdir -p traces metrics
sudo touch traces/traces.jsonl
sudo chown -R 1000:1000 traces/ metrics/
sudo chmod -R 775 traces/ metrics/
sudo chmod -R o+w traces/ metrics/

[fresh scarab]

will have to look into that once i get it working at all lol

also oh i'll just figure exporting that to my existing grafana stack 🤣 or set up alloy to do it manually

[fresh scarab]

Okay I think I might have it partially started here: Your ~/.honcho/config.json is sitting for me at ~/.hermes/honcho.json and now I get this:

$ hermes honcho status

Honcho status
────────────────────────────────────────
  Host:           hermes
  Enabled:        True
  API key:        not set
  Workspace:      hermes
  Config path:    /home/nova/.hermes/honcho.json
  AI peer:        nova
  User peer:      ivanov
  Session key:    .hermes
  Recall mode:    hybrid
  Memory mode:    hybrid
  Write freq:     async

  Connection... OK

  No peer data yet (accumulates after first conversation)

Also should note that hermes honcho setup used to populate this properly pre-refactor, but had other now-fixed bugs. now just seems like the opposite, hermes honcho setup now just calls hermes memory setup instead, and the Honcho part of that new command apparently does not populate the .json fully anymore, it only gives the very small json snippet i posted in my original post 🤣

the fix was manually populating ~/.hermes/honcho.json and making sure not to specify HONCHO_API_KEY anywhere. i might have more self-hosted issues though but this seems to be the main one down.

[simple prairie]

you made it

[glad rampart]

yo @oak hedge

[fresh scarab]

i have not tested that it's working since my "connection OK" yet - i was busy getting the local infra back online 🤣

[oak hedge]

yeah definitely has some issues from the migration i have a PR in the works to resolve my findings from being ported to a plugin . working on it! amazing feedback

[fresh scarab]

glad i can be useful 😄 i run 100% local and thats where 80% of my issues end up being

[oak hedge]

opinions on preferred method for the setup CLI ? trying to figure out how to consolidate the paths

[fresh scarab]

the original hermes honcho setup asked for these variables as part of setup, can just include that as part of the updated hermes memory setup when asking for the api key+base url already as part of honcho onboarding there.

so 7 questions instead of 2 basically, but it populates fully with sane defaults if you just mash enter 🤣 (or however many, i didnt count)

[oak hedge]

yeah and then keep legacy CLI. maybe we enter local for api key value so it overrides and has hardening against that blank api key value bug from ever cropping up

[fresh scarab]

yes! or ask for base URL first, if it's specified then ask API key after and assume not necessary - currently its "API key, base URL" in order

[oak hedge]

genius

[fresh scarab]

the trick is HONCHO_API_KEY can not be specified unless its needed, honcho fails to connect if its specified even if the base url is set to local - but unfortunately some users might still set an API key for their local setup and require auth, so we can't just remove it entirely

the fix was both populating the .json and not providing an API key in my case, because i don't use one on the honcho side

[oak hedge]

thanks for your help, been fighting my llm psychosis to follow all these dev changes at tekniums lightning pace

[fresh scarab]

lol just glad to have inspiration again 😄

[oak hedge]

but to be clear you have things populating your workspace now ?

[fresh scarab]

{
  "items": [
    {
      "id": "hermes",
      "metadata": {},
      "configuration": {},
      "created_at": "2026-04-03T19:54:11.336250Z"
    }
  ],
  "total": 1,
  "page": 1,
  "size": 50,
  "pages": 1
}

seems so! (that was a /v3/workspaces/list)

[oak hedge]

yay!!