Cosmo-Tech · MohcineTor · Apr 24, 2026 · Apr 24, 2026 · Apr 24, 2026
diff --git a/docs/Examples/Example_Deploy_CosmoTech_workspace.md b/docs/Examples/Example_Deploy_CosmoTech_workspace.md
@@ -31,7 +31,7 @@ Check your current Kubernetes context and switch to the correct one:
     ```
 ##  Set up Babylon Context
 ```bash
-babylon namespace use -c test -t dev -s 73a90433
+babylon namespace use -c test -t dev
 ```
 ## Initialization Babylon project
 
@@ -40,7 +40,7 @@ With Babylon v5, you can now generate a minimal manifest YAML file that can be u
 !!! example
 
     ```bash
-    babylon init --project-folder devops --variables-file devops.yaml 
+    babylon init --project-folder devops --variables-file devops.yaml azure
     ```
     ```bash
        → Cloning Terraform WebApp module...
@@ -103,14 +103,19 @@ Here is an example of `variables.yaml` with detailed explanations:
     simulator_version: to_fill                  # To fill according to your simulator version
     # Webapp
     cloud_provider: azure                       # Cloud provider to use (e.g., azure, aws, gcp)
-    cluster_name: dev-aks                       # Name of the Kubernetes cluster
-    cluster_domain: dev-aks.azure.platform.cosmotech.com  # Domain of the Kubernetes cluster
+    cluster_name: aks-dev-test                  # Name of the Kubernetes cluster
+    cluster_domain: aks-dev-test.azure.platform.cosmotech.com  # Domain of the Kubernetes cluster
     tenant: dev                                 # namespace kubernetes (e.g., dev, prod)
     webapp_name: business                       # Name of the web application
     organization_id: o-xxxxxxxxxxx                         # Organization ID
     azure_subscription_id: xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx # Azure subscription ID
     azure_entra_tenant_id: xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx # Azure Entra (AAD) tenant ID
     powerbi_app_deploy: false                              # Set to true if deploying Power BI app, false otherwise
+
+    # Enabled by default: stores deployment state in a Kubernetes secret.
+    # Set to false for local testing.
+    remote: true
+
     # Security
     # The list below will be used on all API objects.
     # If differents security list are needed for each API objects,
@@ -135,7 +140,7 @@ Now you can launch the `apply` command to deploy the workspace:
     source .venv/bin/activate
     ```
     ```bash
-    babylon namespace use -c test -t dev -s 73a90433
+    babylon namespace use -c test -t dev
     ```
     ```bash
     babylon apply project/

diff --git a/docs/Examples/Example_Update_CosmoTech_workspace.md b/docs/Examples/Example_Update_CosmoTech_workspace.md
@@ -70,7 +70,7 @@ After making the necessary modifications, you can now apply the changes using Ba
     source .venv/bin/activate
     ```
     ```bash
-    babylon namespace use -c test -t dev -s 73a90433
+    babylon namespace use -c test -t dev
     ```
     ```bash
     babylon apply project/

diff --git a/docs/commands/babylon_commands.md b/docs/commands/babylon_commands.md
@@ -19,7 +19,7 @@ description: "Reference guide for essential Babylon CLI commands"
           \/___/  \/__/\/_/ \/___/   `/___/> \\/____/ \/___/  \/_/\/_/  
                                         /\___/  
                                         \/__/  
-                                                                 v5.1.0
+                                                                 v5.2.0
 
       CLI used for cloud interactions between CosmoTech and multiple cloud
       environment
@@ -57,7 +57,7 @@ description: "Reference guide for essential Babylon CLI commands"
 !!! info "Namespace Use"
 
     ```bash
-    babylon namespace use -c test -t dev -s 4s5de
+    babylon namespace use -c test -t dev
     ```
     ```bash
      ✔ Switched to context test, tenant dev successfully

