> ## 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.

# Worker runtime

> Headless `bumblebee worker` — platforms and daemon without the CLI.

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.

## Command

```bash theme={null}
bumblebee worker <entity>
```

On Railway, the entity name usually comes from **`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 `cli` is omitted in worker mode so the process does not expect a TTY.

Inference, tools, and memory behave like a normal `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](/deployment/hybrid-railway#persistent-python-environment-on-the-volume).

## 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).                                                           |

The worker sets **`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)](/deployment/hosted-inference-testing).

Details: [Hybrid Railway](/deployment/hybrid-railway), [Gateway](/deployment/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](/architecture/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`                                                                                                           |

If JSON logging is enabled, these fields are queryable in your log stack. Disable the large banner with `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.