Repository navigation
Roll out your team
toard has two parts: one server operated by your team and one shim on each developer machine. The server does not connect back into developer machines. Each shim sends usage to the server, so developers need access to the server address; use TLS when that path crosses an untrusted network.
- Deploy and verify the server with Quickstart or Deploying-toard.
- Share the server address and explain the collection and privacy boundaries.
- Each developer signs in.
- Each developer opens Settings → Installation & token, creates a personal ingest token, and uses the installation command generated by the server.
- Each developer runs the in-product receive check to confirm that the server accepts their collector.
- Ask developers to install the scheduled collector if they use Desktop or IDE workflows, then confirm its status with
toard-shim daemon status.
The generated installation command installs the shim, records the developer's own endpoint and token locally, and configures its path. Do not copy another person's token or paste a token into tickets, chat, or shared documentation.
The settings-page receive check is the quickest confirmation. The shim also offers local diagnostics:
toard-shim doctor
toard-shim collect --dry-run
toard-shim daemon statusUse toard-shim collect when an immediate collection is needed. The scheduled collector is not a permanently running process: the operating system launches a one-shot collection task at its configured interval.
The normal rollout collects usage metadata from local session files. It does not enable prompt or response-content collection. Make that distinction clear before asking people to install the shim.
Content collection is separate and defaults to individual opt-in. It needs server-side encryption configuration. An organization can deliberately use CONTENT_COLLECTION_DEFAULT=on to offer opt-out collection during installation, but should review and communicate that policy before doing so. Do not enable content collection as part of a standard rollout without reviewing Privacy-and-security and your organization's policy.
The shim can report a device label for a user's own device breakdown. Developers can choose an alias or turn that label off if a hostname is sensitive. Token authentication remains the source of identity.
Revoke or rotate an ingest token when its owner changes, a device is lost, or exposure is suspected. Keep server credentials and user ingest tokens in an approved secret-management workflow rather than source control.
Standardize on local session-file pull collection for new rollouts. OTLP push is experimental and should only be evaluated deliberately with the required experimental and server-side configuration; do not run it alongside pull for the same provider.
- Need a deployment platform decision? Read Deploying-toard.
- Need collection details or daemon behavior? See the shim README.
- Need privacy and security guidance? Read Privacy-and-security.