diff --git a/docs/guides/resource_file.md b/docs/guides/resource_file.md
@@ -5,60 +5,20 @@ If the **state file** does not exist, the first Babylon command you run will **i
       (This will be explained in detail in the *Deploy Workspace* tutorial, just keep it in mind for now.)
     - The structure and content of the state may change in future releases as needed.
 
-### Cloud State Configuration
+### State Configuration
 
-When you set `remote: true` and run `babylon apply`, you might encounter an error initially.
+Babylon now stores the state as a Kubernetes Secret within the cluster. This allows us to support all major managed Kubernetes distributions, including AKS, EKS, and GKE.
 
-!!! error 
-    ```bash
-    🚀 Deploying Organization in namespace: sphinx
-      ✘ Failed to initialize BlobServiceClient: Missing environment variables: 'STORAGE_NAME' and 'ACCOUNT_SECRET'
-    ```
-This is expected behavior as the cloud state requires specific environment variables to authenticate with your storage.
-
-To use the cloud state, you **must** set the following environment variables:
-
-| Variable | Description |
-| :--- | :--- |
-| `STORAGE_NAME` | The name of your Azure Storage Account. |
-| `ACCOUNT_SECRET` | Your Storage Account access key. |
-
-
-To find your **ACCOUNT_SECRET**, follow these steps in the Azure Portal:
-
-1. Navigate to your **Storage Account**.
-2. In the left-hand menu, go to the **Security + networking** section.
-3. Click on **Access keys**.
-4. You can use either `key1` or `key2` as your secret.
-
-![Azure Access Keys](../assets/Access_keys.png)
-
-!!! tip "Security Best Practice"
-    Never commit your `ACCOUNT_SECRET` to a git repository. Always use environment variables or a secret manager to keep your credentials safe
-
-**How to set them :**
-
-!!! important
-    === "🖥️ Windows"
-        ```powershell
-        $env:STORAGE_NAME="your_storage_account_name"
-        $env:ACCOUNT_SECRET="your_access_key"
-        ```
-    === "🐧 Linux"
-        ```bash
-        export STORAGE_NAME="your_storage_account_name"
-        export ACCOUNT_SECRET="your_access_key"
-        ```
+When you set `remote: true` and execute `babylon apply`, Babylon automatically creates a Secret named `babylon-state-<context_id>-<tenant_id>` in your current namespace to persist the state information.
 
 ### Babylon State Structure
 
 The **Babylon state** is a structured YAML file composed of multiple sections.  
 At a high level, you will find three main entries:
 ```yaml
 context:
-files: []
-id: 
 tenant:
+remote: true
 services:
   api:
     organization_id: 

diff --git a/docs/partials/installation/from_git.md b/docs/partials/installation/from_git.md
@@ -10,11 +10,11 @@ You can download the latest version of Babylon using git clone command
 
 **Get the specific version from git**
 
-If you want a specific version of Babylon (e.g. v5.0.0-beta.2)
+If you want a specific version of Babylon (e.g. v5.2.0)
 
 !!! example "Specific Version"
     ```bash
-    git clone -b v5.0.0-beta.2 git@github.com:Cosmo-Tech/Babylon.git babylon
+    git clone -b v5.2.0 git@github.com:Cosmo-Tech/Babylon.git babylon
     cd babylon
     ```
 

diff --git a/docs/tutorial/API/Organization.md b/docs/tutorial/API/Organization.md
@@ -1,7 +1,7 @@
   ```yaml
   kind: Organization
   namespace:
-    remote: true   # false by default
+    remote: true
   ```
 The deployment configuration must define the following keys:
 
@@ -25,7 +25,7 @@ For example, in an **Organization** deployment file:
     ```yaml
     kind: Organization
     namespace:
-      remote: true   # false by default
+      remote: true
     spec:
       payload:
         name: "{{organization_name}}"

