Evaluating Flexday AI
Deployment options and data residency
Flexday-hosted SaaS or a dedicated deployment in your own AWS or Azure account - what you control in each, where data lives, and workspace app addresses.
- Everyone
Last reviewed
Flexday AI runs in two ways. In Flexday SaaS your organisation has a workspace on infrastructure Flexday operates. In a dedicated deployment the same platform runs in a cloud account of your own, on AWS or on Azure, and serves only your organisation. The application is the same in each. What changes is who operates the infrastructure, whose cloud account holds the data, which region it is in, and how much of the configuration you set. This page compares the options for a buying committee; the service-by-service detail is on the Deployment models page and the two reference deployments.
At a glance
- One application. The same code and services run in every option; only configuration differs.
- Data stays in the deployment's region. Every data store a deployment creates is in one cloud region, and the infrastructure code defines no copy to another region (the Azure development environment's database is the exception, in East US 2).
- Outside services are the exception. Calls to an AI model provider, an identity provider or a connected business application go to wherever that service runs.
- Your own addresses. A workspace can have its own apps address on Flexday SaaS, and a dedicated deployment runs on a domain you own.
The options
| Flexday SaaS | Dedicated on AWS | Dedicated on Azure | |
|---|---|---|---|
| Where it runs | Flexday's AWS account, on the reference deployment: ECS Fargate, Aurora PostgreSQL, ElastiCache and S3 | Your AWS account, from the same infrastructure code | Your Azure subscription, from the Azure Terraform (a development environment so far), using the platform's Azure drivers for storage and sign-in, and for models where Azure AI Foundry is configured, with the deployment's own secrets in Key Vault |
| Region | US East (N. Virginia), as defined in the infrastructure code | US East (N. Virginia), as the infrastructure code is written; another region means adapting it | The region you choose |
| Kept apart from other customers by | Row-level security in a shared database, and workspace-prefixed storage keys | A deployment of its own | A deployment of its own |
| Studio sign-in | Pooled sign-in, a dedicated user pool, or your own single sign-on | Amazon Cognito, Microsoft Entra ID, or your own OpenID Connect or SAML provider | Microsoft Entra ID, in the Azure reference deployment |
| Keys and secrets | Platform keys held by Flexday; Secret Variables sealed, as the infrastructure code is configured, in Flexday AI's encrypted storage under your workspace's own key | Keys and secrets created in your account | A Key Vault in your subscription |
| AI model provider | Flexday's model-provider accounts | The provider keys the deployment is configured with | The provider keys the deployment is configured with, including your own Azure AI Foundry |
| Addresses | The Studio on Flexday's domain; each workspace's apps on its own address where the deployment publishes one | A domain you own | A domain you own |
| Releases | Rolled by Flexday | Rolled through a deployment pipeline: database changes first, then each changed service | Rolled by the operator: database changes first, then each changed Container App |
What you control
| Decision | Flexday SaaS | Dedicated deployment |
|---|---|---|
| Region | No: the hosted service's region | Yes. On Azure it is a setting; the AWS infrastructure code is written for US East (N. Virginia), so another AWS region means adapting it |
| Network | No | Yes: the deployment's own network in your account |
| Identity provider for builders | Yes: pooled, dedicated pool or your own provider | Yes |
| Identity provider for the people who use what is built | Yes, per Solution | Yes, per Solution |
| Encryption keys for the database and files | No | They are created in your account (on the Azure reference deployment, Microsoft-managed keys); supplying a key of your own is not supported in this release |
| Where Secret Variables are sealed | No: the hosted service's own setting (as configured, Flexday AI's encrypted storage under your workspace's key) | Yes: Flexday AI's encrypted storage, or a vault in your account (Secrets Manager on AWS; Key Vault on Azure once the deployment is set to use it and its services can write to the vault, which the Azure infrastructure code, as written, does not do) |
| AI models | Yes, per use case, from the catalog the deployment offers | Yes, including which provider accounts are used |
| Who can reach the Admin Console, the staff console | No: Flexday staff | Whoever operates the deployment configures its staff sign-in (on Azure, staff sign in through the same Entra app registration as builders) |
| When a new release arrives | No | Whoever operates the deployment decides |
Data residency
By default, the infrastructure code puts every store a deployment creates (the PostgreSQL database, the object storage for apps, files and documents, the shared file system, the cache and the backups) in that deployment's region. Neither cloud's infrastructure code, as configured, defines a cross-region copy: no replication of object storage, no global database, and no backup copied to another region (on Azure, geo-redundant database backup is a setting, off by default).
Some processing happens where an outside service runs, and only when a feature uses it:
- AI model calls go to the model provider's endpoint: Anthropic's API for Claude models, or the Azure AI Foundry resource the deployment is configured with.
- Sign-in is checked against your identity provider.
- Integrations and Teams reach ServiceNow or Microsoft's services when a Solution uses them.
- Email goes to your own mail server where a Solution uses one, and otherwise to the mail service the deployment is configured with: Amazon SES in US East (N. Virginia) in Flexday's environments, the Azure reference deployment included.
What each of these receives is listed in Data protection and privacy. Where your data must stay in one country or region, ask Flexday which regions it can host in, and where each model provider processes requests.
Workspace app addresses
Generated apps and gateway endpoints are served on an apps address, separate from the Studio and the
API. A deployment can give each workspace its own apps address, of the form
<workspace>.apps.<domain>, so the people using an app see your organisation's name in its address. On
that address the workspace is taken from the address itself, and an address that names no workspace is
refused rather than served as another workspace's app. Every older link on the shared apps address keeps
working. In a dedicated deployment, <domain> is a domain you own. See
Addresses and domains.
Choosing
| If you need | Consider |
|---|---|
| To start quickly, with no infrastructure to run | Flexday SaaS |
| Secrets held in a vault in your own cloud account | A dedicated deployment in your AWS account or Azure subscription (the shared service has no option to point at your own vault) |
| Data in a region you choose, in an account you control | A dedicated deployment on AWS or Azure (on AWS, a region other than US East means adapting the infrastructure code) |
| An existing AWS estate with Cognito or your own single sign-on | A dedicated deployment on AWS |
| An existing Microsoft estate with Entra ID and Azure AI Foundry | A dedicated deployment on Azure |