FAQ

In-flight turns are lost. The runtime does not checkpoint mid-turn. When you restart the container, any session that was waiting on a model response or a tool call drops the response. The session itself persists — you just need to resend the last prompt.

Persistent state (sessions, memory, skills, traces, preferences) is all on the workspace volume, so it survives restarts as long as the volume is still mounted. Scheduled goals pick up from their next trigger; they do not retry a missed trigger automatically.

Edit preferences/llm-providers.json through the dashboard (Settings → Providers). The change takes effect for the next turn — you do not need to restart. Running turns keep using the old key because the client was initialized with it.

If you rotate outside the dashboard, reload the provider config:

docker exec golemcore-bot curl -sS -X POST \
  http://localhost:8080/api/admin/reload-providers

{"ok":true,"providers":["anthropic","openai"]}

Back up the workspace volume. That is the whole answer — sessions, preferences, skills, memory, and traces all live there. Nothing in the container image or ephemeral filesystem needs backing up.

• Docker named volume: back up with docker run --rm -v golemcore-bot-data:/data -v $(pwd):/backup alpine tar czf /backup/workspace.tgz /data.
• Host bind mount: snapshot or rsync the host directory; the runtime does not need to be stopped for a consistent enough copy for most use cases, but stopping briefly gives you a guaranteed-consistent snapshot.
• Sandbox volume: treat it as scratch. If you cannot reproduce its contents from the workspace and your tools, that is a bug in your setup.

Technically yes, operationally no. Two runtimes can point at the same provider key, but they will race on memory writes and trace files if they also share the same workspace volume. If you need two runtimes, give each one its own workspace and let Hive (or a message bus) coordinate anything that needs to be consistent between them.

Sharing a provider key between separate runtimes is fine as long as you are comfortable with the combined rate limits and the combined spend appearing under one account.

A fast SSD is strongly preferred. The runtime writes traces and memory records frequently; on spinning disks the write amplification becomes visible in turn latency. In practice:

• Production: NVMe or at minimum SATA SSD.
• Development: whatever your laptop has.
• Network storage: acceptable if latency stays under a few milliseconds; otherwise you will see slow session loads and delayed trace writes.

Disk capacity is driven by traces more than anything else. Plan for a few hundred megabytes per month of active use and adjust retention in preferences/runtime-config.json if that is too much.

Not by default. Exposing port 8080 publicly puts the admin login and every session directly on the internet. Front the dashboard with a reverse proxy that terminates TLS and, if possible, enforces an IP allowlist or SSO. See the production checklist in the Deployment page.

No. The initial password printed to the logs is a one-time value for bootstrap. Rotate it immediately in Settings → Security, or preseed a known password with BOT_DASHBOARD_ADMIN_PASSWORD at container start so the logged value never leaves memory.