diff --git a/docs/tutorial/API/Solution.md b/docs/tutorial/API/Solution.md
@@ -5,7 +5,7 @@ This is how the solution deployment file is structured
     ```yaml
     kind: Solution
     namespace:
-      remote: true   # false by default
+      remote: true
     metadata:
       selector:
         organization_id: "{{services['api.organization_id']}}"

diff --git a/docs/tutorial/API/Webapp.md b/docs/tutorial/API/Webapp.md
@@ -12,16 +12,16 @@ Babylon automatically clones the Terraform web app repository and updates the `t
       ```yaml
       kind: Webapp
       namespace:
-         remote: true
+         remote: {{remote}}
       spec:
          payload:
-            cloud_provider: "azure"
+            cloud_provider: "{{cloud_provider}}"
             cluster_name: "{{cluster_name}}"
             cluster_domain: "{{cluster_domain}}"
             tenant: "{{tenant}}"
             webapp_name: "{{webapp_name}}"
             organization_id: "{{services['api.organization_id']}}"
             azure_subscription_id: "{{azure_subscription_id}}"
             azure_entra_tenant_id: "{{azure_entra_tenant_id}}"
-            powerbi_app_deploy: false
+            powerbi_app_deploy: {{powerbi_app_deploy}}
       ```
diff --git a/docs/tutorial/API/Workspace.md b/docs/tutorial/API/Workspace.md
@@ -15,12 +15,12 @@ When `create` is set to `true`, Babylon will execute the specified Kubernetes jo
     ```yaml
     kind: Workspace
     namespace:
-      remote: true   # false by default
+      remote: true
     spec:
       sidecars:
         postgres:
           schema:
-            create: true # false by default
+            create: true
             jobs:
               - name: k8s_job.yaml
                 path: postgres/jobs

diff --git a/docs/tutorial/Deploy_CosmoTech_workspace.md b/docs/tutorial/Deploy_CosmoTech_workspace.md
@@ -14,7 +14,6 @@ description: Tutorial for creating or update Cosmo Tech workspace
 
     - `context_id`: `test`  
     - `tenant_id`: `dev`  
-    - `state_id`: `8db6069e`
 
 To deploy a complete Cosmo Tech workspace, you can declare its configuration in yaml files corresponding
 to specific deployment type. <br>

diff --git a/docs/tutorial/Deploy_workspace_with_existing_org_sol.md b/docs/tutorial/Deploy_workspace_with_existing_org_sol.md
@@ -14,7 +14,6 @@ description: Tutorial for creating or update Cosmo Tech workspace with and exist
 
     * context_id: `test`
     * tenant_id: `dev`
-    * state_id: `8db6069e`
 
 Before going further, you should know that we have two concepts: deploying a solution object within an existing organization, and deploying a workspace object within an existing organization and solution. This is just to give you some quick context for the tutorial.
 
@@ -57,7 +56,7 @@ Below is an example of the solution manifest structure.
     ```yaml
     kind: Solution
     namespace:
-      remote: true   # false by default
+      remote: true
     metadata:
       selector:
         organization_id: "{{organization_id}}" # <---
@@ -103,7 +102,7 @@ To do this, add both `organization_id` and `solution_id` under `metadata.selecto
     ```yaml
     kind: Workspace
     namespace:
-      remote: true   # false by default
+      remote: true
     metadata:
       selector:
         organization_id: "{{organization_id}}" # <--- 
@@ -168,4 +167,4 @@ Now, with this Babylon feature, you can deploy multiple **Workspaces** that:
 !!! note "Important"
     For each workspace deployment, you need a **specific state file**.
 
