Fleet RLM is a single-user, local-first runtime. Understand these boundaries before you expose it beyond your machine.
No caller authentication
The HTTP API doesn’t authenticate callers. Every request runs as the single local User and Workspace.
fleet web, fleet cli, and fleet-rlm serve-api bind to 127.0.0.1 by default.
- A non-loopback
--host fails with refusing to bind unauthenticated Fleet API to non-loopback host unless you pass --allow-non-loopback-bind.
- If you expose Fleet, put it behind a trusted network boundary or an authenticating reverse proxy.
Local-only settings
GET /api/settings and PATCH /api/settings accept only loopback clients. They reject any request carrying X-Forwarded-For, Forwarded, or X-Real-IP, so a local reverse proxy can’t make a remote client look local. Rejected requests get 403 with settings_local_only.
Sandbox isolation
- Model-authored code runs only in Daytona Sandboxes, never in the Fleet process.
- The Sandbox broker accepts only authenticated JSON. It fences late or duplicate tool results.
- The root Sandbox mounts only the Session Workspace. Host I/O Sandboxes that mount the whole Workspace run Fleet-authored operations only.
- Child RLM Sandboxes have no Volume, credentials, memory, task, or publication capability.
See Sandbox execution.
Secrets
config/fleet.toml holds no secrets. It names environment variables through *_env keys.
- Fleet loads secrets from the process environment or
.env. Keep .env out of version control.
- API responses for Attachments and Artifacts never include host or Volume paths.
- Trace content is bounded and sanitized. Set
mlflow.trace_content_enabled = false to keep content out of traces.
Limits
Database
Managed deployments that use the Lakebase preflight must connect as the fleet_app role over TLS. See Deploy with PostgreSQL. Last modified on September 4, 2026