Serversfrazer.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 Read the 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 <join-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 worksFig. 1

One request, end to end.
Seven steps, each on the record.

Fig. 1From your request to a running cluster on your servers

1
Ask
You, the CLI or an agent sends a request. Frazer checks who is asking and what they may do.
2
Plan
The API works out the change, the quota and the cost, and shows it. Nothing changes yet.
3
Apply
One transaction writes the resource, an operation and an audit entry.
4
Reconcile
A worker turns the change into signed desired state.
5
Pull
The agents at your site fetch it over the connection they opened, outbound.
6
Build
Frazer’s cluster controller and VM layer on your servers create the VMs, and the cluster boots.
7
Deliver
The cluster’s GitOps engine pulls your apps from your Git. Frazer adds nothing to approve.

02 · JoiningFig. 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.

Waiting for servers✓Source✓Site and pool✓Connect4AcceptListening on sf-office

Servers appear here as soon as their agent connects. Install token ft_…3k9Q 1 of 1 used, expires in 41 min.

PendingDynamooffice-gpu-01appeared 2 min ago · install commandRejectAccept

Match the codeH4K-7NPThe installer printed a code on office-gpu-01. Accept only if it is the same.IdentityFingerprintTPM EK 9f3a…c41eAddress203.0.113.24 · behind NATAttestationtpm-boundSeen beforeNo · new fingerprint

Detected hardwareCPUThreadripper PRO 7965WX · 24cMemory128 GiB ECCGPUs2 × RTX 6000 Ada · 48 GBDisks2 × 3.84 TB NVMeReachNAT detected → Frazer LinkTunnelWireGuard · link-us-virginia1

Preflight · 6 passed, 1 note✓cgroups v2✓Swap off✓Time syncchrony✓Kernel 6.8Ubuntu 24.04✓Outbound 443api, registry✓IOMMU onfor GPUsiNVIDIA driveradded later

Joins sf-office-default as a dedicated node · OS stays yours (Ubuntu 24.04) · labels gpu=rtx-6000-ada

InspectingGarnetoffice-build-01accepted 6 min ago · boot image4 of 6

✓Certificate✓Inventory✓Disk health✓Ubuntu 26.04•Network test–Available

Accept and Reject are recorded in the audit log with the fingerprint and the token used.

What Accept grants. A 24-hour certificate for this server, renewed while it stays healthy. With it Frazer can send typed operations only: inventory, health, join a cluster, reboot in the maintenance window. No shell. Wipe and reinstall always need your approval. You can detach the server yourself at any time.

Rules at sf-office

–Auto-accept · off, a person accepts

!Approval key · not set

–Billing · per core, while accepted

Not seeing a server?

Run sudo frazer-nodelet diagnose on it. Outbound 443 blocked: set HTTPS_PROXY and run it again. Clock more than 5 min off: fix time sync. Token used or expired: create a new one.

Fig. 2Two servers joining a siteproduct 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.

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.
02
One substrate per pool
The servers of a pool form one substrate in one organization; never mixed across organizations.
03
A VM per workload
On a shared server, each project’s VMs sit in their own namespace and their own network.
04
Changing hands means a wipe
A Frazer server moves to another organization only through a wipe with a certificate.
05
Customer code never on the host kernel
On Frazer’s shared fleet, only hardware VMs; GPUs pass through whole.
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.

Run one command.
Match one code.

Add a server Read the docs

A server joins.A cluster follows.

One request, end to end.Seven steps, each on the record.

Ask

Plan

Apply

Reconcile

Pull

Build

Deliver

A token can only ask.A person, or a rule, accepts.

Typed operations only.No shell unless you open one.

No exec

Signed or refused

Your organization only

Nothing listening

Keeps going alone

Your servers run your work.Checked by the API, then by the agent.

A server you bring runs only your organization’s work

One substrate per pool

A VM per workload

Changing hands means a wipe

Customer code never on the host kernel

No credential works twice

Who does what.For each kind of server.

It keeps running without us.And it limits what we can do.

Clusters keep running

GitOps keeps syncing

A kubeconfig for emergencies

Detach at the server

Releases signed offline

Upgrades in stages

Regions share nothing

Your approval key

Every step has an owner.And an entry in the log.