Nodes and Devices

Pairing, devices, nodes, and fleet

Remote identities start without access and gain only explicit scope or capabilities.

Pairing

Enable [pairing] deliberately, then inspect requests with phoenix pairing list. Approve or deny by request id or code. Pairing requests expire and are bounded to prevent unbounded state growth.

Devices

phoenix devices add NAME read|act creates a random token and displays it once. Only a token hash is stored. List, rotate, revoke, or remove devices with the corresponding phoenix devices subcommands. read and act are separate scopes.

Nodes

Nodes move through enrollment and approval before use. Each node records an address and explicit capabilities. Use phoenix nodes can NAME CAPABILITY to test authorization, and rotate or reject enrollment rather than sharing credentials between machines.

QR and paths

phoenix qr can render pairing, dashboard, and text payloads. px:// addresses identify a bounded leaf inside a workspace file and are validated before resolution.

Fleet cells

Fleet creates isolated per-tenant cells with separate state directories, configurations, and ports. phoenix fleet create NAME, list, env NAME, and remove NAME --force manage them. Cell state is isolated, but credentials exported by the launching shell remain a host-level concern.

See Security, Configuration, and Architecture.