Deploy on your terms
Run Sfere in your own cloud account, on-premise, or fully managed, in the region you choose: residency and consent are governed at the data layer, so the boundary is enforced before data is activated
The rack builder
One stack, four addresses
The platform is the same five units wherever it runs: pick an address, watch the rack power up, and read who operates it, who holds the keys, and whether a vendor copy of your customer data exists anywhere (simulated rack, real trade-offs)
regulated records stay inside; heavy processing uses capacity you already own
rack at address 01: powered, all five units healthy, zero vendor copy detected
Four ways to run it, one platform
The same system runs in your cloud, on your servers, or fully managed: so residency, control, and speed are trade-offs you choose rather than accept. Deployment options are scoped per engagement
Your cloud (bring-your-own-cloud)
Deploy Sfere inside your own cloud account or private network, in the region you require. The platform runs on infrastructure you already govern, so it inherits your security policy instead of asking you to trust a new one
On-premise
Run the full stack on your own servers for maximum control. Fit it into a Kubernetes, container, or traditional server setup, and keep the most sensitive customer data behind your own perimeter
Sfere-managed
Prefer speed over infrastructure work? Run Sfere as a managed deployment under contract, in a region you choose, while keeping the residency and consent guarantees intact
Hybrid
Keep regulated records behind your own perimeter while heavier processing runs on cloud capacity you already own. The architecture doesn't care where each piece lands, so the split is yours to draw
Setup starts from what you already run
Point the platform at infrastructure you control, keep your own governance in place, and integrate the stack, security policy, and warehouse you already operate
-
01
Pick your infrastructure
Choose where the platform runs: your cloud account, on-premise, or Sfere-managed. Residency is a deployment decision made once, up front, not a region flag toggled after your data already left
-
02
Bring your own security
The deployment integrates with the security stack you already run: your key management, your identity provider, your network controls. Sfere fits inside your policy instead of replacing it
-
03
Compose with your warehouse
Point Sfere at your own analytical warehouse, or deploy the full stack alongside it with a zero-copy posture. Take only the components you need, the platform is composable, not all-or-nothing
-
04
Observe and update on your terms
Stream logs, metrics, and audit trails to your own monitoring tools, and take updates on a schedule that fits your change process rather than a vendor's release calendar
Data stays wherever your rules require
Where customer data lives is a deployment decision you make up front, enforced at the data layer from ingestion through activation
- Deploy in the region you choose so customer data stays there from ingestion onward
- The same platform runs across major cloud providers and on-premise, residency is a choice, not a limitation
- Single tenant by deployment: in your cloud account or on-premise, customer data sits in a dedicated environment, not shared infrastructure
- Because deployment is portable by design, moving regions is a configuration decision, not a re-platforming project
Control without the trade-offs
Most platforms make you choose between keeping data in your region and getting full capability: Sfere runs the full loop on infrastructure you govern
- Run in your own cloud account or private network, in the region you choose, with no vendor copy of your customer data
- On-premise for full control, or Sfere-managed when you want speed over infrastructure
- Data residency and consent governed at the data layer, not patched on top
- Warehouse-composable: point it at your own analytical warehouse and take only the components you need
How and where Sfere runs
Where can Sfere actually run?
In your own cloud account, on your own servers on-premise, or as a Sfere-managed deployment under contract. In every case you choose the region, so data stays wherever your rules require. Deployment is portable by design rather than tied to one provider
Do you get a copy of our customer data?
When you self-host in your own cloud or on-premise, no. The platform runs inside infrastructure you control, with your own keys, so there is no vendor copy of your customer data. If you choose the managed option, residency and access terms are set in the contract
Do we have to move off our existing warehouse or cloud?
No. The architecture is composable and infrastructure-agnostic: point Sfere at your own analytical warehouse and keep using the cloud you already run
Who operates the deployment, us or Sfere?
Your call. Self-host and your IT team keeps full control over security, access, and residency, with the platform integrating into your existing stack. Choose managed and Sfere runs the infrastructure while the residency and consent guarantees stay in place
Point us at infrastructure you govern
Book a walkthrough with your infra lead in the room. We'll scope the deployment model (your cloud, on-premise, managed, or hybrid) and the residency boundary that goes with it