Hosting & Data Residency
Where Fruxon runs, where your data lives, and the deployment models available for regulated and enterprise teams
Fruxon runs as managed SaaS by default — you sign up, build agents, and ship them without operating any infrastructure. For teams with stricter isolation, data-control, or residency requirements, there are more isolated models, up to running Fruxon entirely inside your own cloud.
This page describes those models, where each class of data lives, and how key custody and LLM traffic work across them. For the platform's encryption and access controls, see Building Secure Agents; for compliance posture (SOC 2, DPA, subprocessors) see fruxon.com/trust.
Hosting models
| Model | Who operates it | Where your data lives | Availability |
|---|---|---|---|
| Managed cloud (multi-tenant) | Fruxon | Fruxon's cloud, tenant-isolated and encrypted | All plans — the default |
| Dedicated single-tenant | Fruxon, in an isolated project | A dedicated, region-pinned environment Fruxon runs for you | Enterprise engagement |
| Customer-VPC / self-hosted | You | Entirely inside your own cloud or data center | Enterprise engagement, scoped per deployment |
Managed cloud (default)
The standard deployment. Every organization is isolated by tenant, data is encrypted at rest, and only your authenticated members can reach it. The region depends on your plan. This is the right choice for the large majority of teams.
Dedicated single-tenant
A deployment Fruxon operates exclusively for you, in an isolated project and a region you choose. You get the operational simplicity of managed SaaS with stronger isolation and residency guarantees, without running infrastructure yourself.
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.
Self-hosted and customer-VPC deployments are delivered as an enterprise engagement, not a self-serve download. The exact topology — networking, key custody, identity, and which optional components you run — is scoped with our team per deployment. If this is a requirement, contact sales to start the conversation.
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:
| Data | Managed / dedicated | Customer-VPC / self-hosted |
|---|---|---|
| Prompts & agent instructions | Fruxon's cloud, encrypted, your region | Your environment |
| Conversations & sessions | Fruxon's cloud, encrypted | Your environment |
| Run traces & observability | Fruxon's cloud, encrypted | Your environment |
| Knowledge-base content & embeddings | Fruxon's cloud, encrypted | Your environment |
| Files & artifacts | Fruxon's cloud, encrypted | Your environment |
| Integration credentials | Fruxon's cloud, encrypted (see below) | Your environment |
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. 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 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 cloud LLM (OpenAI, Anthropic, Google), AWS Bedrock or Google Vertex in your own account, or a self-hosted / OpenAI-compatible model endpoint you run.
- You choose the egress path. In a self-hosted deployment, LLM calls originate from your network. For managed deployments, integrations support per-integration egress-country routing so outbound traffic can be pinned to a specific jurisdiction.
This is what lets a regulated team keep both LLM and integration traffic within a chosen boundary.
Data residency
- Managed cloud: region depends on your plan.
- Dedicated: data and encryption keys pinned to a region you choose.
- Customer-VPC / self-hosted: wherever you run it.
- Egress: per-integration country pinning keeps outbound integration traffic in-jurisdiction, independent of where the platform runs.
Talk to us
Dedicated and self-hosted deployments, BYOK, region pinning, and 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
- Contact sales via fruxon.com, or email
security@fruxon.comfor security and architecture questions