everycli UI

Set up and manage your miner from your browser. The UI is included in everycli v0.8.7 and uses the same miner profile and commands as the terminal. It includes provider keys and balances, worker status, a guided Start action and interrupted-operation recovery.

#v0.8.7 improvements

Worker updates keep waiting through temporary status-check errors, including HTTP 502, and continue after recovery. Heartbeat, session and attestation delays are rechecked before work is restored. The update stays in progress until the intended accepting/paused state is confirmed; completed VM and provider-key changes are preserved.

If the wait limit is reached, progress stays saved. Continue from Worker → Worker software or run everycli worker-update on the same profile.

#v0.8.6 improvements

Open Worker → Worker software to check the installed release, check for updates, install an available update, or continue/cancel a saved update. The dashboard uses the same signed update and confirmation flow as everycli worker-update; it updates the existing VM. Disable automatic worker updates first when the panel asks you to do so.

The setup guide reaches 8/8 when the coordinator confirms that accepting work is enabled. Warnings for individual models remain visible separately; they no longer undo the completed start step.

For an update interrupted by unapproved_running_compose, v0.8.6 can reconcile Phala's reordered environment-key list against a fresh signed release. Use Continue worker update, or run everycli reconcile followed by everycli worker-update. The saved update keeps the corrected signed release while restoring the prior accepting/paused state. Keep the existing profile and VM.

A stale provider catalog is shown separately from an offline worker or a provider-key failure. Refresh status before changing credentials.

#v0.8.4 improvements

The setup guide includes Pika and direct Kling keys. Progress updates without clearing open forms, and saving one key preserves other unsaved inputs. Models supports text search and provider/type filters; a mixed batch updates eligible models and identifies skipped ones individually. An existing unavailable offer can still be withdrawn.

The Worker page shows observed cloud state and automatic-update mode. Emergency shutdown, deletion and redeployment are under Advanced. CLI and worker-update checks use readable summaries.

If the browser loses an operation response, it shows Unconfirmed, retains the operation ID and provides Check result. Rechecking reads the existing operation; it does not submit it again. If the UI server has restarted and no longer has the result, re-sync the existing worker and review its state before clearing the notice.

Run everycli update, stop the old UI process, and run everycli ui again. This CLI/UI patch does not require a generation-worker update.

#Open your dashboard

Install everycli, then run:

bash

everycli ui

Keep this terminal running while using the dashboard. It opens a paired page on your computer at 127.0.0.1:47117. If the browser does not open automatically:

bash

everycli ui --no-open

Open the complete pairing URL printed in the terminal. Keep it private: it grants access to your local management session. Do not share it in screenshots, forward it to another person or expose the UI port to the internet. A saved key is never displayed again, but authorized actions can change your worker and spend money.

Already initialized in the terminal? Open the UI as the same OS user with the same profile. Do not create a new miner just to use the dashboard. The default profile is ~/.config/everycli-mainnet117. For a custom profile or another local port:

bash

everycli ui --state-dir /absolute/path/to/miner-profile --port 47118

Use that same --state-dir for subsequent terminal commands. A worker label is only a local display name; it does not select another profile or change the signed VM identity.

#Set up a new miner

Have a hotkey already registered on SN117, a funded Phala workspace and a supported generation-provider account ready. See requirements.

Follow Setup guide in the sidebar:

Select your hotkey. Choose a local wallet/hotkey or enter its keyfile path. Check registration verifies membership without a blockchain transaction. Address-only mode can check a public address, but initialization needs its local hotkey file. An attached identity appears as Your hotkey when you return.
Add your Phala hosting token. Create it in Phala Cloud → Settings → API Tokens, in the workspace that will host your worker. Do not use Private AI → API Keys. Paste the complete token, not its shortened prefix.
Add a provider API key. Save at least one supported generation key. The UI checks it before saving; a rejected key is not saved. An unavailable or restricted check can save with an unverified warning. A successful check is not a paid-generation test or proof of enough funds. Vivix W1 needs W credits, not A credits.
Create your miner profile. Prove ownership with the selected hotkey and download the signed configuration. This does not create a VM or submit a blockchain transaction.
Deploy your worker. Review the live hosting quote and explicitly confirm. The default $10/hour is a maximum permitted compute rate—not the quoted price or a total spending budget. Lower it to your intended ceiling. Storage costs extra.
Activate your keys. Wait for accepted workload attestation, using Check again as needed. Activation sends encrypted generation keys to the verified worker and restarts it. Wait for fresh attestation after that restart.
Choose models to serve. Open Models, choose the contracts you can support and review an offer before confirming it. A saved provider key alone does not create an offer.
Start accepting work. Confirm this action, then check Overview → Health checks. Readiness requires current attestation, an online worker and a current offer, among other checks. Passing checks does not guarantee jobs or earnings.

The guide preserves your selected step when you save a key. Before deployment, warnings about a missing VM, attestation or offer are expected; do not create another VM to clear them. If a worker already exists for this hotkey, follow the existing-worker or recovery flow instead.

#Find your way around

Page	What to use it for
Overview	Miner UID and shortened public hotkey; Worker, Status, Active offers and Jobs cards; health checks, jobs by model, provider balances and serving fees.
Setup guide	Complete the steps still needed for your current profile.
Models	Browse integrated models, inspect readiness and manage individual or batch offers.
API keys	Save, replace or test provider keys; apply changed generation keys to the worker.
Worker	Rename locally, reconnect, reconcile, update, pause, start, shut down, delete or read logs.
Help	Find explanations and next steps for error codes.

