Deployment Flexibility

Run your SaaS wherever it makes business sense — without changing how you operate

SaaS companies increasingly need flexibility in where their software runs.
Customer expectations, regulatory requirements, and commercial models often dictate deployment location.

whitesky enables SaaS providers to deploy their software across multiple environments while keeping one operational model.

Three deployment models, one platform

whitesky supports three distinct deployment models for SaaS software.
All three are operated from the same portal and API.

Three deployment models, one platformOne portal and one API operate three deployment models for SaaS software: local deployment on infrastructure the SaaS company owns, federated deployment on whitesky locations hosted by Cloud Enablers in specific countries or regions (the SaaS company deploys there as a Virtual Cloud Operator of one Cloud Enabler), and customer-owned deployment in the customer's own datacenter under customer-controlled governance. Automation and lifecycle management stay the same in all three.One portal and one API1 LocalSaaS-ownedYour own whiteskyinfrastructurePrimary production,full cost control2 FederatedCloud Enabler locationsFederated whiteskylocationsSpecific countriesor regions3 Customer-ownedSaaS on-premCustomer datacenteror approved facilityCustomer-controlledgovernanceSame automation and lifecycle management in all three
Three deployment models, one platformOne portal and one API operate three deployment models for SaaS software: local deployment on infrastructure the SaaS company owns, federated deployment on whitesky locations hosted by Cloud Enablers in specific countries or regions (the SaaS company deploys there as a Virtual Cloud Operator of one Cloud Enabler), and customer-owned deployment in the customer's own datacenter under customer-controlled governance. Automation and lifecycle management stay the same in all three.One portal and one API1 LocalSaaS-ownedYour own whitesky infrastructurePrimary production, full cost control2 FederatedCloud Enabler locationsFederated whitesky locationsSpecific countries or regions3 Customer-ownedSaaS on-premCustomer datacenter or approved facilityCustomer-controlled governanceSame automation and lifecyclemanagement in all three
Three deployment models, operated from the same portal and API.

1) Local deployment — SaaS-owned infrastructure

In this model, the SaaS company has its own whitesky infrastructure, with the platform layer operated by whitesky as a managed service.

This is typically used to:

  • run the primary SaaS production environment
  • retain full control over capacity and cost
  • optimize performance and margins
  • operate a centralized SaaS platform

The SaaS provider owns the infrastructure and runs its SaaS on it, while whitesky operates the cloud platform.

2) Federated deployment — Cloud Enabler locations

whitesky supports a federated cloud model where Cloud Enablers (telcos, datacenters, hosters or MSPs that own hardware) host whitesky cloud locations and resell capacity to each other. A SaaS company deploying on federated locations does so as a Virtual Cloud Operator (VCO) of one Cloud Enabler: one contract and one invoice, yet access to every federated location.

SaaS companies can deploy their software:

  • on federated whitesky locations
  • in specific countries or regions
  • under local compliance or data residency requirements

This allows SaaS providers to:

  • expand geographically without building local infrastructure
  • meet customer or regulatory locality requirements
  • leverage trusted local Cloud Enablers

Federated deployment extends reach without fragmenting operations.

3) Customer-owned deployment — SaaS on-prem

Some customers require SaaS software to run inside their own environment.

With whitesky, SaaS providers can deploy their software:

  • on customer-owned whitesky infrastructure
  • in customer datacenters or approved facilities
  • under customer-controlled governance

From the SaaS provider’s perspective:

  • the deployment model remains the same
  • automation and lifecycle management remain consistent
  • operations do not need to be reinvented

This enables true SaaS-on-prem use cases without special architecture.

One operational model across all deployments

Regardless of where the SaaS software runs:

  • deployment is automated through one API
  • environments are managed from one portal
  • monitoring and lifecycle processes remain consistent
  • operational knowledge is reusable

Deployment location does not multiply operational complexity.

Why this matters for SaaS companies

Federated and local deployment enables SaaS companies to:

  • enter regulated or sovereign markets
  • support enterprise and public sector customers
  • avoid building regional infrastructure prematurely
  • offer on-prem SaaS without custom builds
  • maintain architectural consistency across environments

This flexibility becomes a competitive advantage rather than a burden.

Relationship to other SaaS topics

Federated & local deployment builds on:

  • Portable SaaS Architecture
  • Multi-Tenancy & Isolation
  • Cost Control & Economics
  • Security & Compliance

Together, these enable SaaS platforms that scale without losing control.

Next steps

  • Identify customer-driven deployment requirements
  • Decide which workloads belong in which environments
  • Automate deployment across locations
  • Design a multi-environment SaaS operating model on whitesky