Regions & data sovereignty

Porten is built to be EU-sovereign: the Hub and the nodes it routes to run on European-owned infrastructure, not the EU regions of US-owned clouds. If data residency matters to you, this is the point of the project.

Region-pinned API keys

An API key can be restricted to one or more regions. A request made with that key only routes to nodes in those regions; if none can serve the model there, you get a clear error rather than a silent fall-back to another region.

• Set a key's regions in the portal under API keys.
• A request that can't be satisfied within the key's allowed regions returns 403 model_not_allowed or 404 model_not_found (no eligible node), never a cross-region route.

Node trust classes

Nodes carry an operator-assigned trust class (e.g. community, verified, trusted, confidential). A key's policy can require a minimum class, so sensitive workloads only land on vetted nodes. Region and class are operator-authoritative — a node can't self-declare them — so routing guarantees like "EU-only, trusted-only" hold.

What's logged

Usage is metered per request (model, token counts, timestamp) for billing and abuse prevention. Prompt and completion content is not part of the durable usage record. See the portal's account and usage views for what's retained.

If you're evaluating Porten for a regulated workload, the combination of region-pinned keys + minimum node class is the mechanism that keeps inference on infrastructure you trust.