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.
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.
| Element | In a cloister | In a GPU package | At Cloister Labs |
|---|---|---|---|
| Wall | The 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. |
| Walk | The 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. |
| Garth | The 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.
- 01
Enclose
The boundary is physical before it is logical. We rent whole machines, and we draw the line where the hardware draws it.
- 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.
- 03
Publish
Prices, incidents and data-handling rules are public documents, written for the person who has to approve the purchase.
- 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.
| Document | Where | Status |
|---|---|---|
| Hardware specification per configuration | GPU catalog | Published |
| Per-GPU-hour rate card with reserved terms | Pricing | Published · sample figures |
| Privacy architecture and attestation sequence | Security | Published |
| Data-handling rules | Security | Published |
| Incident reports with root cause | Status page | From general availability |
| Sub-processor list | Security | From general availability |
What we
will not do.
Written down so that you can hold us to it.
- 01
Place another customer's workload on a host you are renting.
- 02
Read, sample or train on the data and models you run with us.
- 03
Sell or share usage telemetry about your workloads.
- 04
Open a session on a running node without an approval you can see.
- 05
Quote a benchmark we cannot reproduce on the configuration you would buy.
- 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.