Persistent storage and secrets#
Public installations store non-secret launcher configuration in the platform installation root. Application state lives in persistent Docker volumes and data locations managed by the stack; registered host workspaces remain host directories.
Provider API keys use restrictive local secret files and allowed imports to CLI state. OAuth/device state lives in the provider volume. The application core does not mount the raw provider-key directory or provider-state volume; CLI operations cross a protected channel.
Do not confuse this separation with protection from a malicious host administrator. The owner controls the host and Docker. A registered writable workspace grants meaningful filesystem authority to provider tools.
Portable backup includes database, application data, owner memory and integrity metadata. It excludes API-key files, OAuth/device provider state, host workspace contents and browser profiles. Backups themselves can contain sensitive owner/application content.
Authentication and trust model#
The public deployment targets one trusted owner operating one self-hosted instance. It is not documented as tenant isolation for mutually untrusted customers or a managed SaaS control plane.
Default protections include loopback binding, a hashed expiring one-time setup claim, no production default password, explicit workspace registration, separate provider state and no automatic Docker-socket mount into application containers.
Browser clients authenticate to the app. Provider CLIs authenticate to their respective services. Workspace access, tool permissions and external account scopes are separate authorizations; one successful login does not grant all of them.
Host-root mode, where supported and explicitly chosen, exposes the host filesystem with powerful write authority. It is not a resource profile or a stronger sandbox. Containerization alone does not make untrusted commands harmless when host directories are writable.
Repository instructions, pages, screenshots, model output, tool responses and memory content are untrusted data relative to the owner's instructions and runtime policy. They cannot authorize secret disclosure or privileged operations.
Network exposure and privacy#
The default address is http://127.0.0.1:4911. A remote device needs an owner-configured reachable address through an appropriately secured connection. Owners exposing the app are responsible for TLS, firewall/access policy, trusted proxy configuration, updates, backups and retention.
Use only documented configuration mechanisms for the installed release. Never invent a bind flag or expose a service on every interface as a casual troubleshooting step.
Outbound traffic can include registry/package downloads, provider requests, connected integrations and optional/configurable installer telemetry. Self-hosted is not synonymous with air-gapped. Inspect model and tool destinations before processing sensitive input.