Deploy on your terms.
Run Sfere in your own cloud, on-premise, or fully managed: with Saudi fan data kept in-Kingdom. 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 and watch the rack power up: then read the status panel: who operates it, who holds the keys, and whether a vendor copy of your fan base exists anywhere. Simulated rack; the trade-offs are real.
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 fan 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.
In-Kingdom, or wherever your rules require
Where fan data lives is a first-class deployment constraint. Saudi fan data stays inside the Kingdom for PDPL: enforced at the data layer from ingestion through activation.
- Deploy in-Kingdom so Saudi fan data stays inside the Kingdom from ingestion onward.
- The same platform runs across major cloud providers and on-premise, residency is a choice, not a limitation.
- In-Kingdom cloud availability keeps expanding across the Kingdom; on-premise and private-network deployments are the options we scope first.
- Because deployment is portable by design, moving regions is a configuration decision, not a re-platforming project.
Sovereignty without the trade-offs
Most platforms make you choose between control and convenience: keep data in-Kingdom and lose capability, or get capability and give up control. Sfere gives you the full loop on infrastructure you govern.
- Run in your own cloud account or private network, in the region you require, no vendor copy of your fan base.
- On-premise for full control, or Sfere-managed when you want speed over infrastructure.
- In-Kingdom data residency and PDPL 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 can stay in-Kingdom or wherever your rules require. Deployment is portable by design rather than tied to one provider.
Do you get a copy of our fan 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 offshore vendor copy of your fan base. 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-prem, managed, or hybrid: and the residency boundary that goes with it.