The UID comes from a finalized registration lookup. Use Refresh UID to check it again; hover or copy to see the full public hotkey. Jobs by model separates accepted jobs from attempt counts. Serving fees are shown as tables, not proof of wallet payments, on-chain alpha received or net profit.

#Manage models and discounts

Use Ready for my keys, My active offers or All models to narrow the list. Unintegrated models are hidden. Readiness explains why an integrated model cannot yet be offered or served—for example, a missing key or worker update.

Candidates / retired holds unpriced and retired contracts separately. Rows show both the Everyframe contract ID (for offers) and the provider API ID. A removed/deprecated model cannot receive a new offer, but you can withdraw its existing offer. Availability messages distinguish a retired endpoint, unavailable key access, a temporary catalog-check error, and unchecked account access.

If pricing is unavailable, the UI explains it before confirmation and changes no discounts. Refresh the catalog when pricing is restored, then review again.

To change several offers, select rows or all editable models in the current tab, enter one discount and review the batch before confirming. You can also withdraw selected offers. Batches are atomic: a changed quote or offer revision rejects the whole batch rather than leaving partial changes. Refresh and review the new values before trying again.

A discount reduces the reward target, not the provider's charge to you. Check models and reward targets before bidding. Work is not guaranteed.

The Models / All models badge marks newly integrated model IDs since this browser/profile's first catalog snapshot. Opening All models acknowledges them; it does not automatically offer them. Batch results can be dismissed, clear when navigating or switching tabs, and expire after 12 seconds (30 seconds for errors).

#Read balances and change keys

In Overview → Provider balances, use Refresh and read the status and age together with the amount. Run everycli balances in the terminal to see the source as well. A stale synced balance is not a fresh provider check. Unavailable or unsupported does not mean zero, and a successful key test does not guarantee that the provider exposes a balance API.

The UI shows USD where available and Vivix W credits for W1. Other native credit balances may require everycli balances in the terminal; a dash in the UI is not proof of an empty account. Shared account balances must not be added together across miners. See provider balance coverage for each provider's units and limitations.

In API keys, Save / Replace checks a newly entered key and Test checks a saved one. Saving locally does not update a running worker. Use Apply keys to worker, or Worker → Apply keys, to install changes with a restart and fresh attestation. Optional billing keys stay local and are not sent to the worker. Revoking a leaked key must also be done at the provider.

#Update without redeploying

The CLI and cloud worker are separate:

CLI: Run everycli update in the terminal, stop the old UI process with Ctrl+C, then run everycli ui again. Refreshing the browser alone does not replace the running UI server.
Worker: Open Worker → Update worker → Check, then Update to review and confirm an available signed update. This updates the same VM, waits for attestation and restores its previous accepting/paused state. New models still need your explicit offers.

Automatic CLI updates do not update workers. Do not deploy a second VM to upgrade. See worker updates.

#Recover an interrupted operation

Open the failed action's Details and read the error code before retrying.

Situation	Next action
UI disconnected or pairing expired	Check that `everycli ui` is still running. If restarted, open its newly printed pairing URL.
Coordinator rejected the profile authorization	Check the computer clock, then Worker → Reconnect profile with the same hotkey. This preserves saved keys and does not create a VM. It is not a Phala-token error.
A cloud operation was interrupted	Use Worker → Re-sync operation. It checks the recorded operation instead of blindly repeating a billable request.
Initial `provision_intent`, no app ID, adding keys blocked	In the current CLI, Re-sync operation can clear an uncommitted preparation only after verifying the coordinator is unbound and no matching Phala VM exists. Then save keys and reconnect before continuing.
Local phase says running, but Phala reports stopped	In v0.8.2, refresh readiness and use Start for the same VM. Review the hosting quote, then Re-sync state after Phala reports running. Wait for fresh attestation before Resume.
`start_intent` or `starting` remains while the VM is stopped	Use Re-sync operation. A start is cleared only when Phala confirms failure; missing evidence keeps it unresolved. Inspect that VM's Phala Operations. Keep the profile and VM; do not repeatedly submit a start.
Worker exists on another computer, or was deleted in Phala	Use the existing-worker and deleted-VM recovery guide. No local deployment record does not prove that no billable worker exists.

If reconciliation cannot determine what happened, preserve the profile and operation journal. Do not delete local state or repeatedly deploy. init is not a general substitute for reconciliation. See safe preparation recovery.

#Pause, shut down or delete

Worker action	What happens	Billing impact
Pause	Finish current jobs, stop taking new ones; VM stays running.	Hosting continues.
Shut down	Drain work and stop the VM without deleting it.	Storage can still be billed.
Emergency shutdown	Attempt to stop the verified VM when the coordinator is unavailable; can interrupt paid jobs.	Storage remains billable.
Delete	Permanently remove the VM and its storage after confirmation.	Ends billing for that removed workload, not other resources or earlier charges.

Check deletion completes before assuming billing has stopped. Delete and deploy again is a destructive replacement, not a refresh button. It creates a new billable worker after confirming the old one is gone.

#Use the UI on a remote computer

On the computer holding your miner profile:

bash

everycli ui --no-open

From your own laptop, forward the loopback port over SSH:

bash

ssh -N -L 47117:127.0.0.1:47117 USER@SERVER

Open the complete pairing URL from the remote terminal in your laptop's browser. Keep both processes running. Replace USER@SERVER with your SSH destination; if using --port, use the same port in the tunnel. Do not open this port publicly or put the UI behind a public proxy.

#Provider balances

The API keys page shows balances alongside key management. Use Refresh to update the amount, status and check time. Refreshing keeps unsaved key input intact. You can check keys before hotkey initialization; no generation or cloud deployment is submitted.