TVTenvyrDocs
Fleet deployment

Mass deployment

Roll Tenvyr agents out safely across a fleet with staged packages and one-use host enrollment.

Tenvyr's agent is designed for broad software distribution and controlled per-host enrollment. The package may be staged across the fleet, but each machine must enroll with its own short-lived, single-use token.

Rollout model

Use four phases:

PhaseScopeExit condition
LabDisposable systemsInstall, enroll, access, rollback, and removal pass
CanaryA few systems per OS and network zoneNo SSH or agent-plane regressions
WaveA bounded production groupHealth and access metrics remain normal
FleetRemaining approved scopeOwnership transfers to normal operations

Create host groups that reflect trust boundaries, not merely software rollout batches. Each host group has independent CA material and policy scope.

1. Prepare the fleet

Before changing hosts:

  • verify supported operating-system and OpenSSH versions;
  • confirm outbound HTTPS to agents.tenvyr.com;
  • confirm administrators retain an independent emergency path;
  • capture sshd -t or the platform equivalent;
  • back up the SSH server configuration and authorized-keys state;
  • decide who owns failed enrollments, rollback, and after-hours incidents; and
  • define canary and halt thresholds.

Package verification must happen before installation. Obtain release artifacts and checksums from the controlled release channel used for your Tenvyr pilot.

2. Stage the package

Use your normal software-distribution system to place the signed Tenvyr package on every target:

  • Linux: apt, rpm, Ansible, Puppet, Chef, Salt, or an equivalent;
  • macOS: MDM, a signed .pkg, or a managed software catalog;
  • Windows: Intune, Configuration Manager, Group Policy, or another enterprise deployment system.

Staging should install the executable and service definition without embedding an enrollment token. Keep the service stopped until the host-specific enrollment step.

3. Create host groups and policies

In Tenvyr:

  1. create the tenant project and host groups;
  2. choose names and labels that match inventory records;
  3. attach the intended access policies and privilege profiles;
  4. configure owners and reviewers; and
  5. record which deployment wave maps to each host group.

Moving a host across a trust boundary later should be treated as a controlled re-enrollment, not a cosmetic label change.

4. Enroll each host

A Tenvyr owner or administrator with recent MFA creates a one-use token for a specific host group. The token is shown once and expires after ten minutes.

For each machine:

  1. create a unique token immediately before enrollment;
  2. transfer it through a protected host-specific channel;
  3. write it to a root/administrator-only file;
  4. run the agent's one-time enrollment;
  5. verify the durable mTLS identity and reported host keys; and
  6. securely remove the transferred token material.

See Enroll a host for the exact endpoint and Linux command.

The current product deliberately requires an interactive privileged operator to mint host tokens. A fleet-wide service-account API for unattended token issuance is not part of the supported workflow. Plan wave staffing and ten-minute token windows accordingly.

5. Start reconciliation

After enrollment:

  1. start and enable the Tenvyr agent service;
  2. confirm its heartbeat in Tenvyr;
  3. confirm it reports expected OpenSSH host keys;
  4. apply a minimal desired state;
  5. validate the generated SSH configuration before reload; and
  6. make a real SSH connection using a pilot access grant.

The agent makes outbound connections to the Tenvyr agent plane. No inbound management port is required.

6. Advance or halt a wave

Advance only when:

  • all hosts have a healthy agent identity and heartbeat;
  • OpenSSH configuration validation succeeds;
  • expected users can connect and unauthorized users cannot;
  • independent administrator access still works;
  • audit events arrive; and
  • rollback was tested on at least one representative host.

Halt when host identity, SSH validation, authentication, or emergency access deviates from the plan. Do not normalize a failed canary as an installation exception.

Automation pattern

Separate fleet automation into two jobs:

Reusable job: verify package → install files → keep service stopped
Per-host job: receive unique token → enroll once → validate → start service

This keeps broadly distributed configuration non-secret and limits a captured enrollment credential to one host group, one use, and a short window.

Track each wave

Record:

  • package version and checksum;
  • host inventory ID and Tenvyr host ID;
  • target host group;
  • token issue and enrollment time (never the token value);
  • validation results;
  • operator or automation run ID; and
  • rollback or exception outcome.

On this page