Torii's AI Telemetry page exposes three ways to wire up token tracking. They are not interchangeable - pick based on how your fleet is managed and whether you already have an observability pipeline.
TL;DR - which path do I pick?
| Situation | Use |
|---|---|
| You manage workstations with Jamf, Kandji, Intune, JumpCloud, Mosyle, Workspace ONE, SCCM, or any other tool that can run shell or PowerShell scripts on user machines | MDM rollout - MDM overview |
| You already run an OpenTelemetry collector (otelcol-contrib, Grafana Alloy, Datadog Agent, Splunk OTel, ADOT, or Elastic Agent) that workstations already report to | Existing OTEL collector - collector setup |
| You're piloting on a handful of machines, or you want a power user to self-install on their laptop | One-liner install - one-liner setup |
Security policy says no piped curl | bash and no MDM rollouts for new third-party scripts |
Manual config edit - manual setup |
Comparison at a glance
| MDM rollout | Existing OTEL collector | One-liner / manual | |
|---|---|---|---|
| Touches workstations? | Yes - writes settings.json or config.toml on each user's machine via MDM-run script. |
No. Workstations stay untouched. The collector you already operate adds Torii as a second destination. | Yes - same as MDM, but one machine at a time. |
| Best fleet size | 10s to 10,000s of machines. | Any size, as long as workstations already report to your collector. | 1–20 machines (pilot, demo, single power user). |
| Where the ingest token lives | As a parameter / environment variable on each MDM policy that runs the install script. | As TORII_INGEST_TOKEN in the environment of the collector host (one place). |
Passed as a flag at install time; ends up baked into the workstation's CLI config file. |
| Token rotation effort | Update the MDM parameter; the script does not need to be re-uploaded. | Update the env var on the collector host(s) and reload. | Re-run the one-liner with the new token on every machine. |
| Air-gapped fleet support | Yes - mirror the Linux helper binary internally and set HELPER_BASE_URL. (Linux only; macOS and Windows have zero downloads at install time.) |
Yes - nothing on the workstation has to reach Torii's asset host. | Same as MDM. |
How to think about it
If your engineers' workstations are MDM-managed, default to MDM rollout
The MDM path is the lowest-friction option for fleets. The install script is idempotent (safe to re-run - it converges and only writes when something changed), creates a timestamped backup before it changes anything, and touches only the Torii-owned telemetry keys, preserving everything else in the config file. Your MDM gives you the policy targeting (groups, OS, enrollment state) you already use for every other script.
This is also the right path even if you also run an OTEL collector, but workstations don't yet talk to it. Don't redirect workstation telemetry through a collector you'd then need to operate just for this - point them at Torii directly and reduce moving parts.
If workstations already report to an OTEL collector you operate, use the collector path
If you already have otelcol-contrib, Grafana Alloy, Datadog Agent, Splunk OTel, ADOT, or Elastic Agent in front of workstation telemetry, you do not want to bypass it. You also do not want to silently break it by repointing the CLI's OTLP endpoint at Torii. The collector path adds Torii as a second exporter on your existing pipeline - both your existing backend and Torii receive a copy.
One-liner is for pilots and single machines
The one-liner is the same install script the MDM path uses, fetched directly by curl or iwr at install time. It's not a different code path - it's a different way to invoke the same code. Use it for:
- A pilot on 1–20 machines before you wire up an MDM policy.
- Letting a single engineer self-install on their own laptop.
- Validating that the firewall rules to
ai-events.toriihq.comwork before kicking off a fleet rollout.
It is not the right way to do a fleet rollout. There's no targeting, no inventory, no rotation strategy.
Manual config edit is for security-restricted environments
If your security policy says no piped curl | bash and your MDM workflow requires the literal config file contents to be reviewed and shipped through a separate change management process, every install script's output is just a few lines of JSON or TOML. Article 4 covers the manual edit path and shows the exact block to paste in.
Can I mix paths?
Yes:
- One-liner pilot → MDM rollout is a normal sequence. The MDM rollout will safely re-write the config files the one-liner installed; no cleanup needed.
- MDM and one-liner simultaneously on the same machine is fine but redundant - the MDM will overwrite the one-liner install with the same content. Pick one for ongoing management.