Home/Sovereignty
Region pinning is not an interface filter but a mandatory check on the server side. This page explains how that check works, which legal framework it sits in, and how much of it has actually been written today.
This text is explanatory, not a legal document. The binding texts live under /en/yasal/.
Enforcement
A constraint that only exists in the interface is not a constraint: anyone calling the API directly walks past it. That is why the region pin sits inside the pod creation path.
The organisation's region preference is set during the first setup (EU + TR, for example). This is not a user setting but a constraint written into the organisation's record.
Search is filtered with region_group and country_codes. That step is for convenience; it is not a security boundary and is no guarantee on its own.
When a pod request arrives for an offer outside the pin, the request is rejected: 400 · invalid_argument · region_pin_violation. It makes no difference whether it came from the console, the CLI or raw curl.
Every pod carries its region pin information in its own body: whether it is pinned, to which region, with which note. An audit question is answered with a record, not a screenshot.
# Organisation pin: eu_tr # Request: an offer outside the pin (example) POST /v1/pods { "offer_id": "provider-us-west-4090" } 400 Bad Request { "error": { "code": "invalid_argument", "reason": "region_pin_violation", "message": "This offer is outside the organisation's region pin.", "details": { "pin": "eu_tr", "offer_country": "US" } } } # When the console sees this reason it shows it # together with a KVKK/GDPR explanation.
Regions
The list of target regions is below. In Phase 0 supply comes from third-party providers' APIs; our own host network arrives in Phase 1. So being able to select a region today does not mean there is a machine in that region at that moment — the real state of the pool is visible in the console.
The region group is a single parameter in the API; the same constraint is applied identically in the console, in the CLI and in a raw HTTP request.
Legal framework
What follows is how the regulation shows up in the product; these are not commitment texts but the reasoning behind design decisions.
Under KVKK (Turkey's personal data protection law), transferring personal data out of Türkiye is a regulated act. The TR region pin exists so that the workload and the persistent disk stay in Türkiye; identity data is likewise kept on our own infrastructure, not in a US-based identity service.
With an EU region pin the data is processed inside the EU. Our obligations as a processor — processing on instructions, sub-processor transparency, breach notification, deletion and portability rights — will be bound into the contract text.
As an infrastructure provider we do not supply the model; we supply compute. Most of the obligation sits with the model provider and the deployer, but the record of which workload ran in which region is part of your file — and we produce that record.
The DPA and sub-processors
The DPA writes down the boundary between the controller (the customer) and the processor (Kaldera): what we process on which instructions, how long we keep it, within how many hours we report a breach, and how we return or destroy the data when the contract ends. Once the company is incorporated and the text is finished with a lawyer, it will be published under the legal texts and signed with institutional customers.
A sub-processor is a third party that touches the data on our behalf: the provider hosting the control plane, the payment institution, the email service and the GPU providers where the workload runs. The rule will be this: the list is kept public, changes are announced in advance, and your right to object is written into the contract. There is no published list today — because there is no signed contract yet either.
The planned stack is written out plainly in the technical plan: the control plane will be hosted in the EU, identity will be kept in our own database, and on the supply side EU-incorporated providers will be preferred. These are stack decisions; they are not signed supplier contracts.
A structural difference
The US CLOUD Act governs when a service provider subject to US law can receive a demand relating to data in its possession or control. The decisive factor is not which country the data physically sits in, but which legal system the entity holding the data is subject to. That is why "the server is in Frankfurt" is not an answer on its own; the whole question is: whose law is the company that can reach this data subject to?
The structure Kaldera is aiming at answers that question with EU and Turkish legal entities. To be honest, here is the picture today:
When we make comparisons we describe only structural differences that anyone can verify: where a provider's legal entity sits, in which region the data is processed, and whether the region constraint is enforced on the server or only in the interface. An unverifiable negative claim about a competitor has no place on this site.
Data portability and deletion
Lock-in is not a business model. Getting your data out and deleting it was designed to take as few steps as starting it.
Persistent disks are S3-compatible and kept in a form readable with standard tools; you take your checkpoints and outputs out without converting them into a proprietary format. Invoice line items are readable from the API too — your accounting is not condemned to screenshots.
If you pass ?delete_volume=1 when terminating a pod, the persistent disk is deleted too. Deleting all workload data on account closure, and putting retention periods in writing, will be a matter for the DPA.
How long is the disk of a pod paused by the budget cap or a balance issue kept free of charge? The draft policy leans towards 7 days free, storage charges after that, and deletion with notice at the end of 30 days — but the decision is not final, so we do not write it here as if it were.
This page is an explanatory text; it has no legal force. The binding texts — terms of use, the privacy and KVKK notice, the distance sales agreement — are published in the legal section, are drafted under Turkish law, and prevail in case of conflict.
Your call
The boundary of your data is protected on the server side; the boundary of your invoice is set by you. You don't pay for seconds that don't work, a hard budget cap, per-second billing.