Runner invites

After SSH deployment, the owner can create an invite on that runner:

ax enroll invite --node build-host --format json

The result includes an aster1 ticket, invite ID, expiry and use count. Treat the ticket as a secret. It lasts 15 minutes and admits one joining identity. JSON, CSV and TSV output use the usual global format option. A lost response does not automatically retry invitation creation.

What deployment prepares

The owner retains the root key and fleet namespace write secret. The runner receives its own root-issued credential, a bounded issuer delegation and read access to fleet policy. A root-authored binding and sealed grant authorize it to write observations into the owner's separate observations namespace.

The delegation allows persistent enrollment credentials carrying aster.exec, with no tags or attributes, at most 24 hours per credential and no further delegation. Its lifetime is seven days. The generated agent invite profile uses those scopes and persistent registration. Only the deploying caller's configured node key can request invites; being another admitted fleet member, or a user forwarded through a gateway, does not give that permission.

An existing runner keeps its identity, ceiling and owner settings. An old configuration without an issuer gains the generated issuer configuration. Conflicting issuer settings require explicit migration. Redeployment refuses to replace altered, revoked or deleted observation policy. The root's sealed grant is retained locally so a retry publishes the same record.

Installing a changed delegation restarts the API because the SDK issuer cannot reload it. Supervised jobs use separate systemd units. An installation-only upgrade does not restart the service.

Redemption and observation

Before redeeming, the joiner needs the owner's trusted root public key, audience and fleet namespace. The invite does not distribute that trust. The Aster client redeems the ticket using its own persistent identity, saves the returned credential, and enrolls with the runner. The runner records an issued observation. The credential is time-limited even though its registration intent is persistent.

New runners deployed by ax enable credential_scopes in their local ceiling. A freshly redeemed joiner can execute using its credential's Exec scopes within that ceiling, before promotion or a root grant. A root Exec grant always takes precedence when present. The core Exec configuration default remains off.

Redeployment preserves an existing runner's setting. Select a change explicitly:

ax deploy ssh user@host --credential-scopes true
ax deploy ssh user@host --credential-scopes false

These choices also apply when creating a runner. Disabling scope authorization keeps admission through credentials, but requires a root Exec grant for jobs.

Root review and registration

The deployment result identifies the observations namespace. For the selected owner profile, deployment stores its write secret in ~/.ax/deploy-bootstrap/<profile>/observations.secret and the fleet secret in the same directory as policy.secret. Do not transfer those files to joiners.

Set the variables below to the deployment namespace IDs, secret-file paths, audience and runner node ID. Keep the secrets local to the owner. Then review the runner's observations:

ax enroll review \
  --observations-namespace "$observations_id" \
  --observations-secret-file "$observations_secret_file" \
  --fleet-namespace "$fleet_id" --fleet-secret-file "$fleet_secret_file" \
  --audience "$audience" --peer "$runner_node_id"

Inspect the accepted subject, observer, issuer and claims before promotion. Synchronization alone creates no registration. Set joiner_node_id to the reviewed subject. For its first registration, use revision 1:

ax enroll promote --subject "$joiner_node_id" --revision 1 \
  --observations-namespace "$observations_id" \
  --observations-secret-file "$observations_secret_file" \
  --fleet-namespace "$fleet_id" --fleet-secret-file "$fleet_secret_file" \
  --audience "$audience" --peer "$runner_node_id"

Promotion writes a root-authored registration with no expiry, using the reviewed claims. A registration replaces credential admission evidence. The owner's Exec grant is a separate root-written decision. After registration, reconnect with the runner's address-only ticket rather than retaining the spent invite.

Owner review and promotion are explicit actions. Redemption requires a client integration that supplies the owner's trust configuration; these commands manage the owner side of that flow. For the deploying client's complete setup, use SSH deployment.