> For the complete documentation index, see [llms.txt](https://knowledgebase.fabricdata.com/studio/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://knowledgebase.fabricdata.com/studio/getting-started/multi-tenancy-and-environment-model.md).

# Multi-Tenancy & Environment Model

### What is multi-tenancy?

Origin Studio is a **multi-tenant SaaS platform**. This means all clients share the same underlying application infrastructure — the same servers, the same codebase, the same database engine — while each client's data and configuration is completely isolated within their own **tenant**.

A tenant is a logically separated workspace within Origin Studio. Think of it as your private workspace: your metadata, your workflows, your users, and your configuration all live inside your tenant. No other client can see or access your data, and you cannot see theirs.

#### Why multi-tenancy is better for you

Multi-tenancy is not a compromise — it is a deliberate architecture choice that directly benefits every client on the platform.

**You always run the latest, most secure version.** In a dedicated-environment model, clients often fall behind on updates because each environment must be upgraded individually. With multi-tenancy, every client is always on the same version. When we fix a bug or patch a vulnerability, you get it immediately — not weeks later when someone schedules your upgrade. There is no version drift, no "we'll update your instance next quarter."

**You benefit from every improvement we make, for any client.** When we optimise search performance for a client with a 500,000-title catalogue, that improvement lands for everyone. When we harden an API endpoint based on an enterprise client's security audit, every client gets that hardening. The platform gets better for all clients with every release, not just the one who asked for the change.

**Your environment is production-grade from day one.** Your tenants run on the same infrastructure, with the same monitoring, the same redundancy, and the same operational support as every other client — including our largest enterprise accounts. There is no "lite" tier or "staging-quality" environment. Every tenant is a production tenant.

**Faster feature delivery.** Because we maintain one codebase and one infrastructure, our engineering team ships features faster than they could if they were managing dozens of separate environments. New features reach you in weeks, not months.

**Lower total cost.** Shared infrastructure means operational costs are distributed across all clients rather than borne individually. This translates to better pricing without sacrificing quality, reliability, or security.

#### How your data stays isolated

Data isolation in a multi-tenant system is enforced at the application and database level. Every query, every API call, every background job is scoped to your tenant. There is no scenario in which a request from one tenant can return or modify another tenant's data. This isolation is validated continuously through automated testing and monitoring.

If your organisation has specific compliance or regulatory requirements around data residency or isolation, your Fabric Reps (Strategic Account Manager, Customer Success Manager, Support team) can walk you through our security architecture and certifications in detail.

***

### Your tenants

Every client on Origin Studio receives **at least two tenants**. All of your tenants run on **the same Origin Studio production infrastructure** — there is no separate "staging server" or lower-tier environment. Your staging tenant and your live tenant are neighbours on the same platform, with the same performance, reliability, and security guarantees.

| Tenant                                         | Purpose                                                                                                               | Audience                                                                                                        |
| ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| **UAT tenant**                                 | Preview and test the upcoming features and check your end-to-end processes before changes reach your live environment | Your team (and, for enterprise clients, your designated testers)                                                |
| **Live (or Production) tenant**                | Your production environment — the one your day-to-day operations run on                                               | All of your users                                                                                               |
| **Additional tenant(s)** — **e.g. Dev tenant** | Any other tenants needed based on your agreement --development, or additional sandbox purposes                        | Your team (as agreed with your Fabric Reps (Strategic Account Manager, Customer Success Manager, Support team)) |

Because all tenants live on the same production infrastructure:

* **Bug fixes and security patches are delivered automatically to all tenants.** You do not need to take any action, schedule a window, or provide sign-off for these. When we fix a bug or patch a vulnerability, it reaches your staging and live tenants as part of the normal release cycle — no intervention required.
* **New features are different.** New features are deployed behind feature flags, which means the code is on the platform but invisible until we turn the flag on for your tenant. Your staging tenant receives new features first so you can preview and validate them. Your live tenant is only enabled after staging validation is complete.
* **In the future, you will be able to manage feature rollout yourself.** We are building self-service feature management capabilities that will give you direct control over when new features are enabled on your live tenant. Until then, feature enablement is coordinated through your Fabric Representatives or follows the standard release schedule.

The key distinction is:

| Change type          | How it reaches your tenants                                                                      | Action required from you                                                                                                       |
| -------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ |
| **Bug fixes**        | Automatically, as part of the regular release cycle                                              | None                                                                                                                           |
| **Security patches** | Automatically, may be expedited outside the regular cycle                                        | None                                                                                                                           |
| **New features**     | Deployed behind a feature flag; enabled on your staging tenant first, then live after validation | Review on staging, then sign off (enterprise) or automatic rollout (standard)                                                  |
| **Data migrations**  | Executed per-tenant with validation; communicated in advance if client impact is expected        | Enterprise: agree a migration window with your Fabric Reps (Strategic Account Manager, Customer Success Manager, Support team) |

#### Why multiple tenants?

Having a dedicated staging tenant means you can:

* **Preview new features** in a production-grade environment before they affect your live operations
* **Test integrations** (API consumers, downstream systems) against upcoming changes

Your staging tenant is not a lower-quality or less reliable environment. It is a full production tenant — it simply receives new features earlier so you have time to review them.

***

### How changes reach your tenants

Origin Studio follows a structured release process with three distinct steps: **deployment**, **migration**, and **enablement**. Understanding the difference matters because it explains why you may see changes at different times and how we ensure stability.

#### Step 1 — Deployment

Deployment is when new code is shipped to the Origin Studio production infrastructure. A deployment may contain a mix of bug fixes, security patches, and new features.

* **Bug fixes and security patches** take effect immediately across all tenants. These are not behind feature flags — they are applied automatically because they improve stability, security, or correctness for everyone.
* **New features** are deployed behind feature flags — switches that control which tenants can access which features. The code is on the platform, but the feature remains invisible until the flag is turned on for your tenant.

You do not need to take any action for a deployment to happen. Deployments are managed entirely by the Origin Studio team.

#### Step 2 — Migration (when applicable)

Some features require changes to how data is structured, indexed, or stored. When this is the case, Origin Studio runs **data migrations** — carefully sequenced operations that update your tenant's data to work with the new functionality.

Migrations are:

* **Planned and communicated** in advance 
* **Validated** before and after execution to confirm data integrity

Not every release involves a migration. When one does, your Fabric Reps (Strategic Account Manager, Customer Success Manager, Support team) will let you know what to expect, including estimated duration and any temporary impact.

#### Step 3 — Enablement

Enablement is when the feature flag is turned on for your tenant, making the new functionality visible and available to your users.

**Currently**, enablement is managed by the Origin Studio team on your behalf. The process follows a tiered approach:

1. **Your staging tenant is enabled first.** This allows your team to review the feature, test workflows, and confirm everything works as expected with your data and configuration.
2. **Your live tenant is enabled after you have reviewed and approved the change in staging.**

The critical rule: **a feature is never enabled on your live tenant until it has been validated on your staging tenant.** If a migration was involved, the migration must also be confirmed as successful before enablement.

**What's coming:** We are building self-service feature management capabilities that will give you direct control over enablement. Once available, you will be able to enable or disable new features on your tenants yourself — on your own schedule, at your own pace. Until then, your Fabric Reps (Strategic Account Manager, Customer Success Manager, Support team) coordinates all feature enablement on your behalf.

***

### The release timeline from your perspective

Here is what a typical release cycle looks like from a client's point of view:

| When                         | What happens                                                                                                                      | What you need to do                                                      |
| ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| **1–2 weeks before release** | New features are being validated internally by the Origin Studio team                                                             | Nothing — this is handled by our engineering and QA teams                |
| **Release day**              | Code is deployed to the production infrastructure; migrations run (if applicable)                                                 | Nothing yet — changes are behind feature flags                           |
| **Staging enablement**       | The feature is turned on in your **staging tenant** based on your go/no-go.                                                       | Review the feature, test your workflows, confirm it works with your data |
| **Sign-off**                 | You confirm you are happy with the change to your Fabric Reps (Strategic Account Manager, Customer Success Manager, Support team) | Provide sign-off or raise any issues                                     |
| **Live enablement**          | The feature is turned on in your **live tenant**                                                                                  | Your users can now access the new functionality                          |
| **After release**            | Updated documentation, release notes, and help articles are published                                                             | Review at your convenience                                               |

***

### Frequently asked questions

#### Is my staging tenant a separate system from my live tenant?

Both tenants run on the same Origin Studio production infrastructure. They are logically isolated — separate data, separate configuration, separate feature flags — but they share the same underlying platform. This means your staging tenant has the same performance, reliability, and security as your live tenant.

#### Can I use my staging tenant for testing at any time?

Yes. Your staging tenant is always available. Outside of release windows, it mirrors the same feature set as your live tenant. During a release cycle, it may have upcoming features enabled ahead of your live tenant so you can preview them.

#### Will I experience downtime during a release?

Most releases are **zero-downtime**. Code deployments and feature enablements happen without interruption. In rare cases where a data migration requires a brief maintenance window, your Fabric Reps (Strategic Account Manager, Customer Success Manager, Support team) will schedule this with you in advance and provide an estimated duration.

#### How do I know what changed in a release?

Every deployment includes a changelog published to the Origin Studio help centre. Every feature releases, your Fabric Reps (Strategic Account Manager, Customer Success Manager, Support team) may also provide a personalised summary for you with a demo when needed. Release notes follow a simple structure: **New** (new features), **Improved** (enhancements to existing features), and **Fixed** (bug fixes).

#### What about urgent fixes?

Critical issues (security vulnerabilities, data integrity risks, or production-breaking bugs) are addressed through a **hotfix process** that can be deployed outside the normal release cycle. Hotfixes are minimal in scope and follow the same validation and communication process, just on an accelerated timeline.

***

### Glossary

| Term               | Definition                                                                                                               |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------ |
| **Tenant**         | A logically isolated workspace within Origin Studio containing your data, users, and configuration                       |
| **Staging tenant** | Your preview environment — receives new features first so you can test before going live                                 |
| **Live tenant**    | Your production environment — where your day-to-day operations run                                                       |
| **Multi-tenancy**  | An architecture where multiple clients share the same application infrastructure while maintaining strict data isolation |
| **Feature flag**   | A switch that controls whether a specific feature is visible and available to a given tenant                             |
| **Deployment**     | Shipping new code to the Origin Studio infrastructure (invisible to clients until enabled)                               |
| **Migration**      | Updating data structures, indexes, or stored data to support new functionality                                           |
| **Enablement**     | Turning on a feature flag for a specific tenant, making the feature available to that client's users                     |
| **Release cycle**  | The bi-weekly process through which new features, improvements, and fixes are delivered to clients                       |