Deploy your miner

The lifecycle is deliberately sequential and fails closed at every step. Nothing is created in the cloud until deploy, and your provider key is never released into the enclave until the coordinator has admitted that exact VM.

init ──▶ doctor ──▶ deploy ──▶ [operator admission review] ──▶ activate ──▶ [post-restart admission] ──▶ resume

#1. Import your invitation

everycli miner init

The wizard asks for the paths of the signed invitation (invitation.json) and your private credentials file. Or pass them explicitly:

everycli miner init --invitation invitation.json --secrets-file miner.env

init verifies the invitation signature against the pinned coordinator key, checks that the bearer hash of your miner token matches the invitation, and copies only the named credentials into ~/.config/everycli (mode 700, files 600). It never creates cloud resources and never reads a .env it was not told about. Symlinked state or credential paths are rejected.

#2. Run the diagnostics

everycli miner doctor

doctor checks credential presence, file permissions, the invitation, scoped coordinator access, cloud binding, TEE admission and availability. It exits 2 while anything is not ready, which at this point is normal — you have no VM yet. It does not check your provider balance.

#3. Deploy the confidential VM

everycli miner deploy --max-hourly-usd 0.06

--max-hourly-usd is required. The CLI reads the live Phala rate for tdx.small, shows it, and asks you to confirm; if the rate is above your ceiling it aborts before provisioning. The flag limits the compute rate only — storage is billed separately, hosting continues while you wait for admission, and there is no automatic shutdown.

What deploy does, in order:

1. Saves a durable intent to the local journal before every cloud mutation.
2. Creates one VM named everyframe-<minerId> from the pinned request (instance, disk, OS image hash, KMS, digest-pinned compose).
3. Checks the returned app, OS and compose against the invitation.
4. Boots the worker with a disabled placeholder provider key.

When it finishes it prints the app ID and the full compose hash. Send those two values — and only those — to the operator for admission review. Do not send the credentials file.

#4. Activate your provider key

Once doctor reports accepted TEE admission:

everycli miner activate
everycli miner doctor

activate asks the coordinator for a signed confirmation that this app and compose have fresh accepted admission, encrypts your Fal key locally to the saved Phala app key, drains any existing work and requests a secret update. The worker restarts with the real key and stays drained until it is admitted again after the restart. Phala remains the trusted KMS operator for that encryption.

#5. Resume

After the fresh post-restart admission (the operator may need to review the new runtime snapshot):

everycli miner resume
everycli miner status

resume only clears your drain flag. It cannot lift an administrative pause, approve a release, change your model allowlist, enable global routing or submit a generation. Once routing is enabled for a pilot window, a resumed miner will accept assignments — and each one charges your provider account.

#If something is interrupted

everycli miner reconcile

The CLI never blindly retries an uncertain provision, commit, activation, update or shutdown. reconcile is read-only and can confirm a committed VM, a completed update, a startup or a shutdown. A running VM alone does not prove a secret update succeeded. If it cannot resolve the state it exits 2 and tells you to contact the operator.

An interrupted process can leave operation.lock in the state directory. Inspect its PID and the deployment journal before removing that exact file. Do not erase the state directory, edit away an intent, or create a replacement VM to make an error disappear — the operator can only admit the VM the journal knows about.

Next: Day-to-day operations.