Isolated
One tenant per card for the whole rental. Your sandbox is scoped to the cards you rented, and neighbours cannot see in.
Your job runs alone on the card. The person who owns the machine cannot open a shell into it, and everything you wrote to disk is destroyed when the rental ends.
Start from the worry
Everything below answers one of these, ordered by what you came here afraid of rather than how we build it.
A card is allocated to one rental at a time: no time-slicing, no MIG partition shared with a stranger.
The layers
Your session sits inside an isolated container on the provider's machine. Launch brings up a fresh one, connect reaches it on your key alone, and stop destroys it with its volume. Pick a step to hold it there.
Launch. The provider's box starts a fresh container for this rental, nothing carried over from anyone before, and scopes exactly one card into it: card1. The other three cards stay outside your container, for other renters.
A diagram of the boundaries, not a live host. The card names and the blocked sshd are what a real rental showed on 2026-08-03. Kracht does not encrypt the provider's disk: the volume is destroyed at stop instead.
02Ciphertext by default
Between your machine and the box, this is all anyone on the way gets: noise. The key that turns it back into your file is your own SSH key, and its private half never leaves you. Follow one file there and back.
# train.py
import torch
model = load("support-model-v3")
data = open("tickets-2026-q3.jsonl")
for batch in data:
model.step(batch)Never shown, never sent. It stays on this machine.
Plain. Your file, as you wrote it.
Ciphertext. The same bytes, sealed by SSH. The relay forwards what it cannot read.
The public half only. It can check your key; it cannot act as it.
Plain again. On the provider's disk, which Kracht does not encrypt at rest.
Gone. Stopping the rental destroys its volume.
04Encryption
Hover a card to watch its surface resolve into ciphertext. Traffic is encrypted in transit, the database provider encrypts at rest, and every credential is stored as a hash. Customer-managed keys are not available yet, and this page will say so until they are.
Every byte between you, the control plane and the card moves over TLS, authenticated by a bearer token hashed at rest.
Stored data is encrypted at rest by our database provider. We do not roll our own cryptography.
Agent and account credentials live only as hashes; a leaked row reveals a hash, not a key.
Outbound network is off by default, so a compromised workload has nowhere to phone home to.
05What holds, every time
Not aspirations. Each of these is enforced by the system, not promised by a policy.
One tenant per card for the whole rental. Your sandbox is scoped to the cards you rented, and neighbours cannot see in.
TLS on every call, encrypted at rest by the database provider, and every credential stored only as a hash.
The container and its scratch volume are destroyed when the rental ends. Nothing of the workload survives.
Every euro and every state change lands in an append-only ledger, exact to six decimals and impossible to quietly rewrite.
06Compliance
We track the standards enterprises ask about, and label what is complete, in flight, planned, or still under review.
07Proven, dated
Every row is a thing that was run against the live stack, with the day it happened and where it is written down. Nothing here is a total or an uptime figure.
A GPU rental ran end to end on the 7900 XT: passthrough scoped to one card, the iGPU left out, failed sessions charged nothing, every hold released.
Money conserved to the microeuro across the first settlements: renter −0.009019, provider +0.007665, platform 15.01%.
Launch, meter and settle against the live stack, then the connect hop: a renter peered with the hub and read files out of the running container.
#37The worker settled a 27-tick rental under real load, and the provider agent survived a reboot and two control-plane redeploys, re-registering each time.
A renter SSHed into a GPU rental on the default image: one card scoped (card1, renderD128), /dev/kfd openable, the provider's own sshd blocked from inside.
#199Snapshot and restore end to end: a rental stopped with a snapshot, and a second rental restored from it served back the file the first one wrote.
#186A fresh Ubuntu 24.04 box provisioned through the documented one-liner installed the agent, built the instance image itself and kept a session off the host's sshd.
#155Read it, don't trust it
Everything above is a mechanism you can inspect. Everything below is the paper trail.
Knowledge base
Every claim on this page, written up and searchable, linking to the section or the policy that proves it.
TLS on every call, encrypted at rest by our database provider, credentials stored only as hashes.
The container and its scratch volume are destroyed at the end of every rental.
Row-level security scopes every row to the account that owns it.
Bearer tokens authenticate each call, are hashed at rest, and are never echoed back.
Report in good faith, get a human reply, and credit if you want it.
How a report is triaged, and what happens after you send it.
No. There is no SOC 2 report and no ISO certificate today, and readiness work is in progress. That is the honest answer, and a page about security is the worst possible place to give any other kind.
Rent on-demand compute by the second, or list idle hardware and let it pay for itself. Same marketplace, both directions.
No card required