Bring your own servers.
One inventory, shared to every project.

From a join token to a pool.
Nothing is trusted until you accept it.

A join token lets a machine ask to join, nothing more. The agent makes its own key, shows a fingerprint and a code, and waits for you. The agent, Frazer Link and the control plane are on How it works.

Six ways in.
One life after that.

Whichever way a server arrives, it lands in the same list and lives the same lifecycle.

Servers in one project.
Capacity shared to the rest.

Servers live in your infrastructure project, so they outlive the projects that run on them. A pool’s share settings decide which projects use it, with a guaranteed amount and a limit for each.

$ frazer servers server-pools share vint-hill-default \
    --project acme-infra \
    --location us-virginia1 \
    --share-type specific-projects \
    --consumer 'acme-production=guaranteed:vcpus=96,memory-gib=384;limit:vcpus=120,memory-gib=480' --dry-run
  Plan      ~ pool vint-hill-default · revision 8 → 9
            + acme-production · guaranteed 96 vCPU, 384 GiB · limit 120, 480
  Capacity  112 of 136 vCPU guaranteed (144 minus one surge VM) · 24 free to burst
  Who       members of acme-production with compute.vms.create can place VMs here
  Affected  none · a new share
? Apply? yes   ✓ shared · revision 9

# vint-hill-default.yaml  (frazer apply -f vint-hill-default.yaml)
apiVersion: servers.frazer.ai/v1
kind: ServerPool
name: projects/acme-infra/locations/us-virginia1/serverPools/vint-hill-default
spec:
  site: ovh-vint-hill
  role: substrate-host            # or dedicated-node
  wipePolicy: crypto-erase
  shareSettings:
    shareType: SPECIFIC_PROJECTS  # LOCAL | SPECIFIC_PROJECTS | ORGANIZATION
    projectMap:
      acme-production:
        capacity: {guaranteed: {vcpus: 96, memoryGib: 384}, limit: {vcpus: 120, memoryGib: 480}}
      acme-staging:
        capacity: {guaranteed: {vcpus: 16, memoryGib: 64}, limit: {vcpus: 32, memoryGib: 128}}
    unshareGracePeriod: 168h      # stop, never delete
    costAllocation: USAGE         # showback to each project

What Frazer may do to a server.
And what it never can.

The agent pulls typed, signed operations and runs nothing else. Its safety rules live in the agent itself, so they hold even if Frazer’s control plane is wrong.

• No exec

  Only typed operations: install the OS, join a cluster, reboot, wipe, run burn-in, collect diagnostics.

• Signed commands

  Every command carries Frazer’s signature. With an approval key, destructive ones need yours too.

• One organization

  It refuses a join bundle that names another organization, or a project the pool is not shared with.

• No open ports

  It listens on localhost only, rate-limits its own reboots and keeps working when Frazer is unreachable.

Run servers like a cloud.
Keep them yours.

• One inventory

  Every server in one list with its state, site, pool and agent, whichever way it arrived.

• Health conditions

  Agent, disks, ECC errors, NIC link and clock; a failed critical one takes the server out of scheduling.

• Remediation ladder

  Alert, drain, reboot, power cycle, then a ticket. Never more than one server or 10 % of a pool at a time.

• Wipe with a certificate

  Crypto-erase, NVMe sanitize and sample reads, with a certificate you can download.

• Staged agent upgrades

  One server, then 10 %, then all. An agent that stops answering rolls back.

• GPU servers

  GPUs found during inspection, before any driver. MIG and time-slicing stay inside one project.

• Maintenance windows

  Kernel and OS updates wait for the monthly window; critical kernel fixes may reboot sooner.

• Approval key

  Pin a key you hold. Wipe, reinstall, BMC power and shell then need its signature.

Who decides what happens.
Every step in the audit log.