--- title: "How it works: from a server to a running cluster · Frazer" description: "How a server joins Frazer and runs your workloads: a join token that can only ask, a code you match, an outbound-only agent that runs signed, typed operations, a control plane that plans every change, and isolation that keeps organizations apart." url: https://frazer.ai/how-it-works index: https://frazer.ai/llms.txt tokens: 3016 --- > For agents: every page on frazer.ai is indexed at https://frazer.ai/llms.txt. # How it works: from a server to a running cluster · Frazer **Servers** frazer.ai # A server joins. A cluster follows. The token it joins with can only ask. Its code is matched, by the CLI over your own SSH or by you in the console, then the agent dials out and takes typed, signed operations and nothing else, and your clusters build on the server from a plan you applied. [Add a server](https://frazer.ai/start?product=servers) [Read the docs](https://frazer.ai/docs) ``` $ frazer servers add root@203.0.113.10 --site sf-office ✓ SSH root@203.0.113.10 · host key known ✓ Join token sf-office · single use · for this run only ✓ Agent signed · checksum verified ✓ Preflight kernel · cgroups v2 · clock · swap · disk · 443 ✓ Machine key generated on the server · TPM-sealed when present → Fingerprint TPM EK 9f3a…c41e ✓ Code H4K-7NP read over SSH · accepted by you inspecting … available ``` ``` $ curl -fsSL https://get.frazer.ai/node | sudo sh -s -- \ --token --site sf-office ✓ Script and agent signed · checksum verified ✓ Preflight kernel · cgroups v2 · clock · swap · disk · 443 ✓ Machine key generated here · TPM-sealed when present → Fingerprint TPM EK 9f3a…c41e → Code H4K-7NP match it in the console pending · no credentials until someone accepts ``` ``` $ sudo frazer-nodelet detach Works even when Frazer is unreachable ✓ Drained · left the cluster ✓ Frazer components and credentials removed ? Disks: keep · reset state · crypto-erase › keep detached · billing stopped · record kept for audit ``` 01 · How it works Fig. 1 ## One request, end to end. Seven steps, each on the record. **Fig. 1** From your request to a running cluster on your servers 1. 1 ### Ask You, the CLI or an agent sends a request. Frazer checks who is asking and what they may do. 2. 2 ### Plan The API works out the change, the quota and the cost, and shows it. Nothing changes yet. 3. 3 ### Apply One transaction writes the resource, an operation and an audit entry. 4. 4 ### Reconcile A worker turns the change into signed desired state. 5. 5 ### Pull The agents at your site fetch it over the connection they opened, outbound. 6. 6 ### Build Frazer’s cluster controller and VM layer on your servers create the VMs, and the cluster boots. 7. 7 ### Deliver The cluster’s GitOps engine pulls your apps from your Git. Frazer adds nothing to approve. 02 · Joining Fig. 2 ## A token can only ask. A person, or a rule, accepts. The machine makes its own key and shows a code. Nothing is trusted until someone matches the code, or a pool rule names something an attacker cannot fake: the provider ID Frazer reinstalled, a serial on a purchase order, a MAC on a list. *The Waiting for servers screen in the Frazer console at site sf-office. A pending server, office-gpu-01, appeared two minutes ago from the install command: match the code H4K-7NP, its TPM fingerprint, address behind NAT, tpm-bound attestation and a new fingerprint; detected hardware with a 24-core CPU, 128 GiB ECC memory, two RTX 6000 Ada GPUs and two NVMe disks, reached through Frazer Link; preflight six passed with one note. It joins pool sf-office-default as a dedicated node and keeps its own OS. A second server, Garnet, is inspecting, four of six checks done. On the right: what Accept grants, the rules at sf-office, and what to do if a server does not appear.* **Fig. 2** Two servers joining a site product UI, demo organization The three credentials of a join | Credential | Made | Lifetime | Allows | | --- | --- | --- | --- | | Join token | By Frazer, for one host project, site and pool | 24 h by default, 30 days at most; a use limit; revocable | Create a **pending** server. Nothing else. | | Machine key | On the server; sealed in the TPM when there is one | The life of the server | Sign a certificate request. The private key never leaves. | | Machine certificate | By your infrastructure project’s own CA, after you accept | 24 hours, renewed while the server is healthy | Mutual TLS to the agent gateway and a WireGuard key on Frazer Link | 03 · The agent ## Typed operations only. No shell unless you open one. `frazer-nodelet` is one signed binary under systemd, open source under Apache-2.0. It pulls signed desired state and runs nothing else. Its rules hold even if Frazer’s control plane is wrong. - ### No exec Only typed operations: install the OS, join or leave a cluster, reboot, wipe, burn-in, diagnostics, firmware. - ### Signed or refused Every command carries Frazer’s signature; destructive ones also need your approval key once you pin one. - ### Your organization only The agent refuses a join for another organization, or for a project without a signed share. - ### Nothing listening No network port except on localhost; it rate-limits its own reboots. - ### Keeps going alone When Frazer is unreachable the server stays in its cluster and keeps its state. What Frazer can do to a server | Capability | Through | Your server | Rented from Frazer | Guard | | --- | --- | --- | --- | --- | | Read inventory, health, metrics | Agent | On | On | — | | Install or upgrade the OS, Kubernetes, the agent | Agent | In your maintenance window | On | Release signature checked against the pinned key | | Join or leave a cluster, drain | Agent, cluster controller | On | On | Audit log | | Reboot | Agent | In your window | On | Rate limit per pool | | Wipe or reinstall | Agent, provider API, BMC | Needs an org admin’s confirmation | Between tenants | Approval, audit | | BMC power, virtual media, firmware | Site Gateway | Same as a wipe | On | BMC credentials can stay on site | | Remote shell, serial console | Agent through Frazer Link | **Off.** An org admin turns it on per server, time-boxed and recorded | Frazer staff, with a ticket | Session recording; you are told | | Read your workload data | — | **Never**; there is no path | **Never** | Disk keys sealed per server | 04 · Isolation ## Your servers run your work. Checked by the API, then by the agent. 1. 01 ### A server you bring runs only your organization’s work Only projects its pool is shared with. Never another organization, never Frazer’s fleet. 2. 02 ### One substrate per pool The servers of a pool form one substrate in one organization; never mixed across organizations. 3. 03 ### A VM per workload On a shared server, each project’s VMs sit in their own namespace and their own network. 4. 04 ### Changing hands means a wipe A Frazer server moves to another organization only through a wipe with a certificate. 5. 05 ### Customer code never on the host kernel On Frazer’s shared fleet, only hardware VMs; GPUs pass through whole. 6. 06 ### No credential works twice A CA per infrastructure project and a certificate per server; nothing is valid in two organizations. 05 · Shared responsibility ## Who does what. For each kind of server. Shared responsibility per kind of server | Layer | Your servers | Provider accounts | Frazer servers | | --- | --- | --- | --- | | Physical security, power, firmware | You | Your provider | Frazer, with its provider | | Server acceptance, burn-in, wipe | You, checked by Frazer | You, checked by Frazer | Frazer, wiped before reuse | | Operating system image and nodelet | Frazer | Frazer | Frazer | | Control plane, isolation between orgs and projects | Frazer | Frazer | Frazer | | Your workloads, code and data | You | You | You | | Roles, grants and approvals | You set, Frazer enforces | You set, Frazer enforces | You set, Frazer enforces | 06 · What holds ## It keeps running without us. And it limits what we can do. - ### Clusters keep running When Frazer is down your clusters run on; agents keep their state. - ### GitOps keeps syncing Deploys from your Git carry on without the control plane. - ### A kubeconfig for emergencies Org owners can download an admin kubeconfig per cluster; using it marks the cluster until its CA is rotated. - ### Detach at the server `frazer-nodelet detach` works locally, even with Frazer unreachable. - ### Releases signed offline Agent and OS releases need an offline release key pinned at enrollment, not the online control plane. - ### Upgrades in stages One server, then 10 %, then all; an agent that misses heartbeats after an upgrade rolls back. - ### Regions share nothing Each region’s control plane has its own database and credentials. - ### Your approval key Pin a key your organization holds, and wipe, reinstall, BMC power and shell need its signature. 07 · Controls ## Every step has an owner. And an entry in the log. ### Who may do what Servers admin Creates join tokens, accepts or rejects servers, and sets pool rules. Org admin Confirms a wipe or reinstall, and can turn on a remote shell per server for a set time. Agents Use the same API, plans, approvals and audit as people. Frazer staff No shell on your servers unless an org admin turns it on; on Frazer servers, only with a ticket. ### What is logged - Join tokens, accepts and rejects, with the fingerprint and the token used - Every plan and apply: who, what and the operation - Every operation on a server, with its approval and result - A hash-chained log on the server itself, which you can forward ### At the cap - **Join token:** 24 h by default, 30 days at most, with a use limit - **Certificates:** 24 h; a revoked server disconnects within one heartbeat, 30 s - **Remote shell:** off by default; time-boxed and recorded when on - **Automatic repair:** one server, or 10 %, per pool at a time Questions ## How it works, answered. Does Frazer need an inbound port at my site? No. Agents dial out: control on TCP 443 with mutual TLS, data through Frazer Link over WireGuard on UDP 51820, or over 443 where UDP is blocked. Allow egress on 443 and 51820, NTP and DNS; an HTTP proxy works. What if someone steals a join token? It can only create a pending server, which a person sees and rejects. Rejecting deletes the record and blocks that machine’s fingerprint. Can Frazer staff log in to my server? Not by default. The remote shell is off; an org admin can turn it on for one server and a set time, the session is recorded, and you are told. What happens to my clusters if Frazer goes down? They keep running. Agents keep their state, the cluster’s GitOps keeps syncing from your Git, and break-glass kubeconfigs work without Frazer. Can another organization’s work land on my server? No. A server you bring runs only your organization’s workloads, and only those of projects its pool is shared with. The API enforces it and the agent checks it again. What does Frazer store about my servers? Metadata: resources, operations and the audit log, never workload data. Secrets live in Frazer Secrets, and nobody at Frazer has a path to the data on your disks. ## More in Servers - [**Bring your own** Install command, boot image or provider account](https://frazer.ai/servers) - [**Provider accounts** Servers you rent, joined through the API](https://frazer.ai/providers) - [**Your cloud accounts** Instances join, clusters attach](https://frazer.ai/cloud) - [**Buy from Frazer** Dedicated servers by the month](https://frazer.ai/servers/buy) - [**Real hardware** What Frazer needs from a server](https://frazer.ai/hardware) - [**Regions and sites** Where Frazer runs, where servers are](https://frazer.ai/regions) ## Run one command. Match one code. [Add a server](https://frazer.ai/start?product=servers) [Read the docs](https://frazer.ai/docs)