Requirements

You do not need a GPU. You need a supported computer for the CLI, a registered miner hotkey, a funded cloud account and a funded generation provider.

#Accounts and keys

You need	Purpose
Hotkey registered on mainnet SN117	Your miner identity. On-chain registration is separate from everycli's membership check. Use your own coldkey, not the subnet owner's.
Local hotkey file	Signs scoped, revocable, non-expiring authentication locally. It is not uploaded to the coordinator or worker.
Phala Cloud account and workspace API token	Pays for and manages the Intel TDX confidential VM. Create the token under Settings → API Tokens, not Private AI → API Keys.
Generation provider account and API key	Pays for provider requests. The reviewed catalogue has 9 priced providers; choose one supported by your release and `everycli offers`. See Providers & keys.

New public miners do not need an invitation file, miner token or registry credentials. Everycli retrieves and verifies the signed deployment configuration automatically.

Use the Phala workspace where the miner will run: its API token can access only that workspace's resources. Copy the full token into the hidden phala prompt. See Phala Cloud hosting token for the exact steps and recovery if you saved an inference key by mistake.

#Local machine and wallet

Install everycli v0.8.7 on supported Linux or macOS, or a compatible Linux under WSL to follow these guides. No compiler, runtime, Docker or GPU is required locally.

The current local signer supports an unencrypted sr25519 wallet JSON containing secretSeed, with owner-only permissions. Encrypted keyfiles and symlinked paths are rejected. If this does not match your wallet setup, resolve that compatibility before spending on deployment; do not send a seed to support or casually weaken your wallet protection.

With --wallet my-miner --hotkey default, the CLI reads ~/.bittensor/wallets/my-miner/hotkeys/default. Alternatively use --hotkey-file /absolute/path/to/hotkey. --hotkey-ss58 ADDRESS supports a public membership lookup, but cannot replace the local signer during initialization.

The CLI does not access your coldkey or sign an on-chain transaction. It checks the chain identity and finalized membership, then signs scoped off-chain authentication. The worker receives only its restricted delegate, not your wallet key.

#The confidential VM

The signed deployment configuration pins the cloud request. The current public release uses:

Setting	Value
Host	Phala Cloud, Intel TDX
Instance	`tdx.small` — 1 vCPU, 2 GiB RAM
Disk	20 GB
Guest OS	Hash-pinned, operator-reviewed production `dstack` image; new deployments use `dstack-0.5.12`. Existing workers retain their approved OS policy.
Worker	Approved public image pinned by digest, not a mutable tag
Container	Non-root, read-only root, dropped capabilities, bounded CPU/memory
Network	No published ports or gateway; private logs and sysinfo

No image build or private registry login is needed. A custom VPS or locally modified image will not pass the pinned policy automatically.

deploy and start require --max-hourly-usd and reject a live compute quote above your ceiling. This is not a total spending cap. Check Phala's current quote; storage is extra, and stopped VMs can retain billable storage.

#Save credentials in the CLI

bash

everycli set-api-keys
everycli providers

Prompts hide input. Enter preserves an existing key or skips an unset provider. No .env file is required. See Providers & keys to change one key or apply changes to a running worker.

#How keys are protected

Profile directories use mode 0700; credential files use 0600. Local credentials are not encrypted at rest. Use a protected account and encrypted disk, and keep private state out of source control and shared backups.

Activation checks fresh admission of the exact workload, then encrypts allowed provider keys locally to the pinned Phala app key. The worker sends each key only to its authorized provider API over HTTPS. CDN downloads do not receive provider credentials.

Your workstation, the reviewed worker, release policy and Phala KMS remain trusted. The public admission policy checks approved OS measurements, app/compose identity, the hardware-bound configuration and full boot transcript, including the trusted KMS CA identity. It does not establish an independently audited KMS implementation.

#Budget expectations

Hosting continues while waiting for attestation or work; there is no automatic total-budget cutoff or shutdown.
A submitted generation may charge your provider account even if it fails, times out or earns no reward. A coordinator refund event is not a refund from the provider to you.
A mining discount reduces your reward target, not your provider bill. No reimbursement, traffic or profit is guaranteed.
Coordinator job-spend limits do not cap your hosting bill, unrelated use of your key or actual provider billing differences. Use provider-side limits where available.