Run a node

Before you start

Become an operator. On the dashboard's Nodes page, an owner or admin of your organization chooses Apply to operate. Operators are vetted before their nodes receive traffic; approval unlocks node sign-in and credentials.

Hardware. Apple Silicon is the tested platform (Mac Studio M3 Ultra, Mac mini M4 Pro, MacBook Pro M4 Max and M5). Linux runs on CPU; the CUDA build is packaged but not yet verified on real hardware. There is no Windows build.

An engine key. A node that joins the network must run with SILICON_API_KEY set, a secret of your choosing that gates the engine's own API. The engine refuses to join without it, with the engine must run with SILICON_API_KEY set before it can join. In the menu bar app, add it under Settings as a custom environment variable.

Install and run

Packaged releases of the menu bar app are not published yet, so today the engine runs from source. You need uv, Node, Rust nightly and Xcode.

# once, on macOS
xcodebuild -downloadComponent MetalToolchain

# the engine dashboard
cd engine/dashboard && npm install && npm run build && cd ..

# run it; --extra mlx is required on a Mac
SILICON_API_KEY=choose-a-long-secret uv run --extra mlx silicon

The engine API and its dashboard are at http://localhost:52415. For a node that survives reboots, install it as the com.silicon.engine launch agent from deploy/macos and put SILICON_API_KEY=... in ~/.silicon/engine.env (mode 600).

Join with device sign-in

Joining is a device sign-in, like signing a TV into an account: the node shows a code, you approve it in the browser, and the node receives its own credential. You never copy a secret by hand.

From the menu bar app

Choose Sign in and join. In the sheet, tick the Models to offer (none ticked offers every loaded model), pick a region or leave it on Auto, keep Connect through the relay on unless the node has a public HTTPS address, and choose Sign in with browser. The app opens the confirmation page and shows the code it should display.

From the engine dashboard

Open http://localhost:52415/network and choose Sign in and join, with the same region and relay choices.

In the browser

The link opens /dashboard/nodes/connect with the code filled in. Check that the code matches the one on the Mac, then choose Approve this node (or Deny). An owner or admin of an approved operator organization can approve. The code looks like BCDF-GHJK, ignores case and dashes when typed, and expires after 15 minutes. On its next poll the engine receives a node credential, exactly once, and it is never shown in the browser. The node appears on the Nodes page after its first heartbeat.

The engine stores its membership (credential, region, relay choice, offered models) in ~/.silicon/network.json (~/.config/silicon on Linux), readable only by you, and resumes it whenever it starts. Leaving the network deletes the stored credential.

Headless nodes

On a machine without a browser, mint a credential on the Nodes page (Mint a node credential, shown once, starts with snop_) and hand it to the node agent, or paste it into the dashboard's Operator credential field.

export SILICON_OPERATOR_CREDENTIAL=snop_...
export SILICON_API_KEY=choose-a-long-secret
python3 engine/scripts/silicond.py

Revoke a credential with DELETE /v1/operator/credentials/{id} on the account API. The relay re-checks credentials every five minutes, and a node whose credential is rejected stops retrying.

Behind NAT: the relay

With the relay on (the default), the node holds one outbound WebSocket to the relay over port 443. The relay exposes it to the gateway, and only the gateway can call through it. No port forwarding, no tunnel of your own, no inbound firewall rule. The relay re-checks the node credential every five minutes, reconnects by itself across relay deploys, and stops for good if the credential is rejected.

Turn the relay off only if the node has a public https:// address of its own; set it as SILICON_NODE_PUBLIC_URL or in the join form.

Choosing the models you offer

A node serves only models it has running. Offered models narrows that further: leave it empty to offer every running model, or list the ones you want to serve. Change it any time without rejoining, with the Offer toggles on the engine dashboard's Network page or in the menu bar app; a model you offer that is not loaded yet is loaded after you join.

PUT http://localhost:52415/v1/network/offered-models
Authorization: Bearer $SILICON_API_KEY

{"offered_models": ["mlx-community/Llama-3.2-3B-Instruct-4bit"]}   # or null for all

A deployment created on the dashboard places a model on your own organization's online nodes (at most two per node by default, the least recently used one making room). A node counts as online while it heartbeats; the engine sends one every minute.

Hot swap

Swap the model an instance serves without dropping requests: POST /instance/{instance_id}/swap on the engine with mode overlap (the default: load the new model beside the old one, then drain the old one; needs memory headroom, else 409) or pause (hold new requests while swapping, and restore the old model if the load fails). Progress is at GET /instance/swaps. Redeploying a ready deployment from the dashboard uses the same path.

Identity and attestation

On first join the engine creates an ed25519 key at ~/.silicon/node_attest.key (mode 600). With it the node signs an attestation of its node id, a hash of each model it serves, and whether its egress is locked, and the control plane checks the signature and freshness. A later heartbeat with a different model hash invalidates the attestation. Keys can be pinned to attested nodes, and the Silicon-Attestation response header reports what served.

Be precise about what this is. The model hash covers the weight manifest (each weights file's path and size, the index, and config.json), not every byte. Egress lock is declared by the operator (SILICON_EGRESS_LOCKED) and the engine cannot verify it. There is no hardware root of trust yet. Attestation gives continuity and non-repudiation; the checks below are what catch a dishonest node. GET /v1/identity on the engine reports its version and the hash and card id of each running model.

Verification, escrow and payouts

A sample of live requests is re-checked against a trusted engine: chat by scoring the node's tokens under the reference model and replaying tool calls, embeddings by similarity, rerank and transcription by re-execution. Results pool per node and model, so one unlucky sample does not condemn a node. Canary probes and k-node quorum exist and are off by default.

Payouts are off today. Earnings show as pending (would-earn) on the Nodes page, the engine dashboard and the menu bar, and become realized, spendable platform credit once verifiable-inference payouts are switched on. There is no cash-out. The bond matters only for earning; it is not needed to serve.

Updates

Updates are opt-in. The menu bar app asks once, on its second launch, whether to check automatically, and never downloads on its own; a release is verified with an ed25519 signature on top of Developer ID signing and notarization. A source or launch agent install updates itself only with SILICON_AUTO_UPDATE=1: the updater then checks every six hours on SILICON_UPDATE_CHANNEL (default stable), verifies a signed manifest against a pinned key and each artifact's SHA-256, waits until the node is idle, switches atomically, and rolls back if the new engine fails its health check.

python -m silicon.updater status     # or check, apply, rollback

Signed engine releases are not published yet, so until the first one is, the updater has nothing it will accept; update a source install with git.

Clusters

Several Macs on one network form a cluster that shards large models across its members and joins as one node. Inside a cluster, a long prompt can be prefilled on another member (SILICON_REMOTE_PREFILL=auto, with SILICON_PREFILL_BIND_HOST set and the same SILICON_API_KEY on every member); the output is identical either way, and it falls back to local prefill when the peer is not there.