<!-- cmdz — Our hardware. Source: https://www.cmdz.com/hardware -->
# Our hardware
> We own the machines, in racks we manage, and that is why a spending ceiling can exist at all. Rocky Linux 10, k3s, Kata micro-VMs, encrypted disks, and one bootstrap command per node.

Not resold capacity, not a subcontractor doing the management, not a region that gets consolidated next quarter. This page exists because the promise on the front page only makes sense if you believe this part.

Own racks · Rocky Linux 10 · k3s · Kata · Encrypted at rest

## Why owning it is what makes the ceiling possible.

A platform that buys from a hyperscaler pays per gigabyte transferred, per gigabyte stored and per CPU second. Their cost curve follows your usage exactly, so passing it on *is* the margin. For them a hard ceiling is not stubbornness, it is a loss.

Our costs are mostly fixed: the machines are depreciated over years, the rack space is a monthly amount, the power is metered but predictable, and the transit is committed rather than per gigabyte. A customer who hits their ceiling costs us **capacity**, which we already paid for, rather than a purchase invoice we have to eat.

That is the entire mechanism. It is not clever and it is not a business model innovation — it is just a different balance sheet, and it is the reason we can write "you can only ever spend what you have already paid" without an asterisk after it.

```
  reseller cost model
  ├─ egress          per GB   → variable
  ├─ storage         per GB   → variable
  ├─ compute         per sec  → variable
  └─ a ceiling eats the margin

  cmdz cost model
  ├─ hardware        depreciated → fixed
  ├─ rack + power    monthly     → fixed
  ├─ transit         committed   → fixed
  └─ a ceiling costs capacity, not cash
```

[How the ceiling works](/hard-limit)

## What is actually in the rack

Boring, standard, and chosen so that nothing on this platform depends on a component we could not replace ourselves.

### Rocky Linux 10

Enterprise-grade, long-lived, and not owned by anyone whose licensing terms can change under us. Every node is identical and every node was installed the same way.

### k3s, driven from Postgres

The desired state of every customer workload lives in our database, and an idempotent reconciler makes the cluster match it. We never read "the truth" out of the cluster — on drift, the database wins, without exception.

### Kata micro-VMs

Every workload gets its own kernel. The isolation boundary is the hypervisor rather than a namespace, which is the point of the whole exercise.

### Replicated block storage

Volumes are replicated across nodes within the region, with snapshots to object storage. Losing a disk is a maintenance ticket, not an incident.

### LUKS with network-bound unlock

Full-disk encryption where the key is released by a service on the network at boot rather than stored on the machine. A disk that leaves the building is unreadable.

### One command per node

A bare machine becomes a cluster node with a single bootstrap command carrying a one-time token that says which region and cluster it joins. There is no snowflake server and no manual step to forget.

## We order hardware before you notice a queue.

Capacity is calculated per region against fixed thresholds — memory headroom, storage headroom, and enough margin to lose a node without losing the region. When a region crosses a threshold, the ordering advice says which region needs iron, and a region can be marked *limited* or *full* so no new environments land in it until it has been added.

That is deliberately unglamorous. The alternative — running hot and hoping — is how a platform ends up either throttling customers or asking them to move region on short notice, and we would rather buy a machine.

- **Thresholds per region**, not per fleet, so one busy region does not hide behind an empty one
- **Room to lose a node** built into the threshold, not into a runbook
- **Regions can be closed to new environments** rather than degraded
- **Off-site backups** of the control plane, in a different region than the one they describe

[Where the regions are](/regions)

## What owning the iron does not buy you.

It does not make us cheaper than Cloudflare at high request volume — nothing VM-based will be. It does not give us a global edge network, and it does not give us a data center in every jurisdiction you might one day need.

What it buys is a cost structure that can carry a ceiling, an isolation model we control end to end, and a support answer that comes from somebody who can physically reach the machine. If what you need is presence in twenty regions tomorrow, buy that from someone who has it.

[Read the full comparison](/hard-limit#competition)

## The ceiling is downstream of the rack.

Everything else on this site follows from the fact that we bought the machines.

- [Create account](https://app.cmdz.com/signup)
- [How the limit works](/hard-limit)
