For organisations

Everything else in these pages works a developer at a time. This is for rolling Otōto out to many machines, and it is all in the open-source Otōto: there is no other edition.

One settings file for everyone on a machine

/etc/ototo/config.toml (/Library/Application Support/Ototo/config.toml on macOS; OTOTO_SYSTEM_CONFIG moves it) sits under each user’s own ~/.config/ototo/config.toml. Its settings apply where a user’s file and environment say nothing, and the ones it lists in enforced apply whatever they say.

enforced = ["otlp_endpoint", "otlp_attributes", "plugin_signers", "allow_unsigned_plugins", "endpoints"]
otlp_endpoint = "http://collector.corp:4318"
otlp_attributes = "team=platform"
plugin_signers = "allowed_signers"   # relative paths are beside this file

[[endpoints]]
name = "gpu"
base_url = "https://gpu.corp/v1"
model = "Qwen/Qwen3.8-27B"

The file should belong to root and be writable by no one else, or anyone could change what it enforces. ototo doctor checks that, shows what is enforced, and says when a user’s own setting is overridden.

Code goes only to your model servers

With endpoints enforced, the organisation’s model servers are the only ones: a user cannot add another, the Claude Haiku fallback included, and ototo init will not set one. The server itself is vLLM’s page.

Your plugins, and whose signatures count

Beside the settings file, plugins/ holds the organisation’s plugins and allowed_signers the keys it trusts to sign them. Both are used alongside a user’s own, unless plugins or plugin_signers is enforced: then only the organisation’s are. Writing a plugin says how one is made and signed.

Rolling it out

ototo managed writes what to push to every machine with whatever you push settings with (MDM, Ansible, a golden image):

ototo managed --out ototo-managed --collector http://collector.corp:4318 --team platform \
  --base-url https://gpu.corp/v1 --model Qwen/Qwen3.8-27B

• Claude Code’s managed-settings.json: Otōto’s permissions and hooks for every user, above anything a user or a project sets; with --collector, Claude Code’s own telemetry to the same collector with the same team label.
• managed-mcp.json: the ototo server, registered for every user.
• The organisation’s config.toml and allowed_signers.
• A README of where each goes on macOS and on Linux.

--install writes them into this machine’s system locations instead, merged into managed settings already there and backed up. With --base-url the organisation’s servers become the only ones; --allow-user-endpoints lets users add their own. On a managed machine ototo init adds nothing a user would duplicate, and ototo doctor says the setup comes from the organisation.

Somewhere for the counts to go

--collector wants an OpenTelemetry collector. If you have none, the hub is one to run: a collector, Prometheus and Grafana with two dashboards, usage and savings by person and team, and which Otōto servers are running, on what version. It comes as a compose file, a Helm chart and kustomize manifests, in the source’s deploy/.

Updates from your own channel, and the oldest version you accept

• update_url points ototo update at a mirror of the download channel that you host, in place of https://ototo.sh/beta. A release is checked against Otōto’s release key wherever it was fetched from.
• min_version = "2026.18" is the oldest Otōto the organisation accepts: ototo doctor fails on an older one and says ototo update. Nothing is asked of anyone for it and nothing stops working: it is the check a rollout’s script or a fleet’s dashboard reads. ototo doctor also says which sessions are still running the Otōto that was there before the last update.

What is reported, and to whom

Point otlp_endpoint at the collector you already run: Metrics lists every count, and that nothing else leaves the machine. Each running server also reports what it is (ototo.server), so a dashboard can show who is running which version.

For a security review

SECURITY.md covers what runs, what it reads and writes, what leaves the machine, the plugin sandbox and signing, and releases. Every package carries sbom.cdx.json, a CycloneDX bill of materials of every dependency with its licence. Releases are built in the open pipeline, signed, and can be rebuilt to the same bytes: dist/reproduce.sh.