---
title: "Servers and pools: bring your own servers · Frazer"
description: "Bring your own servers into Frazer: add one with a single command over SSH, connect your OVH account or boot our image. Accept each server, group servers into pools and share their capacity with your projects, priced per physical core."
url: https://frazer.ai/servers
index: https://frazer.ai/llms.txt
tokens: 3808
---

> For agents: every page on frazer.ai is indexed at https://frazer.ai/llms.txt.

# Servers and pools: bring your own servers · Frazer

**Servers and pools**  frazer.ai

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

Add a server with one command over SSH, connect your OVH account, or boot our image. Each server proves who it is before you, or a rule you set, accept it. Frazer inspects it before any project can use it, and pools share its cores, memory and GPUs with the projects you choose.

[Add a server](https://frazer.ai/start?product=servers) [Read the docs](https://frazer.ai/docs)

*The Servers page of the Frazer console for the demo organization Acme: 7 servers at 2 sites, 96 of 196 cores allocated. Dynamo waits to be accepted with the code H4K-7NP; Garnet is being inspected; Fjord is in maintenance for a BIOS update that needs approval; Atlas, Borealis and Cobalt run VMs of 2 projects; Ember is available.*

The Servers page: 7 servers at 2 sites, from pending to allocated product UI, demo organization

01 · How a server joins Fig. 1

## 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](https://frazer.ai/how-it-works).

Your server runs the agent with a join token and shows up as pending, with a fingerprint and a code. You, or a pool rule, accept it, and it gets a 24-hour certificate. Frazer inspects it, and it becomes available in its pool: in vint-hill-default, the servers Atlas, Borealis, Cobalt form one substrate of Kubernetes and Frazer’s VM layer, shared to acme-production (guaranteed 96 vCPU, limit 120) and acme-staging (guaranteed 16 vCPU, limit 32). The agent only connects outbound, to Frazer’s agent gateway and Frazer Link; no inbound port is opened at your site.

**Fig. 1** A server’s path from a join token to the projects that use it

02 · Six ways in

## Six ways in.  
One life after that.

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

Six ways to add a server, what each needs and what it does

| Way in | You need | What happens | Operating system |
| --- | --- | --- | --- |
| [Add with the CLI](https://frazer.ai/docs/servers#add-a-server-with-the-cli) frazer servers add root@host | SSH as root, or with sudo, to Ubuntu 22.04 or 24.04, Debian 12 or 13, Rocky or RHEL 9 or 10 | From your laptop: installs the agent over SSH, reads the server’s code in the same session and accepts it as you. Nothing is wiped; the server becomes a dedicated node. | Yours; you patch it |
| [Connect a provider account](https://frazer.ai/providers) OVHcloud, Hetzner and more | API keys limited to your servers | Frazer reinstalls the servers you tick through the provider’s API. Each one joins and is accepted by itself. | Ubuntu LTS, managed by Frazer |
| Run the install commandFor automation and cloud-init | The same Linux, and a join token from the console or the CLI | The agent installs with no one at the keyboard, and the server waits as pending until you, or a pool rule, accept it. | Yours; you patch it |
| Boot our image | Any console: KVM, IPMI, your provider’s KVM or a USB stick | An ISO, USB image, iPXE script or qcow2 with the token inside. You match the code and pick the install disk. | Ubuntu LTS, managed by Frazer |
| Server with a BMC | A BMC that a small Site Gateway in your site can reach | Zero-touch through Redfish: inspection, firmware, RAID, reinstall and power. | Frazer OS |
| [Buy from Frazer](https://frazer.ai/servers/buy) | A card on file or an invoice account | A server Frazer owns, dedicated to your organization for the term and burned in before it reaches your pool. | Frazer OS |

 `frazer servers add root@203.0.113.10 --site sf-office --pool sf-office-default`

One command from your laptop. The CLI makes a single-use join token for the site and pool, installs the signed agent over your own SSH, reads the server’s code in the same session and accepts it as you. Your Frazer credentials never leave your laptop.

 `curl -fsSL https://get.frazer.ai/node | sudo sh -s -- --token <join-token> --site sf-office`

For automation and cloud-init: the install command, with a token the console or `frazer servers join-tokens create` makes for one site and one pool. The server waits as pending until you, or a pool rule, accept it. What a server needs is on [Real hardware](https://frazer.ai/hardware).

03 · Pools and sharing Fig. 2

## 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.

*The pool vint-hill-default in the Frazer console for the demo organization Acme: a substrate host pool at ovh-vint-hill with 144 vCPU and 672 GiB on 3 hosts, shared with acme-production (guaranteed 96 vCPU, limit 120, using 44) and acme-staging (guaranteed 16 vCPU, limit 32, using 10). 112 of 144 vCPU are held, 8 are kept for a surge VM and 24 are free to burst.*

**Fig. 2** A pool’s Sharing tab: who may use it, and what each project holds and uses product UI, demo organization

-   **Substrate host** pools turn their servers into one substrate. Projects you share it with run clusters and VMs on it, counted in vCPU and GiB.
-   **Dedicated node** pools hand whole servers to one cluster, for big databases or GPUs. Shares count servers.
-   **Guaranteed** capacity is held for its project and never lent. **Limit** is how far it may burst into what nobody holds.
-   A full pool refuses new VMs. It never evicts a running one.
-   Projects share servers as separate VMs in separate networks, or take whole servers for production.

```
$ 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
```

04 · What Frazer may do

## 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.

What Frazer can do to a server you bring, through what, by default, and the guard on it

| What | Through | On your server | Guard |
| --- | --- | --- | --- |
| Read inventory, health and metrics | Agent | On | — |
| Install or upgrade the OS, Kubernetes and the agent | Agent | On, staged, in your maintenance window | Release signature checked against the key pinned at enrollment |
| Join or leave a cluster, drain | Agent | On | — |
| Reboot | Agent | On, in the window | Rate limit per pool |
| Wipe or reinstall | Agent, provider API | Needs an org admin’s confirmation | Audit and approval |
| BMC power, virtual media, firmware | Site Gateway | Same as wipe | 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; you are notified | Session recording |
| Read your workload data | — | **Never.** There is no path | Disk keys sealed per server |

-   ### 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.
    

05 · What you get

## 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.
    

06 · Controls

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

### Who may do what

Host project admins

Create pools, accept servers and edit share settings. Sharing is its own permission, so capacity editors cannot widen it.

Org admins and owners

Admins confirm a wipe or reinstall and turn on a time-boxed shell. Owners detach or retire a server.

Project members

Place clusters and VMs on a shared pool with the create rights they already have. They see only their own project’s share.

### What is logged

-   Join tokens, and every accept or reject with the fingerprint and the token used
-   Every reinstall, wipe, firmware update and shell, with its approval and result
-   Share changes, and each VM placed on a pool: project, name and size, never its data
-   Wipe certificates, stored with the audit log
-   A hash-chained local log on each server that you can forward

### At the cap

-   A budget cap never stops workloads on servers you own. It refuses new billable items: rentals, fleet resources, more accepted servers.
-   Guaranteed capacity stays below the pool’s capacity minus one surge VM. A full pool refuses; it never evicts.
-   Unsharing gives a **7-day** grace period by default. Then VMs stop, never deleted, and disks stay 30 days.
-   Production projects need a second person’s approval to be unshared.

07 · Pricing

## Pay per physical core.  
Not for what runs on it.

Per physical core, metered by the hour while a server is accepted; hyperthreads never count. Clusters, VMs, gateways, DNS and monitoring within the allowances are part of the fee. Detach a server and its meter stops.

[See every price](https://frazer.ai/pricing#lines)

Your servers $1.50 per physical core / month · min $15, max $150 per server · first server ≤ 16 cores free

Your GPUs $49 per data-center GPU / month · $19 per workstation GPU

Clusters $0 per cluster · VMs on your servers are included

Included per server 50,000 metric series · 50 GB logs a month · 100 GB backups · 50 GB registry

From Frazer Rented: provider price + 25 %

Questions

## Servers and pools, answered.

Does Frazer need inbound access to my servers?

No. Everything is outbound from your site: the agent reaches Frazer over TCP 443, and Frazer Link over WireGuard on UDP 51820, or on 443 where UDP is blocked. No inbound port is opened, and an HTTP(S) proxy works.

What if someone steals a join token?

A join token can only create a pending server. A person sees it in the list, compares its code and rejects it, which deletes the record and blocks its fingerprint.

A pool rule accepts a server without a click only when it names something an attacker cannot fake: a provider server Frazer reinstalled itself, a serial number in a purchase order, or a MAC address in a list.

Can Frazer read the data on my servers?

No. There is no path for it: the agent runs typed operations only, disk keys are sealed per server, and remote shell is off until an org admin turns it on for one server, for a limited time, with the session recorded.

Do I keep my own operating system?

Yes, when you add it with `frazer servers add` or the install command: the agent runs on your Ubuntu, Debian, Rocky or RHEL and you keep patching it. Such a server becomes a whole node of one cluster. To run VMs, Frazer manages the OS, so connect a provider account or boot our image; a later switch is a reinstall that needs your approval.

How do I take a server back?

Detach it in the console, or run `frazer-nodelet detach` on the server, which works even when Frazer is unreachable. Frazer’s components and credentials are removed, and you choose to keep the disks, reset state or crypto-erase. Billing stops; the record stays for audit.

Can two projects share one server?

Yes, within one organization. A pool’s share settings name the projects, and each project’s VMs sit in its own network. A project can also take whole servers for itself. A server you bring never runs another organization’s workloads.

## More about servers

-   [**Provider accounts** Connect OVHcloud or Hetzner and pick the servers to bring](https://frazer.ai/providers)
-   [**Your cloud accounts** Dedicated nodes and attached clusters in your accounts](https://frazer.ai/cloud)
-   [**Buy from Frazer** Servers Frazer owns, dedicated to you for the term](https://frazer.ai/servers/buy)
-   [**Real hardware** Named servers, local NVMe, private networks and burn-in](https://frazer.ai/hardware)
-   [**How it works** The agent, Frazer Link and the control plane](https://frazer.ai/how-it-works)
-   [**Regions and sites** Frazer regions and the sites your servers sit in](https://frazer.ai/regions)

## More in Compute

-   [**Kubernetes** A cluster per project](https://frazer.ai/kubernetes)
-   [**Serverless** Deploy a repo, DB included](https://frazer.ai/serverless)
-   [**VMs** Images, disks, groups](https://frazer.ai/vms)
-   [**Devboxes** Real machines per engineer](https://frazer.ai/devboxes)

## Bring the servers you have.  
Frazer runs the cloud on them.

[Add a server](https://frazer.ai/start?product=servers) [Read the docs](https://frazer.ai/docs)
