Overview / Company

A court with
a wall around it.

A cloister is an enclosed courtyard: a wall, a covered walk inside it, and an open court at the centre that is quiet because nobody passes through. Draw an accelerator from above and you get the same plan. We named the company after the drawing.

Plan of a cloister: a hatched outer wall with one doorway, a covered walk lined by columns, and a garden court with crossing paths and a central wellA1B2C3D4GARTHWALKWALLDOOR
Fig. 1 Cloister, plan. Typical layout, not a specific building.
Plan of an accelerator package on the same grid: substrate edge, memory stacks, and the compute die at the centreA1B2C3D4TENANT BOUNDARYSUBSTRATE
Fig. 2 Accelerator package, plan on the same grid. Schematic.

Grid references match: at C-2 the garth's edge meets the die's; at A-1 the cloister wall becomes the tenant boundary.

One plan,
three readings.

The analogy is not decoration. It is the specification we design to: every part of the service has to sit inside a boundary that belongs to one customer.

Each element of the plan read as a cloister, a GPU package and Cloister Labs
ElementIn a cloisterIn a GPU packageAt Cloister Labs
WallThe outer wall. One door, kept by someone who knows who is inside.The substrate edge. Everything the accelerator is sits inside it.The tenant boundary — a whole host, rack or cage that only you occupy.
WalkThe covered arcade between the wall and the court.The memory stacks around the die, feeding it.Storage, network and keys that serve your workload and nobody else's.
GarthThe open court at the centre. Quiet because it is enclosed.The compute die.Your model, weights and data while they run.

Four principles.

The operating rules that follow from them are on the overview sheet.

  1. 01

    Enclose

    The boundary is physical before it is logical. We rent whole machines, and we draw the line where the hardware draws it.

  2. 02

    Name

    Say exactly what you are buying: the accelerator, the CPU, the chassis, the port speed. A vague product is a product with something to hide.

  3. 03

    Publish

    Prices, incidents and data-handling rules are public documents, written for the person who has to approve the purchase.

  4. 04

    Prove

    Where hardware can attest to its own state, you should be able to check it yourself instead of taking our word.

What we
publish.

An infrastructure provider should be auditable from the outside. This is the register of documents we keep public, and when each one starts.

Register of public documents
DocumentWhereStatus
Hardware specification per configurationGPU catalogPublished
Per-GPU-hour rate card with reserved termsPricingPublished · sample figures
Privacy architecture and attestation sequenceSecurityPublished
Data-handling rulesSecurityPublished
Incident reports with root causeStatus pageFrom general availability
Sub-processor listSecurityFrom general availability

What we
will not do.

Written down so that you can hold us to it.

  1. 01

    Place another customer's workload on a host you are renting.

  2. 02

    Read, sample or train on the data and models you run with us.

  3. 03

    Sell or share usage telemetry about your workloads.

  4. 04

    Open a session on a running node without an approval you can see.

  5. 05

    Quote a benchmark we cannot reproduce on the configuration you would buy.

  6. 06

    Change the rate of a reserved term once it has been signed.

Write to the people who run the hardware.

Working here
We're not hiring publicly yet. If you build or operate GPU infrastructure and this page reads like something you'd sign, write to hello@cloisterlabs.com.
Everything else
Capacity, security reviews and partnerships reach an engineer, not a sales sequence.
Contact