Hosting & Data Residency

Fruxon runs as managed SaaS by default — you sign up, build agents, and ship them without operating any infrastructure. Every workspace picks a data region when it is created, and can separately restrict where its prompts may go when an agent calls a model. For teams that need more isolation than a shared platform can give, there are dedicated and customer-VPC models, up to running Fruxon entirely inside your own cloud.

This page covers the two residency controls every workspace has, where each class of data lives, key custody, and the deployment models. For the platform's encryption and access controls, see Building Secure Agents; for compliance posture (SOC 2, DPA, subprocessors) see fruxon.com/trust.

Two questions, two controls

Where data is stored and where data is processed are different questions, and Fruxon answers them with different controls. Storing a workspace's database in one region does not keep its prompts there: an agent that calls a vendor API sends the prompt wherever that vendor serves from.

Data region

Each Fruxon region is an independent, self-contained deployment — its own database, file storage, backups, encryption keys, and API host. When you create a workspace you choose its region from the Data region dropdown, and everything the workspace persists is created, stored, processed and backed up inside it.

More regions are opened as customers need them — talk to us if yours is not listed.

The region is available on every plan and is chosen once. There is no move: not self-serve, not by API, not by operator tooling. That is deliberate — a residency guarantee is only worth something if there is no path by which the data can leave, and an auditor's first question about any move feature is who can trigger it. If you need a workspace in a different region, create a new one there.

What the region pins:

• Database — the workspace's tables, partitioned per tenant, in a regional Cloud SQL instance.
• Files and attachments — a regional storage bucket.
• Backups — automated database backups are pinned to the same region, never a multi-region.
• Encryption keys — the key that wraps the workspace's credential-encryption key lives in the region (or in your own KMS, with BYOK).
• Processing — agent execution, background jobs, email, and knowledge-base ingestion run in the region's own services.

Inference residency

Every agent step calls a model through an AI provider config you define. Inference residency is a workspace-wide policy that restricts which of those configs may be used, based on where they send the prompt. Set it under Settings → Data residency → Where your prompts may go.

The settings are ordered by strictness, and tightening has a real cost. The in-region setting excludes any model served only globally — Gemini 3 and newer are global-only on Vertex, so a workspace on that setting cannot use them. Before you save a stricter setting, the page shows every published provider config that would stop resolving under it, so you can see the cost before you pay it.

How it is enforced:

• At publish time. A provider config that breaches the policy is refused when you try to publish it, with an error naming the provider and the reason.
• At run time. Every execution re-checks its configs against the current policy before it starts. This is the backstop for configs published before the policy existed and for policies tightened after publication — a rule enforced only on write would silently exempt everything already written.
• Per model. A config's location cannot answer for a model that Vertex overrides to the global endpoint at call time, so model ids are checked as well.
• Audited. Every change to the setting is recorded with who made it and when. The History tab on the same page shows the ledger.

Hosting models

Managed cloud (default)

The standard deployment. Your workspace lives in the region you chose, isolated by tenant, encrypted at rest, reachable only by your authenticated members, and subject to the inference residency you set. This is the right choice for the large majority of teams, including regulated ones whose requirement is residency rather than physical isolation.

Dedicated single-tenant

A deployment Fruxon operates exclusively for you, in an isolated cloud project and a region you choose — including regions Fruxon does not otherwise offer. You get the operational simplicity of managed SaaS with a hard tenancy boundary: no other customer's workload shares your database, your compute, or your project. Choose this when your requirement is isolation, not only residency.

Customer-VPC / self-hosted

Fruxon packaged to run inside your own cloud account (GCP / AWS) or data center, operated by your team. In this model your data and your encryption keys stay in your environment — Fruxon provides the software and does not operate, or have standing access to, a deployment you run. Inference residency is answered by construction: model calls originate from your network, to endpoints you choose.

Where your data lives

Whatever an agent processes is persisted so that monitoring, conversations, and evaluations work. Here is where each class of data sits in each model:

In a self-hosted deployment, none of this transits Fruxon. The only traffic that leaves your network is the LLM and integration calls you explicitly configure — and you choose where those go. Optional product analytics can be turned off for fully isolated deployments.

Encryption & key custody

Integration credentials, OAuth tokens, and secrets are sealed with tenant-scoped envelope encryption before they are stored — credential ciphertext lives in the database, and each tenant's data-encryption key is wrapped by a key-management service and unwrapped only inside the backend at the moment a tool call needs it. Plaintext never reaches prompts, traces, or logs. The full mechanism, including the per-sensitivity audit tiers, is described in Building Secure Agents → How credentials are protected.

Bring Your Own Key (BYOK). Enterprise customers can root that wrapping key in a key-management service they control, in any location their KMS supports. Because Fruxon can only unwrap your tenant key by calling your key, disabling or revoking it renders every credential Fruxon stored for you permanently unreadable — a cryptographic off-switch that stays in your hands. In a self-hosted deployment the key service, the database, and the keys are all in your environment by construction.

LLM and integration connectivity

Fruxon never resells inference — you bring your own provider keys, and token spend goes directly to your provider account.

• You choose the endpoint. Calls go to the provider you configure: a vendor API (OpenAI, Anthropic, Google), AWS Bedrock or Google Vertex in your own account, or a self-hosted / OpenAI-compatible model endpoint you run.
• You can enforce that choice. Inference residency turns "we only use our own cloud" from a team convention into a policy the platform refuses to breach.
• You choose the egress path for integrations. Integration calls support per-integration egress-country routing, so outbound traffic to a third-party API can be pinned to a specific jurisdiction independent of where the platform runs. In a self-hosted deployment, all of it originates from your network.

Together these let a regulated team keep data at rest, model traffic, and integration traffic each within a boundary they chose — and show an auditor the setting that enforces it.

Summary

Talk to us

Dedicated and self-hosted deployments, BYOK, new regions, and written residency commitments are arranged through an enterprise engagement.

• fruxon.com/trust — compliance posture, DPA, subprocessors, attestations
• Building Secure Agents — the platform controls you use to harden an agent
• Secrets and AI Providers — credential handling and bring-your-own-key