Deploy your miner

These instructions use everycli v0.8.2 and a hotkey already registered on SN117. See installation and requirements first. All commands below use mainnet, the default.

Check hotkey → Save keys → Init → Deploy → Attest → Activate → Attest again → Resume → Offer

Already deployed, or seeing only the original three models? Do not repeat deployment. Use the original management profile to run everycli update, everycli worker-update --check, then everycli worker-update. After fresh attestation, inspect everycli offers and explicitly bid on the new contracts you want to serve. Existing offers remain unchanged; a paused worker stays paused. See worker updates.

#Recommended: guided setup

#Browser setup

Prefer a visual walkthrough? Follow the dedicated everycli UI guide for all eight setup steps, dashboard controls, batch offers and recovery.

Run everycli ui to open the local setup guide. Choose your hotkey, add the Phala workspace token and generation keys, initialize, then review the hosting quote before approving deployment. The UI stays on the selected step when saving keys. Provider rejection prevents saving; restricted or unreachable checks save with an unverified warning. These are free read-only checks, not generation tests. Never share the pairing link or expose this local server to the internet.

The dashboard shows your miner UID and a shortened hotkey, with the full public address available on hover or copy. UID comes from the last finalized registration lookup, not an assumed miner number. Use Refresh UID to check again; it never signs a chain transaction. Initialization and reconnect save the verified lookup automatically.

The first setup step is Select your hotkey, changing to Your hotkey once attached. Reopening the UI preserves the saved identity. Check registration checks membership without signing a chain transaction.

Overview uses four cards: Worker, Status, Active offers, and Jobs. Status distinguishes Ready, Working, Paused, Needs attention, and Unknown. Readiness and attestation details remain under Health checks. Below the cards, Jobs by model shows all-time accepted jobs and attempt counts; serving fees use a readable status/jobs/USD table. These are not wallet-payment receipts.

In any Models tab, select rows or all editable models in the current tab, then apply one discount or withdraw selected offers. Review the exact quotes once before applying. Batches are atomic: a changed quote or offer revision rejects the whole batch, without partial changes or automatic retries. Unavailable new offers are excluded. Results can be dismissed, clear on navigation or tab changes, and expire after 12 seconds (30 for errors) without losing input drafts.

Unintegrated models are hidden. Models and All models show a badge when integrated model IDs are added after your first catalog snapshot. Opening All models acknowledges them in this browser/profile; no keys are stored with it.

The UI's compute ceiling defaults to $10/hour. This is the maximum hourly compute price you permit, not a total budget or the actual quoted price. It does not change the signed instance type; storage costs extra. You must still approve the live quote before a VM is created.

Deploy automatically tries one authorization refresh with the same attached hotkey if its coordinator preflight rejects the saved authorization. It happens before any paid cloud request and preserves keys, labels and deployment history. If recovery cannot finish, check the computer clock and use Worker → Reconnect profile with the original hotkey. This is separate from a Phala API-token error. See profile recovery.

You can rename the displayed worker locally; the signed cloud name remains unchanged. If this hotkey already has a worker, keep it or follow the explicit replace from another computer flow. Do not create a second VM just because a fresh profile has no local record.

#Terminal setup

For a new miner, run this in an interactive terminal:

everycli setup --wallet my-miner --hotkey default --provider fal --max-hourly-usd 0.06

Replace the wallet names with yours. The wizard checks registration, prompts privately for Phala and Fal keys, initializes the signed profile, then shows the live hosting quote for explicit confirmation before creating a paid VM. Use a Phala workspace token from Settings → API Tokens, not Private AI → API Keys. The compute ceiling is not a total budget; storage costs extra and hosting continues until stopped.

--provider fal limits the key prompts to Phala and Fal; omit it to see all providers. If you omit --max-hourly-usd, the wizard asks for a ceiling. New setup is interactive only: it does not accept --yes or --json. Prompts show Saved — Enter keeps existing or Not saved — Enter skips without revealing keys.

The wizard stops on a failed step, an existing or uncertain local deployment, or an existing remote worker. It never registers on-chain, activates credentials or resumes generation automatically. Deployment is step 4 of 11, not completed miner setup. The final message prints steps 5–11 for readiness checks, activation, fresh attestation, resuming, reviewing models, placing an offer and checking readiness again. Continue at Activate after admission. If your hotkey is unregistered, review the suggested registration command and fee, register separately, then rerun everycli setup.

To show the checklist again from the original management profile:

everycli setup --continue

This reads your local deployment journal, not live readiness. It does not call the network, create a VM, activate keys or resume paid work. Use the same --network and --state-dir on every follow-up command, and perform only the steps still needed. This read-only mode supports --json without a terminal; it rejects --yes and new deployment options. If an operation is uncertain, preserve the original profile and run status and reconcile first. Do not create a replacement VM to recover a lost response.

For command options and an example, run everycli setup --help or everycli help deploy. For manual setup or automation, use the individual steps below.

#1. Select your hotkey

everycli register-hotkey --wallet my-miner --hotkey default

