The hybrid deployment splits the stack: inference stays on your home GPU (Ollama + gateway + Cloudflare Tunnel), while the entity worker runs on Railway with Postgres for durable memory.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.
Architecture
The hybrid stack splits across two hosts:| Home PC | Railway |
|---|---|
| Ollama (Gemma 4) | Bumblebee worker |
| Inference Gateway | Telegram / Discord |
| Cloudflare Tunnel | Postgres (memory) |
Volume (/app/data) |
Optional: For product-style harness testing with hosted frontier models (OpenRouter, Venice AI) instead of the home gateway, use
BUMBLEBEE_INFERENCE_PROVIDER=openrouter or venice and set the matching API key on the worker. Same codebase and license story; see Hosted inference (testing).Setup wizard
.env, gateway token, optional automated Cloudflare Tunnel + DNS, optional home stack start, health checks, entity selection, and Railway variables / volume / deploy.
For the gateway piece only:
Manual setup
Home side
- Set the gateway token in
.env:
-
Configure and start the Cloudflare Tunnel pointing at your gateway (default
127.0.0.1:8010). - Start the home stack:
scripts/gateway.ps1; on macOS and Linux it runs scripts/gateway.sh. See Gateway for dependencies (curl, cloudflared, Ollama, correct Python).
Railway side
- Link the repo:
- Set environment variables on the worker service.
BUMBLEBEE_INFERENCE_PROVIDER=openrouter, OPENROUTER_API_KEY=..., and BUMBLEBEE_INFERENCE_PASS_NUM_CTX=false. Full detail: Hosted inference (testing).
- Deploy:
Execution
Shell, filesystem, and code tools execute in the Railway container by default (whenRAILWAY_ENVIRONMENT is set).
| Scenario | Where tools run |
|---|---|
| On Railway, no RPC URL | In the container |
| On Railway, with RPC URL | RPC host (falls back to container if unreachable) |
| On your laptop, hybrid mode | Blocked unless tools.execution.allow_local: true |
Docker
TheDockerfile copies canary.example.yaml to canary.yaml in the image, so BUMBLEBEE_ENTITY=canary works without committing local YAML. The railway.json start command auto-selects worker or API role based on BUMBLEBEE_RAILWAY_ROLE.
Persistent Python environment on the volume
The worker and API processes do not rely only on packages baked into the image layer. At startup,docker/entrypoint-railway.sh:
- Uses
BUMBLEBEE_EXECUTION_WORKSPACE_DIR(default/app/dataif unset) as the mount where the “canonical machine” lives. - Creates
$WORKSPACE/.venvand installs/app[railway,api,full]into that venv whenpyproject.tomlchanges (SHA stamp in.venv/.pyproject_sha). - Sets
HOMEto$WORKSPACE/.home,PIP_CACHE_DIR,XDG_CACHE_HOME, andPLAYWRIGHT_BROWSERS_PATHunder the volume so optional extras and browser binaries survive redeploys as long as the volume is attached.
BUMBLEBEE_EXECUTION_WORKSPACE_DIR=/app/data on the service (see setup wizard). The image still contains a bootstrap install for debugging; set BUMBLEBEE_SKIP_VOLUME_VENV=1 to run with the image Python only.
Install-time extras in pyproject.toml (full = voice, PDF, YouTube, Playwright, fal, plus railway and api) are therefore available and persistent on the volume-backed venv, not only in the ephemeral container root.