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 (with their embedded traces), memory, skills, preferences, auto-mode state, usage counters — all lives on the workspace volume, so it survives restarts as long as the volume is still mounted.

Scheduled goals are handled by a single catch-up: a schedule whose nextExecutionAt is already in the past when the bot comes back up fires once on the next tick, then recomputes the next time from the cron. Multiple missed triggers during a long outage collapse into that one catch-up; the scheduler does not replay each skipped slot.

Rotate it in Settings → LLM Providers. Paste the new key and save — the runtime writes it into preferences/llm.json under providers and uses it on the next turn. You do not need to restart.

In-flight turns keep using the old key because their provider client was already initialized with it. They only pick the new key up on their next turn, so plan the rotation window accordingly if you are retiring the old key in the provider console.

Back up the workspace volume. That is the whole answer —sessions/ (turn transcripts plus their embedded traces), memory/, skills/, preferences/, auto/ (goals, tasks, schedules), usage/, and automation/ (delayed actions) 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.

Yes. The runtime does not track key ownership — two containers can point at the same provider key without knowing about each other. The caveats are on the provider side, not the runtime side:

• Rate limits and quotas are combined. A spike on one runtime throttles the other.
• Spend reports in the provider console are aggregated under one account — you lose per-runtime attribution.
• If you revoke the shared key, both runtimes stop making model calls at the same time.

No. The workspace is not designed for concurrent writers. Two runtimes pointing at the same volume will race on session files, memory records, preferences, and auto-mode state — corruption is a matter of when, not if.

If you need two runtimes, give each one its own workspace volume. They can still share a provider key and reach each other over HTTP (webhooks) if something needs to cross between them.

A fast SSD is strongly preferred. The runtime writes sessions 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 slow writes at the end of each turn.

Disk capacity is driven by sessions — each turn carries an embedded trace with tool and LLM payloads, and that is where the bytes go. If sessions grow too large, shrink the per-session trace budget in Settings → Tracing: sessionTraceBudgetMb caps the total bytes per session, and payloadSnapshotsEnabled controls whether full tool/LLM payloads are captured at all.

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. On first boot — when preferences/admin-credentials.json does not yet exist — the bot generates a random admin password and prints it to the logs. It then hashes it and persists it, so it stays valid until you change it. If that line leaked anywhere (CI logs, shared terminals, screen recordings), treat the dashboard as compromised.

Two ways to avoid that risk:

• Change it in the dashboard as soon as you log in for the first time.
• Preseed it at container start with BOT_DASHBOARD_ADMIN_PASSWORD (or the Spring property bot.dashboard.admin-password). With that set, the generated line never appears in the logs.