Replace the wallet and hotkey names with yours. This checks finalized subnet membership and records your public identity and local keyfile path. It does not perform on-chain registration or pay its fee. If unregistered, register separately using your wallet tool and rerun this check.

If a wallet name is missing, the CLI names it and lists available wallet directories under the current OS user's ~/.bittensor/wallets. It does not read or display private key contents. For a wallet stored elsewhere, use --hotkey-file FILE.

For a public lookup only, use --hotkey-ss58 YOUR_SS58_ADDRESS. You will still need a supported local hotkey file at the initialization step.

#2. Save your API keys

Before answering the phala prompt, sign in to Phala Cloud, select your intended workspace, and create a token under Settings → API Tokens → Create Token. Paste the full workspace token into the hidden prompt, not its shortened prefix.

everycli set-api-keys
everycli providers

Hidden prompts collect Phala and generation-provider keys; Enter preserves or skips each key. You need a funded Phala account and a provider supported by your signed release and enabled models; the examples use Fal, not every provider. Keys stay in your owner-only local profile. No .env file is required.

#3. Initialize and check

everycli init
everycli doctor

init reuses the saved keyfile path and credentials. If you used a public-address lookup, add --wallet my-miner --hotkey default or --hotkey-file /absolute/path/to/hotkey.

The CLI checks finalized subnet membership before enrollment, verifies a fresh coordinator challenge, signs proof locally, and downloads the signed deployment configuration after the server also checks membership. An unregistered hotkey gets a subnet-specific explanation and a suggested btcli registration command; a failed network check is not treated as proof of non-registration. No invitation file or miner token is required. Your hotkey never leaves your computer; only scoped, revocable authentication is delegated. Compatible v2 delegates do not expire; legacy v1 delegates retain their signed expiry. No coldkey or blockchain transaction is involved.

These commands do not create a paid VM. Before deployment, doctor may report no workload, no attestation or no offer; read the individual checks rather than treating every warning as a failed install.

doctor checks readiness to mine, so it does not need to be fully green before the first deployment. Credential-presence checks only confirm that a key was saved. After initialization, use everycli balances to check the local Phala token; a synced snapshot does not verify it. An authentication error needs attention before deployment. A coordinator timeout is a separate connectivity issue, not proof of a wrong Phala token—retry the read-only everycli status and resolve persistent connection failures before creating a VM.

#4. Deploy the confidential VM

everycli deploy --max-hourly-usd 0.06
everycli status

Review the live compute quote and confirm. The example ceiling is not a total budget. Storage costs extra and hosting continues while you wait for work; there is no automatic shutdown.

The CLI records a durable operation intent, creates the pinned workload, checks its app/compose identity and binds the public miner automatically. The worker starts with generation credentials disabled. The coordinator verifies the exact workload against its reviewed TEE policy; you do not need to send hashes to an operator for routine public setup.

If a command is interrupted, use reconcile before retrying. Never create a replacement VM just because a response was lost.

#5. Activate after admission

Wait until status shows accepted attestation for the deployed workload, then:

everycli activate
everycli status

Activation verifies fresh admission, encrypts permitted provider keys to the pinned app key and restarts the worker after confirmation. It stays drained. Wait for fresh post-restart admission before continuing; the earlier session is not enough.

#6. Resume and make an offer

everycli resume
everycli offers

Resume permits work but does not create an offer. Choose a currently enabled model and review its quote. For example:

everycli offer --model studio/fal/minimax/h3-max-turbo/text-to-video --discount-pct 10
everycli health
everycli doctor
everycli earnings

A 10% discount is an example, not a recommended margin: it lowers your reward target without reducing provider charges. See bidding economics. Routing also requires a current offer, fresh attestation, matching capability, an idle worker and no administrative pause. Work and earnings are not guaranteed.

#7. Check readiness and activity

everycli health
everycli status

Run these on the original management device. health displays green PASS, amber WARN and red FAIL checks; all green means the current readiness checks passed. status shows deployment, routing, model offers and job activity as tables. Use --json on either command for structured output.

Zero active jobs is normal when idle, and old accepted jobs are historical evidence—not a live generation test. These checks do not spend provider credits or guarantee traffic. Before deployment or activation, not-ready results are expected; do not deploy again just to clear a red or amber check. Follow the health checklist and investigate the stated reason.

#If something is interrupted

everycli reconcile

This checks uncertain operations without blindly replaying paid cloud requests. For public onboarding it can also finish the idempotent app binding. It is therefore not strictly read-only. If the state cannot be resolved, it exits unsuccessfully rather than creating another VM.

If an initial provision_intent has no app ID and adding keys is blocked, v0.8.2 can archive that uncommitted preparation after verifying an unbound coordinator and no matching Phala workload. Use Re-sync operation in the UI or the command above. Then save keys and run everycli reconnect before continuing. See safe preparation recovery.

Do not erase deployment state or a pending intent. The OS releases the advisory operation lock when the CLI exits or crashes; a leftover lock file alone does not block a later command. Preserve the operation journal and reconcile uncertain cloud actions. Contact support with sanitized identifiers if uncertain.

Next: Day-to-day operations covers updating keys, renewal, pausing and shutdown.