Skip to content

Enrollment

Enrollment is how a robot proves its identity once and then talks to the cloud over mutual TLS (mTLS). It happens automatically as part of the bootstrap command — there is no separate enrollment step to run.

How the flow works

When you add a robot in the web app, you get a single-use bootstrap command. Running it on the robot performs enrollment as part of the install:

  1. Run the bootstrap command on the robot. It sets up the service user, directories, and the systemd service, then enrolls the robot.
  2. The agent generates a key pair on the device. The private key never leaves the robot.
  3. The agent exchanges a CSR for a certificate. It sends a certificate signing request (CSR) together with the bootstrap token to the enrollment endpoint (provided by the web app). The server validates the token and returns a robot ID and a signed device certificate.
  4. The agent saves its identity. It writes the device certificate and updates the robot config (see below).

From then on, all cloud communication uses mTLS with that device certificate.

What gets written

After successful enrollment the agent persists, under the state directory (default /var/lib/rdyn/robot):

  • The device certificate (e.g. device.crt).
  • The private key (the generated Ed25519 or RSA key).
  • The assigned robot ID and related fields in robot.toml.

See Configuration for how these identity fields are referenced.

Idempotency

Enrollment is safe to re-run. If a device certificate already exists, the agent detects it and exits cleanly without enrolling again. This means the install command can be retried after a transient failure without creating a duplicate identity.

To re-enroll from scratch, remove the existing certificate and key from the state directory and run enrollment again with a fresh token. Expanded guidance on re-enrollment and certificate rotation is coming soon; in the meantime, contact [email protected].

Next steps