The worker is the production-shaped entrypoint for running an entity without a local terminal UI. It is what you use on Railway (and similar hosts) so Telegram, Discord, memory consolidation, and soma ticks stay online while inference may still happen on your own machine.Documentation Index
Fetch the complete documentation index at: https://docs.bumbleagi.com/llms.txt
Use this file to discover all available pages before exploring further.
Command
BUMBLEBEE_ENTITY (e.g. canary) instead of a positional argument — your start command should match how the image invokes the CLI.
What the worker runs
- Platforms from the entity YAML (
presence.platforms): e.g. Telegram and Discord when tokens/env vars are set. - Presence daemon: heartbeat (soma, MCP refresh, wake checks), memory consolidation, initiative, automations.
- No CLI platform: interactive
cliis omitted in worker mode so the process does not expect a TTY.
bumblebee run — only the CLI surface is dropped.
On Railway, the start command uses docker/entrypoint-railway.sh: a virtualenv on BUMBLEBEE_EXECUTION_WORKSPACE_DIR (typically /app/data) installs bumblebee[railway,api,full] and keeps HOME and caches on the volume so optional extras persist across deploys. See Hybrid Railway — persistent Python.
Hybrid Railway pairing
In a typical hybrid setup:| Component | Where | Role |
|---|---|---|
| Worker | Railway (or another cloud VM) | Messaging, Postgres memory, tools in-container (or via execution RPC). |
| Inference gateway | Home PC | OpenAI-compatible HTTP proxy to Ollama; reached through Cloudflare Tunnel (or similar). |
| Ollama | Home GPU | Actual models (e.g. Gemma 4). |
BUMBLEBEE_INFERENCE_PROVIDER=remote_gateway and BUMBLEBEE_INFERENCE_BASE_URL to your tunneled gateway URL; BUMBLEBEE_INFERENCE_GATEWAY_TOKEN must match INFERENCE_GATEWAY_TOKEN on the gateway host.
Optional: For hosted evaluation (OpenRouter, Venice AI), set BUMBLEBEE_INFERENCE_PROVIDER=openrouter or venice and the provider API key on the worker instead—no tunnel or gateway token. Same worker binary and harness; see Hosted inference (testing).
Details: Hybrid Railway, Gateway.
Logging
In worker mode, some libraries are configured for quieter console logging so container logs stay readable. For debugging platform or inference issues, use your host’s log stream and entity/harness log files as usual.Autonomous wake
When autonomous wake runs, the worker emits structured log events you can filter on:| Event | What it carries |
|---|---|
autonomous_wake_worker_banner | Multi-line human field: reason, channel, soma bars, GEN fragments, poker preview, stirring, session limits |
autonomous_wake | Compact summary: wake_reason, delivery_platform, channel, max_rounds, wall_seconds, wide_mode, extra_tool_steps, poker flags, soma_bars, gen_fragment_count |
autonomous_wake_round_done | Per round: tools_this_round, tools_accumulated, reply_chars |
autonomous_wake_session_end | rounds_completed, elapsed_seconds, tools_all, stopped_early |
autonomy.wake_verbose_worker_log: false in harness or entity YAML.
User-visible status lines in chat (italic in Telegram, etc.) are controlled separately by autonomy.wake_user_visible_status.
API service (separate role)
bumblebee api is a small HTTP health service, not the message worker. Railway deployments often use BUMBLEBEE_RAILWAY_ROLE (or equivalent) so one service runs worker and another runs api. They share the same repo and config story but different processes.