Multi-Workspace / Tenant Isolation Architecture for floci-ui

[fredpena]

Overview

Currently, floci-ui supports multiple cloud providers through a provider switch mechanism (AWS, Azure, and future GCP support), allowing users to dynamically interact with different cloud ecosystems from a unified interface.

The next architectural step is introducing isolated environments/workspaces similar to what major cloud providers offer:

• AWS → Accounts / Organizations

• Azure → Tenants / Subscriptions

• GCP → Projects / Organizations

The goal of this discussion is to define:

• the abstraction model

• the isolation boundaries

• the user experience

• the provider mappings

• and the initial implementation scope

before any major implementation begins.

---

Why This Matters

Real cloud environments are rarely single-context systems.

Users typically manage:

• multiple environments

• multiple teams

• multiple companies

• multiple isolated configurations

• multiple credentials

• multiple billing scopes

• multiple regions/accounts/projects

Without a workspace isolation model, floci-ui may become difficult to scale for real-world usage patterns.

---

Proposed Concept

Introduce a provider-agnostic abstraction layer tentatively called:

• Workspace

• Tenant

• Project Space

• Cloud Space

• Environment

(Needs discussion)

This abstraction would represent an isolated execution/configuration boundary inside floci-ui.

Example:

floci-ui
 ├── Workspace: Production
 │     ├── Provider: AWS
 │     ├── Credentials
 │     ├── Region Config
 │     └── Services
 │
 ├── Workspace: Development
 │     ├── Provider: Azure
 │     └── Config
 │
 └── Workspace: Customer-A
       ├── Provider: AWS
       └── Config

---

Key Discussion Points

1. Naming

What should the abstraction be called?

Options:

• Workspace

• Tenant

• Project

• Environment

• Cloud Space

• Context

Important:
The naming should remain provider-agnostic.

---

2. Isolation Scope

What exactly should be isolated?

Potential isolation boundaries:

• credentials

• regions

• provider configuration

• service state

• emulator state

• runtime containers

• logs

• telemetry

• local storage/cache

• UI state/preferences

Question:
Should workspaces behave like "lightweight profiles" or "fully isolated cloud environments"?

---

3. Provider Mapping

How should floci-ui internally map cloud provider concepts?

floci-ui | AWS | Azure | GCP -- | -- | -- | -- Workspace | Account | Subscription | Project

Is this enough?
Or do we need additional hierarchy support later?

Examples:

• AWS Organizations

• Azure Management Groups

• GCP Folders

---

4. Runtime Isolation

Should each workspace have:

• its own floci-core instance?

• isolated containers/processes?

• isolated adapter pipelines?

• isolated persistence?

Or should isolation initially remain logical/UI-level only?

---

5. Scope of v1

Suggested v1 scope:

• create/edit/delete workspaces

• provider selection per workspace

• isolated credentials/configuration

• isolated local state

• workspace switcher in UI

• persistent workspace sessions

Potentially OUT OF SCOPE for v1:

• RBAC

• multi-user collaboration

• organization hierarchy

• billing simulation

• distributed isolation

• cross-workspace networking

---

6. UI/UX Discussion

Potential UX ideas:

• top-level workspace selector

• provider badge

• recent workspaces

• color-coded environments

• quick switch support

• provider-aware navigation

• isolated tabs/sessions

Question:
Should users be able to open multiple workspaces simultaneously?

---

7. Persistence Model

How should workspace configuration be stored?

Options:

• local filesystem

• embedded database

• provider-specific config

• encrypted credential storage

---

8. Future Considerations

Possible future roadmap:

• Workspace templates

• Team collaboration

• RBAC

• Shared environments

• Cloud federation

• Cross-workspace observability

• Workspace snapshots/import/export

• Remote workspace execution

• Kubernetes-backed isolation

---

Goals of This Discussion

This issue is intended to:

• align architecture decisions early

• avoid provider-specific coupling

• define clear isolation boundaries

• establish naming conventions

• define MVP scope

• prevent future breaking refactors

---

Non-Goals

This discussion is NOT about:

• implementing RBAC

• enterprise billing

• distributed orchestration

• SaaS tenancy

• authentication providers

• production-grade security models

Those can be discussed in future RFCs/issues.

---

Open Questions

1. What should the abstraction be called?

2. How deep should isolation go in v1?

3. Should runtime isolation exist initially?

4. Should workspace switching be instant?

5. Should multiple workspaces be open simultaneously?

6. What belongs in the MVP?

7. What must explicitly stay out of scope?

---

Goal

Define a clean, scalable, provider-agnostic workspace isolation architecture for floci-ui that can evolve incrementally without requiring major future redesigns.

[IoannisLafiotis]

1. Naming
   What should the abstraction be called?

I like the project name which also can contain multicloud configuration. That means different Credentials for different cloud providers.
Env will be in other levels used so I dont think it is a good idea. Context could be used on the k8s level as well as in the provider level

Project Test
Context AWS f.e or just with Provider AWS

2. Isolation Scope
   Here I like somehow the lightweight idea
   A Project should have the necessary configuration for seting up the Emulators environement

3. Hierarchy
   I think it is enough for now and it wont be a huge issue to update later. Of course better now than later.

4. Runtime
   I am bit puzzled on this one. I think I would prefer to go with an isolated instance but can servce all selected Providers

5. Scope of work
   I agree with the scope of work for the v1 of the API

6. User should be able to open multiple workspaces but that could also be dependant on the organization right. When self-hosted then for sure. Of course here an Idea would be to use a feature switch

7. I would say database maybe like a Postgresql

8. Future Considerations:
   Sky is the limit. Cloud Federation sounds good.

[huda-code]

I think “Workspace” makes the most sense. It’s simple and works across AWS, Azure, and GCP without sounding tied to one platform.

For v1, I’d keep it simple with separate credentials/configs, separate local state, easy workspace switching, saved sessions

I wouldn’t do full runtime/container isolation yet. That can come later once the base structure is stable. Also agree that opening multiple workspaces at once would be useful later, but probably not needed for MVP.

[cristiandlahoz]

1. Naming
   I agree with Hajira. Workspaces make perfect sense for our goal.

2. Isolation scope:
   I think we should go with an easy-to-use approach where this is only a UI state/preference for now. Later, this should allow us to support having different workspaces open in different tabs, similar to Jira’s sites concept.

3. Provider Mapping:
   I think a simple mapping concept per provider is enough for now.

4. Runtime Isolation:
   I would say logical/UI only. If we later see the need to switch to a more robust approach, we can do that.

5. Scope of V1:
   I’m okay with this MVP.

6. Should users be able to open multiple workspaces simultaneously?
   Yes. As @hectorvent said, it’s a common need, and if we follow a logical context-switching approach, it seems manageable.

7. Persistence Model:
   I like @IoannisLafiotis idea of using Postgres.

8. Future considerations:
   Those seem like logical considerations, but I would like to keep it simple first and decide based on community needs and feedback.