-    e.g :  `state.<context_id>.<tenant_id>.<state_id>.yaml`
+    e.g :  `state.<context_id>.<tenant_id>.yaml`
diff --git a/docs/tutorial/Getting_started.md b/docs/tutorial/Getting_started.md
@@ -130,40 +130,22 @@ If you no longer have access to the cluster, you can export these variables manu
         ```
 ### Configuration
 
-At this point, you need **three variables** to perform Babylon commands.
+At this point, you need **two variables** to perform Babylon commands.
 
 | Variable       | Description                                | Example   |
 |----------------|--------------------------------------------|-----------|
 | `context_id`   | Project name *(string of your choice, no special characters)* | `project1` |
 | `tenant_id`    | Tenant ID *(e.g., dev, staging, prod)*                        | `dev`     |
-| `state_id`     | State name *(string of your choice, no special characters)*   | `state1`  |
 
 !!! important "⚠️ Variable Constraints"
-    - `context_id` and `state_id` can be **any string** of your choice, but **they must not contain special characters**.  
-    - For state_id, you can generate a new UUID with [`uuidgen`](https://man7.org/linux/man-pages/man1/uuidgen.1.html):  
-    === "🐧 Linux"
-        ```bash
-        sudo apt update
-        sudo apt install uuid-runtime -y
-        # Generate a UUID
-        uuidgen | cut -c1-8
-        # Example output:
-        0475231d
-        ```
-    === "🖥️ Windows"
-        ```powershell
-        # Open PowerShell and run:
-        [guid]::NewGuid().ToString().Substring(0,8)
-        # Example output:
-        0475231d
-        ```
+    - `context_id` can be **any string** of your choice, but **they must not contain special characters**.
     - `tenant_id` represents the **namespace kubernetes** (e.g., `dev`, `staging`, ...).  
 
 
 To initialize Babylon namespace with these values, run:
 
 ```bash
-babylon namespace use -c <context_id> -t <tenant_id> -s <state_id>
+babylon namespace use -c <context_id> -t <tenant_id>
 ```
 
 !!! note "Generated Configuration"
@@ -197,7 +179,7 @@ This persisted state is referred to as the **Babylon state**.
     The state is saved in two locations:
 
     1. **Remote backend (cloud)** → storage account `cosmotechstates` → containers `babylon-states`
-    2. **Local backend (YAML file)** → `~/.config/babylon/state.<context_id>.<tenant_id>.<state_id>.yaml`
+    2. **Local backend (YAML file)** → `~/.config/babylon/state.<context_id>.<tenant_id>.yaml`
 
 ## State file specification
 
@@ -241,11 +223,11 @@ Additionally, with `get-states`, you can list all states available on our local
 
 #### Viewing State Files
 
-You can easily view and manage all available state files, whether they are stored locally or in the cloud. This is particularly useful when you need to select a specific state to update or redeploy your workspace.
+You can easily view and manage all available state files, whether they are stored locally or in the cluster as a secret. This is particularly useful when you need to select a specific state to update or redeploy your workspace.
 
 The `babylon namespace get-states` command provides two options:
 
-- `remote`: Lists all state files stored in the remote (cloud).
+- `remote`: Lists all state files stored in the remote (cluster).
 - `local`: Lists all state files available on your local machine.
 
 !!! example 
@@ -284,20 +266,25 @@ Here’s an example:
     babylon init --help
     ```
     ```bash
-    Usage: babylon init [OPTIONS]
+    Usage: babylon init [OPTIONS] {azure|kob}
+
+    Scaffolds a new Babylon project structure using YAML templates.
+
+    arguments:
 
-    Create a Babylon project structure using YAML templates.
+        cloud_provider: Target cloud provider for webapp deployment (e.g. 'azure',
+        'kob').
 
     Options:
     --project-folder TEXT  Name of the project folder to create (default:'project').
     --variables-file TEXT  Name of the variables file (default:'variables.yaml').
     --help  Show this message and exit.
     ```
     ```bash
-    babylon init
+    babylon init azure
     ```
     ```bash
-    babylon init --project-folder devops --variables-file devops.yaml 
+    babylon init --project-folder devops --variables-file devops.yaml azure
     ```
     ```bash
        → Cloning Terraform WebApp module...

diff --git a/setup.py b/setup.py
@@ -4,7 +4,7 @@
 with open('requirements.txt') as f:
     required = f.read().splitlines()
 
-version = "5.1.0"
+version = "5.2.0"
 
 setup(
     name='Babylon End User Documentation',