diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 74dfb91ee9..082c11aceb 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -8,7 +8,7 @@ In order to contribute you can submitting bug reports or suggest some correction
## Code of Conduct
This project adheres to the [Contributor Covenant Code of Conduct](CODE_OF_CONDUCT.md), please read it and follow it
-before contributing. If you find someone that is not respecting it please report its behaviour.
+before contributing. If you find someone that is not respecting it please report its behavior.
## How Can I Contribute
diff --git a/docs/products/fast_data_v2/farm_data/CHANGELOG.md b/docs/products/fast_data_v2/farm_data/CHANGELOG.md
index d546248b28..224d38d843 100644
--- a/docs/products/fast_data_v2/farm_data/CHANGELOG.md
+++ b/docs/products/fast_data_v2/farm_data/CHANGELOG.md
@@ -9,6 +9,13 @@ All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+## [0.6.1] - 2026-02-19
+
+### Fixed
+
+- Fixed control plane startup behavior to resume
+- Explicit error on missing SERVICE_NAME missing var
+
## [0.6.0] - 2026-02-02
### BREAKING
diff --git a/docs/products/fast_data_v2/kango/CHANGELOG.md b/docs/products/fast_data_v2/kango/CHANGELOG.md
index e3c52f4a77..22b6309fab 100644
--- a/docs/products/fast_data_v2/kango/CHANGELOG.md
+++ b/docs/products/fast_data_v2/kango/CHANGELOG.md
@@ -9,6 +9,13 @@ All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+## [0.6.1] - 2026-02-19
+
+### Fixed
+
+- Fixed control plane startup behavior to resume
+- Explicit error on missing SERVICE_NAME missing var
+
## [0.6.0] - 2026-02-02
### BREAKING
diff --git a/docs/products/fast_data_v2/runtime_management/application_configuration.md b/docs/products/fast_data_v2/runtime_management/application_configuration.md
index b04d3ea70e..ccdd045d9f 100644
--- a/docs/products/fast_data_v2/runtime_management/application_configuration.md
+++ b/docs/products/fast_data_v2/runtime_management/application_configuration.md
@@ -90,6 +90,55 @@ During the deployment process, the files will be automatically applied to the ac
Without these permissions, the Control Plane service cannot discover Fast Data workloads (Mongezium, Stream Processor, Farm Data, Kango) in your namespace and the Control Plane Frontend will not display your pipeline.
+:::caution
+When deploying the `control-plane-role.yaml` and `control-plane-role-binding.yaml` manifests, the Service Account or user performing the deployment (the "deployer") **must have sufficient permissions to manage RBAC resources within the target namespace**.
+:::
+
+If the deployer lacks these permissions, the pipeline will fail with an error similar to:
+
+> `User "..." cannot patch resource "roles" in API group "rbac.authorization.k8s.io" in the namespace "..."`
+
+This typically happens because, in many Kubernetes distributions (such as Azure AKS), the ability to modify security roles is restricted to prevent unauthorized privilege escalation.
+
+**Corrective Action**
+
+Before deploying these manifests, ensure that the deployer Service Account (e.g., `console-deployer`) has a **Role** or **ClusterRole** bound to it that allows the following actions in the target namespace:
+
+* **Resources**: `roles`, `rolebindings`
+* **API Group**: `rbac.authorization.k8s.io`
+* **Verbs**: `get`, `list`, `watch`, `create`, `update`, `patch`
+
+#### **Example: Granting RBAC management to the deployer**
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
+metadata:
+ name: rbac-manager-role
+ namespace: {YOUR_NAMESPACE}
+rules:
+ - apiGroups: ["rbac.authorization.k8s.io"]
+ resources: ["roles", "rolebindings"]
+ verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+ name: rbac-manager-binding
+ namespace: {YOUR_NAMESPACE}
+subjects:
+ - kind: ServiceAccount
+ name: console-deployer # The name of your CI/CD service account
+ namespace: mia-platform
+roleRef:
+ kind: Role
+ name: rbac-manager-role
+ apiGroup: rbac.authorization.k8s.io
+
+```
+
+In some managed environments like **Azure AKS**, ensure that your Azure identity also has the "Azure Kubernetes Service Cluster Admin" or "Azure Kubernetes Service RBAC Admin" role if you are using Azure RBAC integration.
+
#### In-Memory Storage
You can opt for in-memory storage for your pipeline runtime states instead of persisting them.
@@ -113,8 +162,6 @@ The Control Plane Frontend is already pre-configured and ready to be deployed. N
The Envoy API Gateway serves as the entry point for the Fast Data Control Plane application, providing essential routing and security capabilities.
-The Envoy API Gateway microservice is pre-configured and ready to be deployed. The routing configuration is automatically generated based on the endpoint definitions, and no manual intervention is required.
-
#### Exposed Endpoints
The application pre-configures two endpoints that are automatically routed by Envoy:
@@ -123,6 +170,16 @@ The application pre-configures two endpoints that are automatically routed by En
- **`/`** - Routes requests to the Control Plane Frontend service
+#### Required Advanced Configuration
+
+Since the application uses the **WebSocket protocol** for bidirectional communication, you must add the following configuration to the **patches.yaml** file within the Advanced Configurations section of the Design Area:
+
+```yaml
+- listener_name: frontend
+ 'filter_chains.0.filters.0.typed_config.upgrade_configs':
+ upgrade_type: "websocket"
+```
+
## Workloads Configuration
To enable proper communication between the Control Plane and the Fast Data workloads deployed in your namespace, each Fast Data workload must be configured to connect to the Control Plane.
@@ -137,8 +194,14 @@ For each of the Fast Data workloads (Mongezium, Stream Processor, Farm Data, and
}
```
+Moreover, it is necessary to add the `SERVICE_NAME` environment variable with the following parameters:
+
+- **Value Type**: `From Downward API`
+- **Field Path**: `metadata.labels['KEY']`
+- **Label Key**: `app.kubernetes.io/name`
+
:::note
-Without this configuration, the Fast Data workloads will operate independently and will not be visible or controllable through the Control Plane interface.
+Without this configuration, the Fast Data workloads will operate independently and will not be controllable through the Control Plane interface.
:::
### Additional Configuration Parameters
@@ -148,7 +211,7 @@ Optionally, it is possible to add other parameters to the "control plane" config
- **`onCreate`**: Initial state when the workload for the first time is deployed and connects to the control plane. Available values are `"pause"` or `"resume"`. Set to `"pause"` to ensure the workload waits for explicit Control Plane commands from UI before start data consumption from data streams.
:::note
-If no `onCreate` behavior is defined in the microservice ConfigMap, the **default runtime state** is **Running**. This design choice safeguards real-time data flows by preventing service interruptions when adding Control Plane connectivity to established Fast Data workloads.
+If no `onCreate` behavior is defined in the microservice ConfigMap, the **default runtime state** is **Running**, so the **resume** state. This design choice safeguards real-time data flows by preventing service interruptions when adding Control Plane connectivity to established Fast Data workloads.
`onCreate` is applied solely if the Fast Data workload is the first time that is deployed. Otherwise, the parameter will be not considered by Control Plane, as it reads the last saved runtime state.
:::
@@ -165,7 +228,7 @@ If no `onCreate` behavior is defined in the microservice ConfigMap, the **defaul
## Application Deployment
-Once you have concluded all the above mentioned configuration steps, you can easily deploy your Project configuration!
+Once you have concluded all the above mentioned configuration steps, it's time to **deploy your Project**!
Verify the success of your deploy by:
diff --git a/docs/products/fast_data_v2/runtime_management/compatibility_matrix.md b/docs/products/fast_data_v2/runtime_management/compatibility_matrix.md
index 9e9caca165..6763e22632 100644
--- a/docs/products/fast_data_v2/runtime_management/compatibility_matrix.md
+++ b/docs/products/fast_data_v2/runtime_management/compatibility_matrix.md
@@ -13,23 +13,23 @@ Please ensure that versions shown in the matrix are respected in your deployed e
| Service | Version | MongoDB |
|-------------------------|---------|---------|
-| Control Plane | 0.1.0 | \>=7.0 |
+| Control Plane | 0.1.1-mongodb | \>=7.0 |
## Fast Data Services
Here is provided the compatibility matrix between Control Plane components and the Fast Data Engine v2 workloads that need to communicate with them.
Please ensure that your services respect the following matrix.
-| [Control Plane Frontend](/products/fast_data_v2/runtime_management/application_configuration.md) | [Control Plane Piper](/products/fast_data_v2/runtime_management/application_configuration.md) | [Mongezium](/products/fast_data_v2/mongezium_cdc/10_Overview.md) | [Stream Processor](/products/fast_data_v2/stream_processor/10_Overview.md) | [Farm Data](/products/fast_data_v2/farm_data/10_Overview.md) | [Kango](/products/fast_data_v2/kango/10_Overview.md) |
+| [Control Plane Frontend](/products/fast_data_v2/runtime_management/application_configuration.md) | [Control Plane](/products/fast_data_v2/runtime_management/application_configuration.md) | [Mongezium](/products/fast_data_v2/mongezium_cdc/10_Overview.md) | [Stream Processor](/products/fast_data_v2/stream_processor/10_Overview.md) | [Farm Data](/products/fast_data_v2/farm_data/10_Overview.md) | [Kango](/products/fast_data_v2/kango/10_Overview.md) |
|:----------------------:|:-------------------:|:----------------------------------------------------------:|:---------------------------------------------------------------------:|:------------------------------------------------------:|:----------------------------------------------:|
-| 0.1.0 | 0.1.0 | \>=0.5.0 | \>=0.6.0 | \>=0.6.0 | \>=0.6.0 |
+| 0.1.2 | 0.1.1-mongodb | \>=0.5.0 | \>=0.6.0 | \>=0.6.0 | \>=0.6.0 |
## Service Latest Versions
| Service | Version |
|-----------------------------------------------------------------------------------------------|---------|
-| [Control Plane Frontend](/products/fast_data_v2/runtime_management/application_configuration.md) | 0.1.0 |
-| [Control Plane Piper](/products/fast_data_v2/runtime_management/application_configuration.md) | 0.1.0 |
+| [Control Plane Frontend](/products/fast_data_v2/runtime_management/application_configuration.md) | 0.1.2 |
+| [Control Plane](/products/fast_data_v2/runtime_management/application_configuration.md) | 0.1.1-mongodb |
| [Mongezium](/products/fast_data_v2/mongezium_cdc/10_Overview.md) | 0.5.0 |
| [Stream Processor](/products/fast_data_v2/stream_processor/10_Overview.md) | 0.6.0 |
| [Farm Data](/products/fast_data_v2/farm_data/10_Overview.md) | 0.6.0 |
@@ -37,11 +37,11 @@ Please ensure that your services respect the following matrix.
## Internal Compatibility
-| Service | Control Plane Frontend | Control Plane Piper | Mongezium | Stream Processor | Farm Data | Kango |
+| Service | Control Plane Frontend | Control Plane | Mongezium | Stream Processor | Farm Data | Kango |
|---------------------------:|:----------------------:|:-------------------:|:---------:|:----------------:|:---------:|:-----:|
-| Control Plane Frontend - 0.1.0 | _N/A_ | 0.1.0 | 0.5.0 | 0.6.0 | 0.6.0 | 0.6.0 |
-| Control Plane Piper - 0.1.0 | 0.1.0 | _N/A_ | 0.5.0 | 0.6.0 | 0.6.0 | 0.6.0 |
-| Mongezium - 0.5.0 | 0.1.0 | 0.1.0 | _N/A_ | 0.6.0 | 0.6.0 | 0.6.0 |
-| Stream Processor - 0.6.0 | 0.1.0 | 0.1.0 | 0.5.0 | _N/A_ | 0.6.0 | 0.6.0 |
-| Farm Data - 0.6.0 | 0.1.0 | 0.1.0 | 0.5.0 | 0.6.0 | _N/A_ | 0.6.0 |
-| Kango - 0.6.0 | 0.1.0 | 0.1. | 0.5.0 | 0.6.0 | 0.6.0 | _N/A_ |
+| Control Plane Frontend - 0.1.2 | _N/A_ | 0.1.1-mongodb | 0.5.0 | 0.6.0 | 0.6.0 | 0.6.0 |
+| Control Plane - 0.1.1-mongodb | 0.1.2 | _N/A_ | 0.5.0 | 0.6.0 | 0.6.0 | 0.6.0 |
+| Mongezium - 0.5.0 | 0.1.2 | 0.1.1-mongodb | _N/A_ | 0.6.0 | 0.6.0 | 0.6.0 |
+| Stream Processor - 0.6.0 | 0.1.2 | 0.1.1-mongodb | 0.5.0 | _N/A_ | 0.6.0 | 0.6.0 |
+| Farm Data - 0.6.0 | 0.1.2 | 0.1.1-mongodb | 0.5.0 | 0.6.0 | _N/A_ | 0.6.0 |
+| Kango - 0.6.0 | 0.1.2 | 0.1.1-mongodb | 0.5.0 | 0.6.0 | 0.6.0 | _N/A_ |
diff --git a/docs/products/fast_data_v2/stream_processor/CHANGELOG.md b/docs/products/fast_data_v2/stream_processor/CHANGELOG.md
index a705601cc4..afa712a4a0 100644
--- a/docs/products/fast_data_v2/stream_processor/CHANGELOG.md
+++ b/docs/products/fast_data_v2/stream_processor/CHANGELOG.md
@@ -10,6 +10,13 @@ All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+## [0.6.1] - 2026-02-19
+
+### Fixed
+
+- Fixed control plane startup behavior to resume
+- Explicit error on missing SERVICE_NAME missing var
+
## [0.6.0] - 2026-02-02
### BREAKING
diff --git a/release-notes/v14.5.0.mdx b/release-notes/v14.5.0.mdx
index 1b32200825..f7278c01f5 100644
--- a/release-notes/v14.5.0.mdx
+++ b/release-notes/v14.5.0.mdx
@@ -7,16 +7,7 @@ image: "img/release-note-link-preview.png"
import Accordion from '@site/src/components/Accordion/index.js';
import dataAccordion from '@site/src/config/release-notes/release-note-v14-5-0.json';
-_February 05th, 2026_
-
-:::info
-
-Mia-Platform Console v14.5.0 is **now in Preview** and will be generally available on February 19th.
-
-Console SaaS users can try out v14.5.0 latest improvements in Preview! Open a Service Request to ask for the creation of a sandbox Company in case you do not have access to any Company.
-
-For self-hosted installations, please read the [following guidelines](#how-to-update-your-console).
-:::
+_February 19th, 2026_
## Fast Data Control Plane v2
@@ -24,7 +15,7 @@ Let's welcome the **Fast Data Control Plane v2**, the runtime management solutio
Fast Data Control Plane application provides a general overview of the Fast Data v2 pipelines released on the runtime environment, and allows to monitor and govern the execution steps of your data pipelines.
-Discover all the capabilities and benefits of Fast Data Control Plane v2 in the [official documentation](/docs/14.5.0/products/fast_data_v2/runtime_management/overview).
+Discover all the capabilities and benefits of Fast Data Control Plane v2 in the [official documentation](/docs/products/fast_data_v2/runtime_management/overview).
@@ -52,7 +43,7 @@ To try it, go the **Feature Preview** section inside your **Project settings**,
## How to update your Console
-For self-hosted installations, please head to the [self hosted upgrade guide](/docs/infrastructure/self-hosted/installation-chart/how-to-upgrade) or contact your Mia-Platform referent and upgrade to _Console Helm Chart_ `v15.0.8-beta.1`.
+For self-hosted installations, please head to the [self hosted upgrade guide](/docs/infrastructure/self-hosted/installation-chart/how-to-upgrade) or contact your Mia-Platform referent and upgrade to _Console Helm Chart_ `v15.0.8`.
### Bill of materials
diff --git a/release-notes/v14.5.1.mdx b/release-notes/v14.5.1.mdx
new file mode 100644
index 0000000000..d853530799
--- /dev/null
+++ b/release-notes/v14.5.1.mdx
@@ -0,0 +1,70 @@
+---
+id: v14.5.1
+title: Version 14.5.1 Release Notes
+image: "img/release-note-link-preview.png"
+---
+
+import Accordion from '@site/src/components/Accordion/index.js';
+import dataAccordion from '@site/src/config/release-notes/release-note-v14-5-1.json';
+
+_February 19th, 2026_
+
+:::info
+
+Mia-Platform Console v14.5.1 is **now in Preview** and will be generally available on March 05th.
+
+Console SaaS users can try out v14.5.1 latest improvements in Preview! Open a Service Request to ask for the creation of a sandbox Company in case you do not have access to any Company.
+
+For self-hosted installations, please read the [following guidelines](#how-to-update-your-console).
+:::
+
+
+
+## How to update your Console
+
+For self-hosted installations, please head to the [self hosted upgrade guide](/docs/infrastructure/self-hosted/installation-chart/how-to-upgrade) or contact your Mia-Platform referent and upgrade to _Console Helm Chart_ `v15.0.9-beta.0`.
+
+### Bill of materials
+
+| Image repository | Version |
+| ----------------------------------------------------------------------- | :-------------: |
+| docker.io/envoyproxy/ratelimit | 19f2079f |
+| nexus.mia-platform.eu/api-portal/website | 2.2.0 |
+| nexus.mia-platform.eu/back-kit/mfe-toolkit-on-prem | 1.3.10 |
+| nexus.mia-platform.eu/backoffice/login-site | 7.2.3 |
+| nexus.mia-platform.eu/console/aggregated-website | 1.5.57 |
+| nexus.mia-platform.eu/console/api-gateway | 0.2.9 |
+| nexus.mia-platform.eu/console/backend | 32.9.1 |
+| nexus.mia-platform.eu/console/catalog-service | 1.7.1 |
+| nexus.mia-platform.eu/console/deploy-service | 8.1.2 |
+| nexus.mia-platform.eu/console/environments-variables | 3.6.1 |
+| nexus.mia-platform.eu/console/events-manager | 1.4.4 |
+| nexus.mia-platform.eu/console/extensibility-manager | 2.1.0 |
+| nexus.mia-platform.eu/console/favorites-service | 2.3.1 |
+| nexus.mia-platform.eu/console/feature-toggle-service | 1.3.7 |
+| nexus.mia-platform.eu/console/kubernetes-service | 8.4.6 |
+| nexus.mia-platform.eu/console/license-manager | 3.0.3 |
+| nexus.mia-platform.eu/console/license-metrics-generator | 6.0.6 |
+| nexus.mia-platform.eu/console/mcp-server | 1.2.1 |
+| nexus.mia-platform.eu/console/mia-assistant | 1.3.8 |
+| nexus.mia-platform.eu/console/mia-craft-bff | 1.2.5 |
+| nexus.mia-platform.eu/console/notification-provider | 2.2.5 |
+| nexus.mia-platform.eu/console/project-service | 2.1.0 |
+| nexus.mia-platform.eu/console/rbac-manager-bff | 2.1.2 |
+| nexus.mia-platform.eu/console/scripts/bindings-cleaner | 1.2.2 |
+| nexus.mia-platform.eu/console/scripts/configuration-history-cleaner | 0.4.1 |
+| nexus.mia-platform.eu/console/scripts/marketplace-sync | 10.10.1 |
+| nexus.mia-platform.eu/console/scripts/mia-assistant-embeddings-importer | latest |
+| nexus.mia-platform.eu/console/scripts/software-catalog-sync | 0.7.17 |
+| nexus.mia-platform.eu/console/scripts/version-upgrader | 11.1.2-hotfix.0 |
+| nexus.mia-platform.eu/console/tenant-overview | 4.1.0 |
+| nexus.mia-platform.eu/core/authentication-service | 3.13.1 |
+| nexus.mia-platform.eu/core/authorization-service | 2.4.3 |
+| nexus.mia-platform.eu/core/client-credentials | 3.4.1 |
+| nexus.mia-platform.eu/core/crud-service | 6.10.3 |
+| nexus.mia-platform.eu/core/proxy-manager | 3.5.0 |
+| nexus.mia-platform.eu/core/swagger-aggregator | 3.9.6 |
+| nexus.mia-platform.eu/microlc/middleware | 3.4.0 |
+| nexus.mia-platform.eu/plugins/files-service | 2.10.5 |
+| nexus.mia-platform.eu/plugins/ses-mail-notification-service | 3.5.0 |
+| nexus.mia-platform.eu/rond-authz/rond | 1.14.2 |
diff --git a/release-notes/versions.md b/release-notes/versions.md
index 13b8147cc7..cce6d08d15 100644
--- a/release-notes/versions.md
+++ b/release-notes/versions.md
@@ -9,8 +9,19 @@ import Changelog from '@site/src/components/Changelog';
+## [v14.5.1](/release-notes/v14.5.1.mdx)
+*February 19th, 2026*
+
+This release enhances the merge capabilities in the Console Design Area by introducing **support for merging configurations from versions**, complementing the existing merge from revisions feature.
+Additionally, the **Orchestrator Generator** payload has been enriched with configuration change identifiers and public variables.
+For **Fast Data**, there are some available version updates for both Fast Data Control Plane v2 services and Fast Data Engine service.
+
+[Read the release notes](/release-notes/v14.5.1.mdx)
+
+---
+
## [v14.5.0](/release-notes/v14.5.0.mdx)
-*February 05th, 2026*
+*February 19th, 2026*
This release introduces the **Fast Data Control Plane v2**, the runtime management solution for Fast Data v2, that allows to visualize and control Fast Data v2 pipelines at runtime.
Additionally, a new **interface for merging configurations** is now available in Beta, improving the DevX in the Console Design Area.
diff --git a/sidebarsReleaseNotes.js b/sidebarsReleaseNotes.js
index a0c1f12384..7d8f212f28 100644
--- a/sidebarsReleaseNotes.js
+++ b/sidebarsReleaseNotes.js
@@ -11,6 +11,7 @@ export default {
},
"items": [
{"id": "versions", "type": "doc"},
+ {"id": "v14.5.1", "type": "doc", "label": "v14.5.1"},
{"id": "v14.5.0", "type": "doc", "label": "v14.5.0"},
{"id": "v14.4.2", "type": "doc", "label": "v14.4.2 - LTS"},
{"id": "v14.4.1", "type": "doc", "label": "v14.4.1"},
diff --git a/src/config/release-notes/release-note-v14-5-1.json b/src/config/release-notes/release-note-v14-5-1.json
new file mode 100644
index 0000000000..51308ba4e9
--- /dev/null
+++ b/src/config/release-notes/release-note-v14-5-1.json
@@ -0,0 +1,74 @@
+[
+ {
+ "title": "Console",
+ "icon": "console",
+ "defaultOpen": true,
+ "type": "versions",
+ "items": {
+ "newFeatures": [
+ {
+ "title": "Merge of configurations starting from a version",
+ "description": [
+ "In the Design Area, we have added support for merging from versions, in addition to the existing merge from revisions feature.",
+ "Clicking the _Merge from another revision_ icon now displays a list of all available revisions and versions of your Project, allowing you to select the one you wish to merge into your current configuration."
+ ]
+ }
+ ],
+ "improvements": [
+ {
+ "title": "Orchestrator Generator payload information enhancement",
+ "description": [
+ "When using the [Orchestrator Generator](/docs/products/console/company-configuration/providers/extensions/orchestrator-generator/overview) in your Enhanced Workflow Project, the sent payload now includes:",
+ "- **`changesId`**: the configuration change identifier, within the `configurationRef` field",
+ "- the list of **public variables** for the specific deployment environment, available within the `unsecretedVariables` field."
+ ]
+ }
+ ],
+ "bugFixes": []
+ }
+ },
+ {
+ "title": "Fast Data",
+ "icon": "fast-data",
+ "defaultOpen": true,
+ "type": "versions",
+ "items": {
+ "newFeatures": [],
+ "improvements": [
+ {
+ "title": "Fast Data Control Plane v2 Application",
+ "description": [
+ "The new versions of Fast Data Control Plane v2 services are available: the `v0.1.1-mongodb` (and `v0.1.1`) of the _Control Plane_ service are available, the `v0.1.2` of the _Control Plane Frontend_ service is available.",
+ "For the _Ingest_ execution step implemented by [Mongezium CDC plugin](/docs/14.5.0/products/fast_data_v2/mongezium_cdc/overview), now source assets are rendered in Control Plane UI.",
+ "For more information about service latest versions, check out the [compatibility matrix](/docs/14.5.1/products/fast_data_v2/runtime_management/compatibility_matrix#service-latest-versions)."
+ ]
+ },
+ {
+ "title": "Stream Processor v0.6.1",
+ "description": [
+ "The new version `v0.6.1` of the _Stream Processor_ is available!",
+ "This version introduces some fixes about service default startup behavior when using Fast Data Control Plane v2.",
+ "Refer to the [JSON Schema](https://cdn.mia-platform.eu/runtime/platform/data-fabric/stream-processor/v0.6.1/stream-processor.schema.json) for configuration details and check the service [changelog](/docs/14.5.1/products/fast_data_v2/stream_processor/changelog) for more information."
+ ]
+ },
+ {
+ "title": "Farm Data v0.6.1",
+ "description": [
+ "The new version `v0.6.1` of the _Farm Data_ is available!",
+ "This version introduces some fixes about service default startup behavior when using Fast Data Control Plane v2.",
+ "Refer to the [JSON Schema](https://cdn.mia-platform.eu/runtime/platform/data-fabric/farm-data/v0.6.1/farm-data.schema.json) for configuration details and check the service [changelog](/docs/14.5.1/products/fast_data_v2/farm_data/changelog) for more information."
+ ]
+ },
+ {
+ "title": "Kango v0.6.1",
+ "description": [
+ "The new version `v0.6.1` of the _Kango_ service is available!",
+ "This version introduces some fixes about service default startup behavior when using Fast Data Control Plane v2.",
+ "Refer to the [JSON Schema](https://cdn.mia-platform.eu/runtime/platform/data-fabric/kango/v0.6.1/kango.schema.json) for configuration details and check the service [changelog](/docs/14.5.1/products/fast_data_v2/kango/changelog) for more information."
+ ]
+ }
+ ],
+ "bugFixes": []
+ }
+ }
+]
diff --git a/versioned_docs/version-14.5.0/products/fast_data_v2/runtime_management/application_configuration.md b/versioned_docs/version-14.5.0/products/fast_data_v2/runtime_management/application_configuration.md
index b04d3ea70e..f554937862 100644
--- a/versioned_docs/version-14.5.0/products/fast_data_v2/runtime_management/application_configuration.md
+++ b/versioned_docs/version-14.5.0/products/fast_data_v2/runtime_management/application_configuration.md
@@ -137,8 +137,14 @@ For each of the Fast Data workloads (Mongezium, Stream Processor, Farm Data, and
}
```
+Moreover, it is necessary to add the `SERVICE_NAME` environment variable with the following parameters:
+
+- **Value Type**: `From Downward API`
+- **Field Path**: `metadata.labels['KEY']`
+- **Label Key**: `app.kubernetes.io/name`
+
:::note
-Without this configuration, the Fast Data workloads will operate independently and will not be visible or controllable through the Control Plane interface.
+Without this configuration, the Fast Data workloads will operate independently and will not be controllable through the Control Plane interface.
:::
### Additional Configuration Parameters
@@ -148,7 +154,7 @@ Optionally, it is possible to add other parameters to the "control plane" config
- **`onCreate`**: Initial state when the workload for the first time is deployed and connects to the control plane. Available values are `"pause"` or `"resume"`. Set to `"pause"` to ensure the workload waits for explicit Control Plane commands from UI before start data consumption from data streams.
:::note
-If no `onCreate` behavior is defined in the microservice ConfigMap, the **default runtime state** is **Running**. This design choice safeguards real-time data flows by preventing service interruptions when adding Control Plane connectivity to established Fast Data workloads.
+If no `onCreate` behavior is defined in the microservice ConfigMap, the **default runtime state** is **Running**, so the **resume** state. This design choice safeguards real-time data flows by preventing service interruptions when adding Control Plane connectivity to established Fast Data workloads.
`onCreate` is applied solely if the Fast Data workload is the first time that is deployed. Otherwise, the parameter will be not considered by Control Plane, as it reads the last saved runtime state.
:::
@@ -165,7 +171,7 @@ If no `onCreate` behavior is defined in the microservice ConfigMap, the **defaul
## Application Deployment
-Once you have concluded all the above mentioned configuration steps, you can easily deploy your Project configuration!
+Once you have concluded all the above mentioned configuration steps, it's time to **deploy your Project**!
Verify the success of your deploy by:
diff --git a/versioned_docs/version-14.5.1/getting-started/faqs.md b/versioned_docs/version-14.5.1/getting-started/faqs.md
new file mode 100644
index 0000000000..7d13030abd
--- /dev/null
+++ b/versioned_docs/version-14.5.1/getting-started/faqs.md
@@ -0,0 +1,76 @@
+---
+id: faqs
+title: Mia-Platform FAQs
+sidebar_label: Mia-Platform FAQs
+---
+
+### Mia-Platform Console
+
+#### What is Mia-Platform Console?
+Mia-Platform Console is a Platform Builder used to create and manage a custom Internal Developer Platform (IDP). It is a centralized developer portal designed to industrialize and govern the entire cloud-native software development lifecycle, from infrastructure connection and API design to deployment and monitoring.
+
+#### What are the main benefits of using the Console?
+The main benefits are improved governance, developer self-service, and a lower cognitive load. It empowers development teams with self-service capabilities, abstracts away cloud-native complexity, and allows platform engineering teams to enforce standards and best practices, creating "golden paths" for developers.
+
+For a more detailed list of questions and answers about this product, see the [dedicated FAQ section](/getting-started/faqs/mia-platform-console-faqs.md).
+
+***
+
+### Mia-Platform Fast Data
+
+#### What is Mia-Platform Fast Data?
+Mia-Platform Fast Data is a solution for building a **Digital Integration Hub (DIH)**. It collects data from various sources, known as **Systems of Record (SoR)**, standardizes them into collections called **Projections**, and then aggregates them in near real-time into read-optimized data models called **Single Views**.
+
+#### Why would an organization use Fast Data?
+Organizations use Fast Data to create a high-performance, real-time data layer that decouples modern applications from legacy systems. This approach offloads legacy systems, ensures data is consistently available 24/7, and provides an up-to-date, aggregated view of fast-changing data to be consumed by APIs and applications with low latency.
+
+For a more detailed list of questions and answers about this product, see the [dedicated FAQ section](/getting-started/faqs/mia-platform-fast-data-faqs.md).
+
+***
+
+### Mia-Platform Microfrontend Composer
+
+#### What is the Microfrontend Composer?
+The Microfrontend Composer is a low-code/no-code tool within the Console for building user interfaces like backoffices, dashboards, and developer portals. It allows users to visually assemble pages by configuring and combining pre-built or custom web components.
+
+#### How does it work and what are its key components?
+The Composer is powered by **micro-lc**, an open-source microfrontend orchestrator that renders the final application. Pages are typically built using **Back-Kit**, a library of pre-built web components (tables, forms, buttons) that communicate with each other through an event-driven system. The entire application configuration is served by a lightweight web server.
+
+For a more detailed list of questions and answers about this product, see the [dedicated FAQ section](/getting-started/faqs/mia-platform-microfrontend-composer-faqs.md).
+
+***
+
+### Mia-Platform Data Catalog
+
+#### What is the purpose of the Mia-Platform Data Catalog?
+The Data Catalog is a centralized solution for discovering, understanding, and governing all data assets within an organization. It functions as a single source of truth, allowing users to find relevant datasets, understand their quality, and trace their origin and transformations (lineage).
+
+#### What kind of information can I find in the Data Catalog?
+For each data asset (like a database table or a Fast Data Projection), you can find detailed metadata, including its schema, a business description, owners, and tags. A key feature is **Data Lineage**, which provides a visual graph showing the data's origin and how it flows and transforms across different systems.
+
+For a more detailed list of questions and answers about this product, see the [dedicated FAQ section](/getting-started/faqs/mia-platform-data-catalog-faqs.md).
+
+***
+
+### Mia-Platform Software Catalog
+
+#### What is the Software Catalog and how is it different from the Marketplace?
+The **Software Catalog** is the backend management solution used by platform engineers to create, version, and govern all reusable software assets (like Plugins and Templates). The **Marketplace** is the user-facing UI inside the Console, where developers browse and consume the assets made available by the Software Catalog to add them to their projects.
+
+#### Why is the Software Catalog important for a Platform Engineering team?
+It is a crucial tool for implementing an effective Internal Developer Platform (IDP). It allows a platform team to enforce standardization and best practices by providing a curated library of approved components. This promotes reusability, accelerates development by offering "golden paths," and ensures governance over the software assets used across the organization.
+
+For a more detailed list of questions and answers about this product, see the [dedicated FAQ section](/getting-started/faqs/mia-platform-software-catalog-faqs.md).
+
+***
+
+### Runtime Components
+
+#### What are Runtime Components?
+Runtime Components are ready-to-use software assets available in the Marketplace that can be added to projects to speed up development. They are the functional building blocks, like plugins and templates, that developers use to assemble their applications on the platform.
+
+#### What is the main difference between a Plugin and a Template?
+* A **Plugin** is a pre-built, ready-to-use Docker image that functions like a "black box." You configure it but do not modify its source code. It's used for common, standardized functionalities.
+* A **Template** is a boilerplate Git repository that serves as a starting point. It gets cloned into your project, giving you full ownership of the code to modify and extend as needed. It's used for building custom services.
+
+For a more detailed list of questions and answers about this product, see the [dedicated FAQ section](/getting-started/faqs/mia-platform-runtime-components-faqs.md).
diff --git a/versioned_docs/version-14.5.1/getting-started/faqs/mia-platform-console-faqs.md b/versioned_docs/version-14.5.1/getting-started/faqs/mia-platform-console-faqs.md
new file mode 100644
index 0000000000..3243b73f83
--- /dev/null
+++ b/versioned_docs/version-14.5.1/getting-started/faqs/mia-platform-console-faqs.md
@@ -0,0 +1,246 @@
+---
+id: mia-platform-console-faqs
+title: Mia-Platform Console FAQs
+sidebar_label: Console FAQs
+---
+
+### General Concepts & Project Management
+
+#### What is the Mia-Platform Console?
+The Mia-Platform Console is a cloud-native Platform Builder that functions as an **Internal Developer Platform (IDP)**. It's designed to help organizations industrialize and govern the entire software development lifecycle. By providing a centralized **developer hub**, it simplifies cloud-native complexity, empowers development teams with self-service capabilities, and allows **platform engineers** to enforce governance and **platform engineering best practices**. The Mia-Platform Console manages everything from infrastructure connection to API design, deployment, and monitoring.
+[Discover more](/products/console/overview-dev-suite.md)
+
+#### What is a "Company" in the Mia-Platform Console?
+A **Company** is the highest-level organizational unit in the Mia-Platform Console. It acts as a container for multiple **Projects** and provides centralized governance. At the Company level, you configure shared resources that are inherited by all its projects, such as Kubernetes cluster connections, **Providers** (like Git providers and secret managers), and default project templates. This structure allows an organization to manage different business units or teams in an isolated and organized manner.
+[Discover more](/products/console/company-configuration/create-company.md)
+
+#### What is the difference between a Project and an Environment?
+* A **Project** is where you build your services. It contains all the necessary configurations, including microservices, APIs, data models (CRUDs), and public variables. Each Project belongs to a Company.
+* An **Environment** represents a specific deployment stage within a Project, such as `Development`, `Staging`, or `Production`. Each environment is mapped to a unique namespace in a Kubernetes cluster, allowing you to deploy and test your services in isolated runtime contexts.
+ [Discover more](/products/console/project-configuration/application-project.md)
+
+#### What is a "Project Blueprint" and why is it important?
+A **Project Blueprint** is a pre-configured Git repository that serves as a starting point for creating new Projects. It includes a default structure, sample configurations, and often pre-defined **CI/CD** pipelines. Using templates is a core aspect of **platform engineering best practices** because it enforces standardization, ensures consistency across projects, and dramatically speeds up the onboarding of new applications by providing developers with a "golden path".
+[Discover more](/products/console/company-configuration/project-blueprint.md)
+
+#### How do I create a new Project?
+To create a new Project, you must first have a Company, a Git Provider, a CI/CD Provider, a Secret Management Provider and a Project Template configured. From the Console homepage, click "Create Project" and follow the three-step wizard:
+1. **General**: Provide a name, description, and choose the project workflow (Standard or Enhanced).
+2. **Repository**: Select a Git Provider, define the repository path, set visibility, and choose a starting template.
+3. **Environments**: Review the environments that will be automatically configured based on the Company's defaults.
+ [Discover more](/products/console/project-configuration/create-a-project.mdx)
+
+#### What is the Enhanced Project Workflow and why should I use it?
+The Enhanced Project Workflow is a significant evolution from the standard, Git-centric model. It improves the developer experience by managing the project's logical state directly within the Console, rather than relying on Git for every change. This results in much faster performance in the Design area. Kubernetes configurations are generated only at deploy time, which also enables a pull-based, **GitOps** deployment strategy. It is the recommended workflow for all new projects.
+[Discover more](/products/console/set-up-infrastructure/overview.md)
+
+#### What is the difference between a branch and a revision in the Console?
+* In the **Standard Workflow**, the Console uses **branches** that directly correspond to Git branches in your configuration repository. All configuration changes are saved via commits to these branches.
+* In the **Enhanced Project Workflow**, the concept of branches is replaced by **Revisions**. A Revision is a line of development managed within the Console, consisting of a series of immutable snapshots. This approach decouples the design process from Git, which is only used to store the final orchestrator files upon deployment.
+ [Discover more](/products/console/set-up-infrastructure/revisions-and-versions.md)
+
+#### How do I save my configuration changes in the Design area?
+In the top-right corner of the Design area, click on the branch/revision name to open the management popover. If you have unsaved changes, a "Save configuration" button will be active. Clicking it opens a modal where you must provide a commit title and an optional message. This action creates a new commit (in Standard Workflow) or a new snapshot (in Enhanced Workflow). if there are remote changes and you want to make your changes too, a warning shows up when opening the action popover, telling the users that they have current local changes but there are also remote changes that should be addressed
+[Discover more](/products/console/api-console/api-design/overview.md)
+
+#### How can I merge configurations between two branches or revisions?
+From the branch/revision management popover in the Design area, you can select "Merge from another branch". This will open a diff editor where you can compare the configurations of the source and target branches/revisions side-by-side. You can review all changes, resolve conflicts by editing the configuration directly, and then confirm the merge. The merged configuration must then be saved.
+[Discover more](/products/console/api-console/api-design/merge_collaboration.md)
+
+#### What are Infrastructure Projects?
+Infrastructure Projects are a specialized project type designed for Operations teams and **platform engineers** to manage infrastructure using **Infrastructure as Code** (IaC) principles. Instead of managing applications, these projects manage infrastructure components like cloud resources (e.g., using **Terraform**) or Kubernetes operators. They support a two-phase deployment process (`plan` and `apply`) to ensure changes are reviewed before execution, providing better control over infrastructure provisioning.
+[Discover more](/products/console/project-configuration/infrastructure-project.md)
+
+#### How can I delete a Project?
+You can delete a Project from the **Project Settings -> Advanced** tab. Clicking the "Delete Project" button will open a confirmation modal where you must type the project's name to confirm. This action is irreversible and will remove the project from the Console, with options to also delete associated namespaces and archive the Git repository.
+[Discover more](/products/console/project-configuration/delete-a-project.md)
+
+---
+### Configuration & Design
+
+#### How do I create a new microservice in my project?
+You can create a microservice from the **Design -> Microservices** section, typically by starting from a **Template** or an **Example** from the Marketplace.
+1. Click "Create a Microservice" and select "From Marketplace".
+2. Choose a template (e.g., "Node.js Template" for **JavaScript** or "Spring Boot Template" for "Java").
+3. Provide a name, description, and specify the details for the new Git repository that will be created for your service's code.
+ After creation, you can configure its Docker image, resources, environment variables, and more.
+ [Discover more](/products/console/api-console/api-design/custom_microservice_get_started.md)
+
+#### What is the difference between creating a microservice from a Template vs. a Docker Image?
+* **From a Template/Example**: This method is for creating a *new* microservice. The Console creates a new Git repository for you by cloning the template's source code. You get a complete, ready-to-code starting point with best practices for logging, health checks, and **CI/CD** already configured.
+* **From a Docker Image**: This method is for integrating an *existing* microservice. You provide the name of a pre-built Docker image. The Console does not create a code repository; it only creates the configuration to deploy that existing image as part of your project.
+ [Discover more](/products/console/api-console/api-design/services.md)
+
+#### How do I expose a microservice with a public URL?
+To expose a microservice, you need to create an **Endpoint**.
+1. Go to **Design -> Endpoints** and click "Create new endpoint".
+2. Define a **Base Path** (e.g., `/my-api`), which is the public URL path.
+3. Set the **Type** to "Microservice".
+4. Select the microservice you want to expose from the dropdown.
+ This configuration instructs the API Gateway to handle **ingressing** traffic from the specified base path to your internal microservice.
+ [Discover more](/products/console/api-console/api-design/endpoints.md)
+
+#### What is the difference between Public Variables and Secret Variables?
+* **Public Variables** are environment-specific variables managed in the **Design -> Public Variables** section. They are stored in plain text within your Git configuration repository and are suitable for non-sensitive data, like feature flags or public URLs.
+* **Secret Variables** are for sensitive data like passwords or API tokens. They are managed in the **Project Overview -> Variables** section and are stored securely in a **secrets manager** (like GitLab CI/CD variables, HashiCorp Vault, or **Azure Key Vault**), not in the Git repository.
+ [Discover more](/products/console/project-configuration/manage-environment-variables/index.md)
+
+#### How do I configure Kubernetes probes (Liveness & Readiness) for my microservice?
+In the microservice's detail page, under the **Runtime** card, you can configure probes.
+* **Readiness Probe**: Tells Kubernetes when your container is ready to start accepting traffic.
+* **Liveness Probe**: Tells Kubernetes if your container is still running and healthy. If it fails, Kubernetes will restart the container.
+ For each probe, you can specify the path (e.g., `/-/healthz`), port, initial delay, and other parameters.
+ [Discover more](/products/console/api-console/api-design/microservice-runtime-resources.md)
+
+#### What is a CronJob in the Console and how do I create one?
+A **CronJob** is a Kubernetes resource that runs a job on a repeating schedule (e.g., for nightly data processing or cleanup tasks). You can create one from the **Design -> CronJobs** section. You need to provide a name, a Docker image to run, and a schedule in standard cron format (e.g., `0 2 * * *` for 2 AM daily).
+[Discover more](/products/console/api-console/api-design/jobs-cronjob.md)
+
+#### What is a CRUD and how do I create one?
+A CRUD is a data collection stored in MongoDB that is automatically exposed via a full set of RESTful APIs for Create, Read, Update, and Delete operations. This allows you to quickly bootstrap a data-driven service without writing any backend code. You can create one from the **Design -> MongoDB CRUD** section by providing a name for the collection and then defining its data schema (fields, types, and validation rules).
+[Discover more](/products/console/api-console/api-design/crud_advanced.md)
+
+#### How do I manage ConfigMaps for a microservice?
+In the microservice's detail page, go to the **ConfigMaps & Secrets** tab. Here you can create a new ConfigMap or mount an existing one. You define a **Runtime Mount Path** (where the files will be available inside the container) and then add files to the ConfigMap. This is useful for managing configuration files that are separate from your application code.
+[Discover more](/products/console/api-console/api-design/services.md)
+
+#### Can I use Kustomize for environment-specific configurations?
+Yes, Kustomize is fully supported. When you enable it for a project, an `overlays` directory is created in your configuration repository. Inside this directory, you can create a folder for each environment (e.g., `production`) containing patch files and a `kustomization.yaml`. These patches are applied over the base configuration at deployment time, allowing you to declaratively modify resources for specific environments.
+[Discover more](/products/console/project-configuration/kustomize-your-configurations/index.md)
+
+---
+### Deployment & Runtime
+
+#### How do I deploy my project's configuration?
+You deploy from the **Deploy** section.
+1. Select the target environment.
+2. Select the branch, tag, or version to deploy.
+3. Review the comparison of what's currently running versus the new configuration.
+4. Choose between **Smart Deploy** (only deploys changed services) or **Deploy All**.
+5. Clicking "Deploy" triggers the configured **CI/CD** pipeline to apply the changes to the cluster.
+ [Discover more](/products/console/deploy/overview.md)
+
+#### How does "Smart Deploy" work?
+**Smart Deploy** optimizes the deployment process by only redeploying services whose configurations have actually changed since the last deployment. The Console calculates a checksum of a service's configuration (including its Docker image, environment variables, mounted ConfigMaps, etc.). If the checksum in the new release is different from the one currently running in the environment, the service is marked for deployment. This saves time and resources, especially in large projects.
+[Discover more](/products/console/deploy/overview.md)
+
+#### What happens if a deployment fails and how can I check the history?
+If a deployment pipeline fails, the Console will show a "Failed" status in the **Deploy** section. The **History** tab in this section provides a log of all past deployments for each environment. You can see the status (Success, Failed, Pending), who triggered it, when it happened, and a direct link to the pipeline logs in your **CI/CD tool** to investigate the cause of the failure.
+[Discover more](/products/console/deploy/overview.md)
+
+#### How can I monitor the status of my deployed services?
+The **Runtime** section provides a live view of your Kubernetes resources. You can:
+* View the status of all **Pods** (running, pending, crashed).
+* Inspect individual pods to see CPU/memory usage, event history, and real-time logs.
+* Monitor other resources like **Deployments**, **Services**, and **CronJobs**.
+ [Discover more](/products/console/monitoring/introduction.md)
+
+#### How can I restart a single pod from the Console?
+Yes. Go to the **Runtime** section, find the pod you want to restart in the Pods list. On the right side of the pod's row, there is an options menu (three dots). Clicking it will reveal a "Restart" option. This will safely terminate the existing pod, and Kubernetes will automatically create a new one to replace it. This is useful for recovering a pod that is in a bad state.
+[Discover more](/products/console/monitoring/resources/pods.md)
+
+#### How can I view the logs of a running microservice?
+Go to the **Runtime** section, select the environment, and find the pod for your microservice. Clicking on the pod name takes you to its detail view. The **Logs** tab shows a real-time stream of the container's logs. You can pause the stream, search for keywords, and download the logs.
+[Discover more](/products/console/monitoring/resources/pods.md)
+
+#### How can I debug a service locally while it's connected to the remote cluster?
+The Console integrates with **Telepresence**. From the **Debug** section, you can get a command that intercepts traffic from the remote cluster and redirects it to the service instance running on your local machine. This allows you to use local debuggers and see code changes instantly without a full deployment cycle, which is a massive productivity boost.
+[Discover more](/products/console/debugging/telepresence.md)
+
+#### What is the API Portal?
+The API Portal, accessible from the **Documentation** section, automatically generates and displays interactive API documentation (using OpenAPI/Swagger) for all your exposed endpoints. Developers can use it to explore APIs, understand their schemas, and test them live by making API calls directly from the browser, which greatly accelerates integration tasks.
+[Discover more](/products/console/project-configuration/documentation-portal.md)
+
+---
+### Security & Access Management
+
+#### How does Role-Based Access Control (RBAC) work in the Console?
+The Console uses a hierarchical RBAC model. Permissions are grouped into **Roles** (e.g., `Developer`, `Maintainer`), and roles are assigned to users or groups at different levels (Console, Company, or Project). Permissions are inherited downwards, so a `Company Owner` has full admin rights over all projects within that company. This allows for both broad and granular control over who can do what.
+[Discover more](/products/console/identity-and-access-management/console-levels-and-permission-management.md)
+
+#### What is the difference between a `Developer` and a `Maintainer` role?
+The key difference is deployment rights.
+* A **`Developer`** can edit the project configuration in the Design area (create services, endpoints, etc.) and save their changes. They can view runtime environments but cannot deploy to them.
+* A **`Maintainer`** has all the permissions of a Developer, plus the ability to trigger deployments to runtime environments. This role is typically assigned to team leads or senior developers responsible for releases.
+ [Discover more](/products/console/identity-and-access-management/console-levels-and-permission-management.md)
+
+#### How do I add a new user to my Company or Project?
+A `Company Owner` can add users at the Company level from the **IAM -> Users** section by inviting them via email and assigning a role. A `Project Administrator` can manage roles for existing company users at the Project level. You can assign roles directly to individual users or, for easier management, add users to a **Group** that has the desired role.
+[Discover more](/products/console/identity-and-access-management/manage-users.md)
+
+#### How do I create a Service Account and what is it used for?
+A `Company Owner` can create a **Service Account** from the **IAM -> Service Accounts** section. A Service Account is a non-human identity used for automation, primarily in **CI/CD** pipelines. Instead of a username/password, it uses client credentials or a private key JWT for authentication. You assign it a role just like a regular user to grant it the specific permissions it needs to perform its tasks, such as triggering a deployment.
+[Discover more](/products/console/identity-and-access-management/manage-service-accounts.md)
+
+#### How do Groups simplify user management?
+Groups allow you to manage permissions for multiple users at once. Instead of assigning the `Developer` role to 20 individual users, you can create a "Developers" group, assign the `Developer` role to the group, and then add the 20 users to that group. All members of the group inherit the role's permissions. This is much more efficient and less error-prone, especially for large teams.
+[Discover more](/products/console/identity-and-access-management/manage-groups.md)
+
+#### How do I protect an endpoint?
+You can secure an endpoint from its configuration page in the **Design -> Endpoints** section. The **Security** tab offers several options:
+* **Authentication required**: If checked, the user must be logged in.
+* **API Key required**: If checked, a valid API Key must be sent in the `client-key` or `secret` header.
+* **User Group Permission**: An expression-based rule for fine-grained control. You can write logic based on the user's groups (e.g., `groups.admin`) or the API key's client type (e.g., `clientType == 'my-app'`).
+ [Discover more](/products/console/api-console/api-design/endpoints.md)
+
+#### How does the authorization flow work for a protected endpoint?
+1. A client sends a request with credentials to the **API Gateway**.
+2. The API Gateway forwards the request headers to the **Authorization Service**.
+3. The Authorization Service calls an **Authentication Manager** (like the `auth0-client`) to validate the credentials and get user information (ID, groups, etc.).
+4. The Authorization Service evaluates the endpoint's **User Group Permission** expression against the user's info.
+5. If authorized, it returns success to the API Gateway, which then forwards the request to the target microservice, adding headers like `miauserid` and `miausergroups`.
+ [Discover more](/products/console/project-configuration/authorization-flow.md)
+
+#### How can I implement more advanced authorization with policies?
+For advanced authorization, you can enable **Rönd**, an open-source sidecar based on Open Policy Agent (OPA). With Rönd, you can write declarative policies in the **Rego** language to enforce complex rules, such as:
+* **Row Filtering**: Filtering data from a CRUD response based on user attributes (e.g., a user can only see their own orders).
+* **Response Filtering**: Removing specific fields from a response body (e.g., hiding a `salary` field from non-admin users).
+* **Attribute-Based Access Control (ABAC)** on the request itself.
+ [Discover more](/products/console/api-console/api-design/authorization.md)
+
+---
+### Advanced Features & Extensibility
+
+#### How can I extend the Console with custom functionality?
+The Console's **Extensibility** feature allows you to add custom pages to the sidebar navigation by embedding external web applications as an `