diff --git a/claude/content/wiki/_index.md b/claude/content/wiki/_index.md
index 4ef1461..8fd1d5b 100644
--- a/claude/content/wiki/_index.md
+++ b/claude/content/wiki/_index.md
@@ -31,7 +31,7 @@ The result is collaboration that feels like working with an expert colleague who
 The platform consists of two primary architectural systems that work together to transform AI interactions into persistent professional collaboration.
 
 > [!NOTE]
-> The platform was designed using **Site Reliability Engineering** methodologies and **behavioral psychology** principles, treating AI collaboration as infrastructure requiring systematic observability, monitoring, and reliability engineering for consistent professional partnership.
+> The platform was [designed](/wiki/guide/components/design) using **Site Reliability Engineering** methodologies and **behavioral psychology** principles, treating AI collaboration as infrastructure requiring systematic observability, monitoring, and reliability engineering for consistent professional partnership.
 
 ### Platform Components
 
diff --git a/k3s-cluster/content/tutorials/handbook/ansible/_index.md b/k3s-cluster/content/tutorials/handbook/ansible/_index.md
index f4598e0..fde21d5 100644
--- a/k3s-cluster/content/tutorials/handbook/ansible/_index.md
+++ b/k3s-cluster/content/tutorials/handbook/ansible/_index.md
@@ -57,10 +57,10 @@ ansible_password: !vault |
           36613833363662323261373266333565633430643639366435303061313039643637
 ```
 
-Insert the `ansible_password` encrypted output into [`all.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/inventory/cluster/group_vars/all.yaml) group variables file, while respecting the *existing* indentation.
+Insert the `ansible_password` encrypted output into [`all.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/inventory/cluster/group_vars/all.yaml) group variables file, while respecting the _existing_ indentation.
 
 > [!TIP]
-> Once all variables have been initially encrypted with the same global password, they can be decrypted or updated with the [Vault](/k3s-cluster/wiki/guide/playbooks/vault) playbook.
+> Once all variables have been initially encrypted with the same global password, they can be decrypted or updated with the [Vault](/wiki/guide/playbooks/vault) playbook.
 
 ### Playbook Usage
 
diff --git a/k3s-cluster/content/tutorials/handbook/argocd/_index.md b/k3s-cluster/content/tutorials/handbook/argocd/_index.md
index 1d81cf3..b71f52c 100644
--- a/k3s-cluster/content/tutorials/handbook/argocd/_index.md
+++ b/k3s-cluster/content/tutorials/handbook/argocd/_index.md
@@ -13,7 +13,7 @@ This repository uses [ArgoCD](https://argoproj.github.io/cd) to deploy applicati
 See the related role variables, defined into [`main.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/argo-cd/defaults/main.yaml) defaults file. Review the [`README.md`](https://{{< param variables.repository.cluster >}}/tree/main/roles/argo-cd) file, for additional details and the advanced configuration settings, listed below.
 
 > [!IMPORTANT]
-> A [role upgrade](/k3s-cluster/wiki/guide/configuration/roles/argocd/#upgrade) is required, in order to apply any changes related to configuration.
+> A [role upgrade](/wiki/guide/configuration/roles/argocd/#upgrade) is required, in order to apply any changes related to configuration.
 
 ### Credentials
 
@@ -23,9 +23,9 @@ While still implemented, the `admin` credentials are disabled by default and `us
 argocd_resources:
   server:
     users:
-      - name: '{{ argocd_map.credentials.server.user.name }}'
-        password: '{{ argocd_map.credentials.server.user.password }}'
-        permissions: 'apiKey, login'
+      - name: "{{ argocd_map.credentials.server.user.name }}"
+        password: "{{ argocd_map.credentials.server.user.password }}"
+        permissions: "apiKey, login"
         role: admin
         enabled: true
 ```
@@ -40,7 +40,7 @@ The `name` and `password` keys listed above are defined into [`all.yaml`](https:
 Additional configuration parameters can be defined into [`config_params.j2`](https://{{< param variables.repository.cluster >}}/blob/main/roles/argo-cd/templates/config_params.j2) template.
 
 > [!TIP]
-> Perform a [role validation](/k3s-cluster/wiki/guide/configuration/roles/argocd/#validation), to visualize all rendered templates and variables.
+> Perform a [role validation](/wiki/guide/configuration/roles/argocd/#validation), to visualize all rendered templates and variables.
 
 ### RBAC
 
@@ -48,7 +48,7 @@ Additional RBAC policies can be defined into [`config_rbac.j2`](https://{{< para
 
 ## Repository Setup
 
-Login into [ArgoCD UI](/k3s-cluster/tutorials/handbook/externaldns/#argocd), navigate to `ArgoCD Settings` > `Repositories` and connect to official project repository:
+Login into [ArgoCD UI](/tutorials/handbook/externaldns/#argocd), navigate to `ArgoCD Settings` > `Repositories` and connect to official project repository:
 
 | Key     | Value                                                         |
 | :------ | :------------------------------------------------------------ |
diff --git a/k3s-cluster/content/tutorials/handbook/cilium/_index.md b/k3s-cluster/content/tutorials/handbook/cilium/_index.md
index 791a81d..e7cc4cf 100644
--- a/k3s-cluster/content/tutorials/handbook/cilium/_index.md
+++ b/k3s-cluster/content/tutorials/handbook/cilium/_index.md
@@ -18,7 +18,7 @@ Due to the intricate nature of its requirements, Cilium is deployed in three ste
 
 ## Dependencies
 
-See below the required Cilium dependencies, used into chart configuration. 
+See below the required Cilium dependencies, used into chart configuration.
 
 ### CertManager
 
@@ -30,6 +30,7 @@ During chart post-install provisioning, Cilium Hubble is configured to take adva
 
 > [!IMPORTANT]
 > Cilium details the following instructions, into their `cert-manager` [installation](https://docs.cilium.io/en/latest/observability/hubble/configuration/tls) steps:
+>
 > > Please make sure that your issuer is able to create certificates under the `cilium.io` domain name.
 >
 > CertManager cannot control a domain not owned by end-user, therefore the above listed `Certificate` and `ClusterIssuer` resources are created.
@@ -42,7 +43,7 @@ Refer to Cilium Hubble [documentation](https://docs.cilium.io/en/stable/gettings
 
 #### Usage Example
 
-This is an example of `Gateway` and `HTTPRoute` resources usage for [Cilium Hubble UI](/k3s-cluster/tutorials/handbook/externaldns/#cilium), as replacement for `Ingress` resource:
+This is an example of `Gateway` and `HTTPRoute` resources usage for [Cilium Hubble UI](/tutorials/handbook/externaldns/#cilium), as replacement for `Ingress` resource:
 
 - `Gateway` resource template, see [`gateway.j2`](https://{{< param variables.repository.cluster >}}/blob/main/roles/cilium/templates/gateway.j2)
 - `HTTPRoute` insecure resource template, see [`http_route_insecure.j2`](https://{{< param variables.repository.cluster >}}/blob/main/roles/cilium/templates/http_route_insecure.j2)
diff --git a/k3s-cluster/content/tutorials/handbook/externaldns/_index.md b/k3s-cluster/content/tutorials/handbook/externaldns/_index.md
index 0a40c3b..3bd5060 100644
--- a/k3s-cluster/content/tutorials/handbook/externaldns/_index.md
+++ b/k3s-cluster/content/tutorials/handbook/externaldns/_index.md
@@ -13,13 +13,13 @@ This repository uses [ExternalDNS](https://github.com/kubernetes-sigs/external-d
 Generate the Cloudflare domain [API token](https://developers.cloudflare.com/fundamentals/api/get-started/create-token/), with following permissions:
 
 {{< filetree/container >}}
-  {{< filetree/folder name="ACCOUNT" >}}
-    {{< filetree/folder name="domain.com - Zone:Read, DNS:Edit" state="closed" >}}
-    {{< /filetree/folder >}}
-  {{< /filetree/folder >}}
+{{< filetree/folder name="ACCOUNT" >}}
+{{< filetree/folder name="domain.com - Zone:Read, DNS:Edit" state="closed" >}}
+{{< /filetree/folder >}}
+{{< /filetree/folder >}}
 {{< /filetree/container >}}
 
-Encrypt the `global_map.credentials.externaldns.cloudflare.api.token` value with [`ansible-vault`](/k3s-cluster/tutorials/handbook/ansible/#vault) and insert it into 
+Encrypt the `global_map.credentials.externaldns.cloudflare.api.token` value with [`ansible-vault`](/tutorials/handbook/ansible/#vault) and insert it into
 [`all.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/inventory/cluster/group_vars/all.yaml) group variables file.
 
 ## Front-Ends
diff --git a/k3s-cluster/content/tutorials/handbook/k3s-monitor/_index.md b/k3s-cluster/content/tutorials/handbook/k3s-monitor/_index.md
index 1c7d975..3b147e6 100644
--- a/k3s-cluster/content/tutorials/handbook/k3s-monitor/_index.md
+++ b/k3s-cluster/content/tutorials/handbook/k3s-monitor/_index.md
@@ -13,39 +13,39 @@ The **K3s Monitor** tool is a comprehensive Python utility designed to collect,
 
 ## Tool Features
 
-* **Cluster Resource Monitoring**: Collects various resource metrics from nodes and pods
-* **Component-Specific Monitoring**: Tracks resource usage for all K3s Cluster [components](/k3s-cluster/wiki/guide/configuration/roles/#charts)
-* **Log Collection**: Gathers logs from system services and Kubernetes components
-* **Automated Analysis**: Identifies high resource consumption and potential issues
-* **Comparative Reporting**: Compares current metrics with previous monitoring runs
-* **Comprehensive Summary**: Generates detailed reports with recommendations, ready for AI-assisted analysis with tools like [Claude](https://claude.ai)
+- **Cluster Resource Monitoring**: Collects various resource metrics from nodes and pods
+- **Component-Specific Monitoring**: Tracks resource usage for all K3s Cluster [components](/wiki/guide/configuration/roles/#charts)
+- **Log Collection**: Gathers logs from system services and Kubernetes components
+- **Automated Analysis**: Identifies high resource consumption and potential issues
+- **Comparative Reporting**: Compares current metrics with previous monitoring runs
+- **Comprehensive Summary**: Generates detailed reports with recommendations, ready for AI-assisted analysis with tools like [Claude](https://claude.ai)
 
 ## Prerequisites
 
-The following dependencies are required to run the **K3s Monitor** tool, automatically deployed with [Provisioning](/k3s-cluster/wiki/guide/playbooks/provisioning) playbook:
+The following dependencies are required to run the **K3s Monitor** tool, automatically deployed with [Provisioning](/wiki/guide/playbooks/provisioning) playbook:
 
-* Python 3.8+
-* `python3-kubernetes` library
-* `python3-yaml` library
-* `kubectl` configured to access the K3s cluster
-* `journalctl` for log collection
-* `jq` for JSON processing
+- Python 3.8+
+- `python3-kubernetes` library
+- `python3-yaml` library
+- `kubectl` configured to access the K3s cluster
+- `journalctl` for log collection
+- `jq` for JSON processing
 
 ## Generated Reports
 
 The following reports are generated:
 
-* **cilium-metrics.log**: Detailed Cilium networking status, endpoints and services information
-* **cluster-info.log**: Basic information about the cluster
-* **comparison.log**: Comparison with previous monitoring runs
-* **component-metrics.csv**: Time-series data for component resource usage
-* **summary.log**: Overall resource usage summary and recommendations
-* **etcd-metrics.log**: Status of HA clusters, `etcd` cluster health and metrics
-* **k3s-monitor.log**: Operational log of the monitoring tool itself, including all actions taken during execution
-* **log-summary.txt**: Summary of important log events (errors, warnings)
-* **pod-metrics.csv**: Detailed pod-level resource metrics
-* **sysctl.txt**: System kernel parameter settings
-* **summary.log**: Overall resource usage summary and recommendations
+- **cilium-metrics.log**: Detailed Cilium networking status, endpoints and services information
+- **cluster-info.log**: Basic information about the cluster
+- **comparison.log**: Comparison with previous monitoring runs
+- **component-metrics.csv**: Time-series data for component resource usage
+- **summary.log**: Overall resource usage summary and recommendations
+- **etcd-metrics.log**: Status of HA clusters, `etcd` cluster health and metrics
+- **k3s-monitor.log**: Operational log of the monitoring tool itself, including all actions taken during execution
+- **log-summary.txt**: Summary of important log events (errors, warnings)
+- **pod-metrics.csv**: Detailed pod-level resource metrics
+- **sysctl.txt**: System kernel parameter settings
+- **summary.log**: Overall resource usage summary and recommendations
 
 See below the directories and files structure, containing the generated reports.
 
@@ -53,38 +53,38 @@ See below the directories and files structure, containing the generated reports.
 > Submit the generated tarball to [Claude](https://claude.ai), for AI-assisted analysis. Upload the tarball to a chat with Claude and ask for an analysis of your K3s cluster metrics and performance.
 
 {{< filetree/container >}}
-  {{< filetree/folder name="/var/log/k3s" >}}
-    {{< filetree/folder name="YYYYMMDD-HHMMSS (click to expand)" state="closed" >}}
-      {{< filetree/file name="cilium-metrics.log" >}}
-      {{< filetree/file name="cluster-info.log" >}}
-      {{< filetree/file name="comparison.log" >}}
-      {{< filetree/file name="component-metrics.csv" >}}
-      {{< filetree/file name="etcd-metrics.log" >}}
-      {{< filetree/file name="k3s-monitor.log" >}}
-      {{< filetree/file name="log-summary.txt" >}}
-      {{< filetree/file name="pod-metrics.csv" >}}
-      {{< filetree/folder name="service" >}}
-        {{< filetree/folder name="components" >}}
-          {{< filetree/file name="argo-cd_YYYYMMDD-HHMMSS.log" >}}
-          {{< filetree/file name="cert-manager_YYYYMMDD-HHMMSS.log" >}}
-          {{< filetree/file name="cilium_YYYYMMDD-HHMMSS.log" >}}
-          {{< filetree/file name="coredns_YYYYMMDD-HHMMSS.log" >}}
-          {{< filetree/file name="external-dns_YYYYMMDD-HHMMSS.log" >}}
-          {{< filetree/file name="kured_YYYYMMDD-HHMMSS.log" >}}
-          {{< filetree/file name="longhorn_YYYYMMDD-HHMMSS.log" >}}
-          {{< filetree/file name="metrics-server_YYYYMMDD-HHMMSS.log" >}}
-          {{< filetree/file name="victorialogs_YYYYMMDD-HHMMSS.log" >}}
-          {{< filetree/file name="victoriametrics_YYYYMMDD-HHMMSS.log" >}}
-        {{< /filetree/folder >}}
-        {{< filetree/file name="containerd.log" >}}
-        {{< filetree/file name="k3s.log" >}}
-        {{< filetree/file name="kubelet.log" >}}
-      {{< /filetree/folder >}}
-      {{< filetree/file name="summary.log" >}}
-      {{< filetree/file name="sysctl.txt" >}}
-    {{< /filetree/folder >}}
-    {{< filetree/file name="k3s-monitor-YYYYMMDD-HHMMSS.tar.gz" >}}
-  {{< /filetree/folder >}}
+{{< filetree/folder name="/var/log/k3s" >}}
+{{< filetree/folder name="YYYYMMDD-HHMMSS (click to expand)" state="closed" >}}
+{{< filetree/file name="cilium-metrics.log" >}}
+{{< filetree/file name="cluster-info.log" >}}
+{{< filetree/file name="comparison.log" >}}
+{{< filetree/file name="component-metrics.csv" >}}
+{{< filetree/file name="etcd-metrics.log" >}}
+{{< filetree/file name="k3s-monitor.log" >}}
+{{< filetree/file name="log-summary.txt" >}}
+{{< filetree/file name="pod-metrics.csv" >}}
+{{< filetree/folder name="service" >}}
+{{< filetree/folder name="components" >}}
+{{< filetree/file name="argo-cd_YYYYMMDD-HHMMSS.log" >}}
+{{< filetree/file name="cert-manager_YYYYMMDD-HHMMSS.log" >}}
+{{< filetree/file name="cilium_YYYYMMDD-HHMMSS.log" >}}
+{{< filetree/file name="coredns_YYYYMMDD-HHMMSS.log" >}}
+{{< filetree/file name="external-dns_YYYYMMDD-HHMMSS.log" >}}
+{{< filetree/file name="kured_YYYYMMDD-HHMMSS.log" >}}
+{{< filetree/file name="longhorn_YYYYMMDD-HHMMSS.log" >}}
+{{< filetree/file name="metrics-server_YYYYMMDD-HHMMSS.log" >}}
+{{< filetree/file name="victorialogs_YYYYMMDD-HHMMSS.log" >}}
+{{< filetree/file name="victoriametrics_YYYYMMDD-HHMMSS.log" >}}
+{{< /filetree/folder >}}
+{{< filetree/file name="containerd.log" >}}
+{{< filetree/file name="k3s.log" >}}
+{{< filetree/file name="kubelet.log" >}}
+{{< /filetree/folder >}}
+{{< filetree/file name="summary.log" >}}
+{{< filetree/file name="sysctl.txt" >}}
+{{< /filetree/folder >}}
+{{< filetree/file name="k3s-monitor-YYYYMMDD-HHMMSS.tar.gz" >}}
+{{< /filetree/folder >}}
 {{< /filetree/container >}}
 
 ## Tool Usage
@@ -111,7 +111,7 @@ options:
   -n NAMESPACE, --namespace NAMESPACE
                         Default namespace (default: kube-system)
   -v, --verbose         Enable verbose logging (default: False)
-  ```
+```
 
 See below various **K3s Monitor** tool usage examples.
 
@@ -145,9 +145,9 @@ sudo k3s-monitor --duration 600 --interval 60
 
 ## Best Practices
 
-* **Regular Monitoring**: Run the tool periodically (e.g., weekly) to establish baseline metrics
-* **After Changes**: Run after cluster upgrades or significant workload changes
-* **Retention**: Keep monitoring results for trend analysis
-* **Size Appropriately**: Adjust duration and interval based on cluster size:
-  * Small clusters: 1-hour duration, 5-minute intervals
-  * Large clusters: 6-hour duration, 15-minute intervals
+- **Regular Monitoring**: Run the tool periodically (e.g., weekly) to establish baseline metrics
+- **After Changes**: Run after cluster upgrades or significant workload changes
+- **Retention**: Keep monitoring results for trend analysis
+- **Size Appropriately**: Adjust duration and interval based on cluster size:
+  - Small clusters: 1-hour duration, 5-minute intervals
+  - Large clusters: 6-hour duration, 15-minute intervals
diff --git a/k3s-cluster/content/tutorials/handbook/k3s/_index.md b/k3s-cluster/content/tutorials/handbook/k3s/_index.md
index bed23bd..e3c4ca3 100644
--- a/k3s-cluster/content/tutorials/handbook/k3s/_index.md
+++ b/k3s-cluster/content/tutorials/handbook/k3s/_index.md
@@ -25,15 +25,15 @@ The end-user can use `kubectl` to operate the cluster via local terminal, or [Le
 [![K3s: Lens](k3s-lens.webp)](k3s-lens.webp)
 
 > [!TIP]
-> Lens automatically detects and exposes the metrics produced by [VictoriaMetrics](/k3s-cluster/wiki/guide/configuration/roles/victoriametrics) role.
+> Lens automatically detects and exposes the metrics produced by [VictoriaMetrics](/wiki/guide/configuration/roles/victoriametrics) role.
 
 ## Upgrade
 
-Upon a new K3s version release, end-user can perform a [role upgrade](/k3s-cluster/wiki/guide/configuration/roles/k3s/#upgrade), which will schedule a [Kured](/k3s-cluster/wiki/guide/configuration/roles/kured) reboot.
+Upon a new K3s version release, end-user can perform a [role upgrade](/wiki/guide/configuration/roles/k3s/#upgrade), which will schedule a [Kured](/wiki/guide/configuration/roles/kured) reboot.
 
 ### Manual Upgrade
 
-Once the [role upgrade](/k3s-cluster/wiki/guide/configuration/roles/k3s/#upgrade) performed, end-user can choose to manually upgrade each cluster node. A [node drain](/k3s-cluster/tutorials/handbook/longhorn/#node-drain) must be executed one node at the time, followed by a node reboot. Once the node is up and running, it can be uncordoned with Lens or `kubectl`, via local terminal:
+Once the [role upgrade](/wiki/guide/configuration/roles/k3s/#upgrade) performed, end-user can choose to manually upgrade each cluster node. A [node drain](/tutorials/handbook/longhorn/#node-drain) must be executed one node at the time, followed by a node reboot. Once the node is up and running, it can be uncordoned with Lens or `kubectl`, via local terminal:
 
 ```shell
 kubectl uncordon <node>
diff --git a/k3s-cluster/content/tutorials/handbook/kured/_index.md b/k3s-cluster/content/tutorials/handbook/kured/_index.md
index 60c47c7..7738ae9 100644
--- a/k3s-cluster/content/tutorials/handbook/kured/_index.md
+++ b/k3s-cluster/content/tutorials/handbook/kured/_index.md
@@ -30,7 +30,7 @@ https://hooks.slack.com/services/<token>/<token>/<token>
 
 ### Notify URL
 
-Encrypt the `global_map.credentials.kured.slack.notify.url` value with [`ansible-vault`](/k3s-cluster/tutorials/handbook/ansible/#vault) and insert it into 
+Encrypt the `global_map.credentials.kured.slack.notify.url` value with [`ansible-vault`](/tutorials/handbook/ansible/#vault) and insert it into
 [`all.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/inventory/cluster/group_vars/all.yaml) group variables file. Notify URL decrypted format:
 
 ```yaml
diff --git a/k3s-cluster/content/tutorials/handbook/server/_index.md b/k3s-cluster/content/tutorials/handbook/server/_index.md
index 4b77d0a..0537cde 100644
--- a/k3s-cluster/content/tutorials/handbook/server/_index.md
+++ b/k3s-cluster/content/tutorials/handbook/server/_index.md
@@ -33,7 +33,7 @@ On each cluster node, under `OS Customisation: General` section, set **only** th
 ![OS General Settings: Imager General](server-imager-general.webp)
 
 > [!IMPORTANT]
-> Use the `username` defined above to set the [`ansible_username`](/k3s-cluster/wiki/guide/configuration/user) variable.
+> Use the `username` defined above to set the [`ansible_username`](/wiki/guide/configuration/user) variable.
 
 ### OS Services
 
@@ -100,7 +100,7 @@ product: Raspberry Pi 4 Model B Rev 1.5
 See the `cluster_vars.device` settings listed below, defined into [`main.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/cluster/defaults/main.yaml) defaults file.
 
 > [!NOTE]
-> To prevent premature wear and improve system performance, the [Provisioning](/k3s-cluster/wiki/guide/playbooks/provisioning) playbook disables the `atime` timestamp on storage device mounts.
+> To prevent premature wear and improve system performance, the [Provisioning](/wiki/guide/playbooks/provisioning) playbook disables the `atime` timestamp on storage device mounts.
 
 {{% steps %}}
 
@@ -127,7 +127,7 @@ Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 For example, connecting the storage device with different USB cable models might result in a different `device.name`. Similarly, connecting the storage device to a different USB port will result in a different `device.id`.
 
 > [!TIP]
-> Run the [Validation](/k3s-cluster/wiki/guide/playbooks/validation) playbook, to validate the USB storage device values.
+> Run the [Validation](/wiki/guide/playbooks/validation) playbook, to validate the USB storage device values.
 
 ### `device.id`
 
@@ -188,7 +188,7 @@ If the output is as listed below, no action is required:
 ```
 
 > [!NOTE]
-> The [Provisioning](/k3s-cluster/wiki/guide/playbooks/provisioning) playbook will validate on each cluster node if the above format is respected, and correct it if needed.
+> The [Provisioning](/wiki/guide/playbooks/provisioning) playbook will validate on each cluster node if the above format is respected, and correct it if needed.
 
 You can check the detected server node FQDNs, by running:
 
diff --git a/k3s-cluster/content/tutorials/handbook/tools/_index.md b/k3s-cluster/content/tutorials/handbook/tools/_index.md
index 37e6cbf..9b27712 100644
--- a/k3s-cluster/content/tutorials/handbook/tools/_index.md
+++ b/k3s-cluster/content/tutorials/handbook/tools/_index.md
@@ -30,7 +30,7 @@ brew tap robusta-dev/homebrew-krr
 brew install krr
 ```
 
-Example of running a `simple` strategy, using the [Prometheus endpoint](/k3s-cluster/tutorials/handbook/externaldns/#victoria-metrics):
+Example of running a `simple` strategy, using the [Prometheus endpoint](/tutorials/handbook/externaldns/#victoria-metrics):
 
 ```shell
 krr simple -p https://metrics.domain.com/prometheus -n kube-system --allow-hpa
diff --git a/k3s-cluster/content/wiki/_index.md b/k3s-cluster/content/wiki/_index.md
index eceb741..6fa6cfc 100644
--- a/k3s-cluster/content/wiki/_index.md
+++ b/k3s-cluster/content/wiki/_index.md
@@ -22,12 +22,12 @@ The following hardware was used to deploy the cluster:
 
 ## Network
 
-Prior starting the cluster configuration, the end-user must determine if the [network](/k3s-cluster/tutorials/handbook/network) configuration can support **load balancing** with [external IP addresses](https://kubernetes.io/docs/tutorials/stateless-application/expose-external-ip-address) assigned from a load balancer [IP pool](https://docs.cilium.io/en/stable/network/lb-ipam). Some retail routers do not have this capability.
+Prior starting the cluster configuration, the end-user must determine if the [network](/tutorials/handbook/network) configuration can support **load balancing** with [external IP addresses](https://kubernetes.io/docs/tutorials/stateless-application/expose-external-ip-address) assigned from a load balancer [IP pool](https://docs.cilium.io/en/stable/network/lb-ipam). Some retail routers do not have this capability.
 
 ## Next
 
 Dive right into the following section, to get started:
 
 {{< cards >}}
-  {{< card icon="adjustments" link="getting-started" title="Getting Started" subtitle="Set the local deployment environment." >}}
+{{< card icon="adjustments" link="getting-started" title="Getting Started" subtitle="Set the local deployment environment." >}}
 {{< /cards >}}
diff --git a/k3s-cluster/content/wiki/guide/configuration/_index.md b/k3s-cluster/content/wiki/guide/configuration/_index.md
index f7f837b..6c759ba 100644
--- a/k3s-cluster/content/wiki/guide/configuration/_index.md
+++ b/k3s-cluster/content/wiki/guide/configuration/_index.md
@@ -18,11 +18,11 @@ The configuration guides present in this section allow you to configure the K3s
 Each cluster node must have Ubuntu Server `{{< param variables.os.version >}}+` LTS (64-bits) OS installed, which is a requirement for [Cilium](https://cilium.io). The required `apt` package dependencies changed also, compared to previous Ubuntu Server LTS release.
 
 > [!TIP]
-> Read the [OS Installation](/k3s-cluster/tutorials/handbook/server) tutorial, on bare-metal infrastructure.
+> Read the [OS Installation](/tutorials/handbook/server) tutorial, on bare-metal infrastructure.
 
 ## Ansible Vault
 
 All sensitive data stored in this public repository (passwords, emails, etc.) is safely encrypted, using [Ansible Vault](https://docs.ansible.com/ansible/latest/cli/ansible-vault.html).
 
 > [!IMPORTANT]
-> Use the **same global password** for various encrypted settings, in your configuration files. See an [example](/k3s-cluster/tutorials/handbook/ansible/#encrypted-variables), to understand the logic behind.
+> Use the **same global password** for various encrypted settings, in your configuration files. See an [example](/tutorials/handbook/ansible/#encrypted-variables), to understand the logic behind.
diff --git a/k3s-cluster/content/wiki/guide/configuration/inventory.md b/k3s-cluster/content/wiki/guide/configuration/inventory.md
index f8dd002..0bb0775 100644
--- a/k3s-cluster/content/wiki/guide/configuration/inventory.md
+++ b/k3s-cluster/content/wiki/guide/configuration/inventory.md
@@ -5,7 +5,7 @@ next: /wiki/guide/configuration/user
 weight: 1
 ---
 
-Ansible automates tasks on managed nodes (also named *hosts*) in cluster infrastructure, using a list or group of lists, known as [inventory](https://docs.ansible.com/ansible/latest/inventory_guide/intro_inventory.html). 
+Ansible automates tasks on managed nodes (also named _hosts_) in cluster infrastructure, using a list or group of lists, known as [inventory](https://docs.ansible.com/ansible/latest/inventory_guide/intro_inventory.html).
 
 <!--more-->
 
@@ -17,11 +17,11 @@ There are two key configuration settings, influencing how the cluster will be de
 
 ### Playbook Batch Size
 
-Because K3s uses [tokens](https://docs.k3s.io/cli/token) to secure the node join process, a [`serial`](https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_strategies.html#setting-the-batch-size-with-serial) must be defined, generating the token on first `cluster` type node. Next, the generated token is copied into additional nodes, while running the [Provisioning](/k3s-cluster/wiki/guide/playbooks/provisioning) playbook.
+Because K3s uses [tokens](https://docs.k3s.io/cli/token) to secure the node join process, a [`serial`](https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_strategies.html#setting-the-batch-size-with-serial) must be defined, generating the token on first `cluster` type node. Next, the generated token is copied into additional nodes, while running the [Provisioning](/wiki/guide/playbooks/provisioning) playbook.
 
 #### Batch Size Usage
 
-Example of `serial` structure with 3 `server` type nodes and 5 `agent` type nodes, used into [Provisioning](/k3s-cluster/wiki/guide/playbooks/provisioning) playbook:
+Example of `serial` structure with 3 `server` type nodes and 5 `agent` type nodes, used into [Provisioning](/wiki/guide/playbooks/provisioning) playbook:
 
 {{% details title="Provisioning Details" closed="true" %}}
 
@@ -43,7 +43,7 @@ The `serial` structure has the following pattern:
 > [!TIP]
 > Update the `serial` structure into [`provisioning.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/provisioning.yaml) playbook file.
 
-Example of `serial` structure with 3 `server` type nodes and 5 `agent` type nodes, used into [Reset](/k3s-cluster/wiki/guide/playbooks/reset) playbook:
+Example of `serial` structure with 3 `server` type nodes and 5 `agent` type nodes, used into [Reset](/wiki/guide/playbooks/reset) playbook:
 
 {{% details title="Reset Details" closed="true" %}}
 
@@ -139,7 +139,7 @@ To address this issue, set the `k3s_vars.server.controlplane.tainted` option to
 The minimum number of server type nodes for a Non HA cluster is 1. By [K3s Architecture](https://docs.k3s.io/architecture) design, a cluster can have either 1, or 3+ `server` type nodes.
 
 > [!IMPORTANT]
-> If the targeted cluster has less than 3 `server` type nodes, the [Provisioning](/k3s-cluster/wiki/guide/playbooks/provisioning) playbook will automatically disable all related HA features. 
+> If the targeted cluster has less than 3 `server` type nodes, the [Provisioning](/wiki/guide/playbooks/provisioning) playbook will automatically disable all related HA features.
 
 Example of a Non HA cluster inventory with 2 nodes:
 
diff --git a/k3s-cluster/content/wiki/guide/configuration/roles/argocd.md b/k3s-cluster/content/wiki/guide/configuration/roles/argocd.md
index 0a15eea..b2bc03a 100644
--- a/k3s-cluster/content/wiki/guide/configuration/roles/argocd.md
+++ b/k3s-cluster/content/wiki/guide/configuration/roles/argocd.md
@@ -9,7 +9,7 @@ next: /wiki/guide/configuration/roles/certmanager
 The `argo-cd` role performs various tasks related to Helm chart deployment, reset and validation.
 
 > [!TIP]
-> Role deployments are performed at `global` level, using the [Provisioning](/k3s-cluster/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
+> Role deployments are performed at `global` level, using the [Provisioning](/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
 
 <!--more-->
 
@@ -36,7 +36,7 @@ Post-install related tasks, see [`postinstall.yaml`](https://{{< param variables
 Reset related tasks, see [`reset.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/argo-cd/tasks/reset.yaml) for details.
 
 > [!TIP]
-> A reset is performed at global level only, review the [Reset](/k3s-cluster/wiki/guide/playbooks/reset) playbook instructions.
+> A reset is performed at global level only, review the [Reset](/wiki/guide/playbooks/reset) playbook instructions.
 
 ### Upgrade
 
@@ -114,12 +114,12 @@ Kubernetes `HTTPRoute` resource template, see [`http_route_secure.j2`](https://{
 ## Role Variables
 
 > [!IMPORTANT]
-> A [role upgrade](/k3s-cluster/wiki/guide/configuration/roles/argocd/#upgrade) is required, in order to apply any changes related to role variables.
+> A [role upgrade](/wiki/guide/configuration/roles/argocd/#upgrade) is required, in order to apply any changes related to role variables.
 
-See the related role variables, defined into [`main.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/argo-cd/defaults/main.yaml) defaults file. Review the [`README.md`](https://{{< param variables.repository.cluster >}}/tree/main/roles/argo-cd) file, for additional details and refer to ArgoCD [tutorial](/k3s-cluster/tutorials/handbook/argocd), for advanced configuration settings.
+See the related role variables, defined into [`main.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/argo-cd/defaults/main.yaml) defaults file. Review the [`README.md`](https://{{< param variables.repository.cluster >}}/tree/main/roles/argo-cd) file, for additional details and refer to ArgoCD [tutorial](/tutorials/handbook/argocd), for advanced configuration settings.
 
 > [!TIP]
-> Use [Renovate](/k3s-cluster/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
+> Use [Renovate](/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
 
 ## Support
 
diff --git a/k3s-cluster/content/wiki/guide/configuration/roles/certmanager.md b/k3s-cluster/content/wiki/guide/configuration/roles/certmanager.md
index 5c030ed..3849a8a 100644
--- a/k3s-cluster/content/wiki/guide/configuration/roles/certmanager.md
+++ b/k3s-cluster/content/wiki/guide/configuration/roles/certmanager.md
@@ -9,7 +9,7 @@ next: /wiki/guide/configuration/roles/cilium
 The `cert-manager` role performs various tasks related to Helm chart deployment, reset and validation.
 
 > [!TIP]
-> Role deployments are performed at `global` level, using the [Provisioning](/k3s-cluster/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
+> Role deployments are performed at `global` level, using the [Provisioning](/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
 
 <!--more-->
 
@@ -36,7 +36,7 @@ Post-install related tasks, see [`postinstall.yaml`](https://{{< param variables
 Reset related tasks, see [`reset.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/cert-manager/tasks/reset.yaml) for details.
 
 > [!TIP]
-> A reset is performed at global level only, review the [Reset](/k3s-cluster/wiki/guide/playbooks/reset) playbook instructions.
+> A reset is performed at global level only, review the [Reset](/wiki/guide/playbooks/reset) playbook instructions.
 
 ### Upgrade
 
@@ -88,12 +88,12 @@ Helm chart values template used for controller configuration, see [`config_contr
 ## Role Variables
 
 > [!IMPORTANT]
-> A [role upgrade](/k3s-cluster/wiki/guide/configuration/roles/certmanager/#upgrade) is required, in order to apply any changes related to role variables.
+> A [role upgrade](/wiki/guide/configuration/roles/certmanager/#upgrade) is required, in order to apply any changes related to role variables.
 
 See the related role variables, defined into [`main.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/cert-manager/defaults/main.yaml) defaults file. Review the [`README.md`](https://{{< param variables.repository.cluster >}}/tree/main/roles/cert-manager) file, for additional details.
 
 > [!TIP]
-> Use [Renovate](/k3s-cluster/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
+> Use [Renovate](/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
 
 ## Support
 
diff --git a/k3s-cluster/content/wiki/guide/configuration/roles/cilium.md b/k3s-cluster/content/wiki/guide/configuration/roles/cilium.md
index 40068db..2a92c67 100644
--- a/k3s-cluster/content/wiki/guide/configuration/roles/cilium.md
+++ b/k3s-cluster/content/wiki/guide/configuration/roles/cilium.md
@@ -9,7 +9,7 @@ next: /wiki/guide/configuration/roles/coredns
 The `cilium` role performs various tasks related to Helm chart deployment, reset and validation.
 
 > [!TIP]
-> Role deployments are performed at `global` level, using the [Provisioning](/k3s-cluster/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
+> Role deployments are performed at `global` level, using the [Provisioning](/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
 
 <!--more-->
 
@@ -36,7 +36,7 @@ Post-install related tasks, see [`postinstall.yaml`](https://{{< param variables
 Reset related tasks, see [`reset.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/cilium/tasks/reset.yaml) for details.
 
 > [!TIP]
-> A reset is performed at global level only, review the [Reset](/k3s-cluster/wiki/guide/playbooks/reset) playbook instructions.
+> A reset is performed at global level only, review the [Reset](/wiki/guide/playbooks/reset) playbook instructions.
 
 ### Upgrade
 
@@ -108,12 +108,12 @@ Kubernetes `CiliumLoadBalancerIPPool` resource template, see [`loadbalancer_ip_p
 ## Role Variables
 
 > [!IMPORTANT]
-> A [role upgrade](/k3s-cluster/wiki/guide/configuration/roles/cilium/#upgrade) is required, in order to apply any changes related to role variables.
+> A [role upgrade](/wiki/guide/configuration/roles/cilium/#upgrade) is required, in order to apply any changes related to role variables.
 
 See the related role variables, defined into [`main.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/cilium/defaults/main.yaml) defaults file. Review the [`README.md`](https://{{< param variables.repository.cluster >}}/tree/main/roles/cilium) file, for additional details.
 
 > [!TIP]
-> Use [Renovate](/k3s-cluster/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
+> Use [Renovate](/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
 
 ## Support
 
diff --git a/k3s-cluster/content/wiki/guide/configuration/roles/cluster.md b/k3s-cluster/content/wiki/guide/configuration/roles/cluster.md
index 88f14f7..ce30db2 100644
--- a/k3s-cluster/content/wiki/guide/configuration/roles/cluster.md
+++ b/k3s-cluster/content/wiki/guide/configuration/roles/cluster.md
@@ -10,7 +10,7 @@ weight: 1
 The `cluster` role performs various tasks related to OS configuration, reset and validation.
 
 > [!TIP]
-> Role deployments are performed at `global` level, using the [Provisioning](/k3s-cluster/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
+> Role deployments are performed at `global` level, using the [Provisioning](/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
 
 <!--more-->
 
@@ -41,7 +41,7 @@ Main role related tasks, see [`main.yaml`](https://{{< param variables.repositor
 Reset related tasks, see [`reset.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/cluster/tasks/reset.yaml) for details.
 
 > [!TIP]
-> A reset is performed at global level only, review the [Reset](/k3s-cluster/wiki/guide/playbooks/reset) playbook instructions.
+> A reset is performed at global level only, review the [Reset](/wiki/guide/playbooks/reset) playbook instructions.
 
 ### Upgrade
 
@@ -68,12 +68,12 @@ ansible-playbook --ask-vault-pass --tags=cluster validation.yaml
 ## Role Variables
 
 > [!IMPORTANT]
-> A [role upgrade](/k3s-cluster/wiki/guide/configuration/roles/cluster/#upgrade) is required, in order to apply any changes related to role variables.
+> A [role upgrade](/wiki/guide/configuration/roles/cluster/#upgrade) is required, in order to apply any changes related to role variables.
 
 See the related role variables, defined into [`main.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/cluster/defaults/main.yaml) defaults file. Review the [`README.md`](https://{{< param variables.repository.cluster >}}/tree/main/roles/cluster) file and perform any optional adjustments.
 
 > [!TIP]
-> Use [Renovate](/k3s-cluster/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
+> Use [Renovate](/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
 
 ## Support
 
diff --git a/k3s-cluster/content/wiki/guide/configuration/roles/coredns.md b/k3s-cluster/content/wiki/guide/configuration/roles/coredns.md
index c6077ff..8f01793 100644
--- a/k3s-cluster/content/wiki/guide/configuration/roles/coredns.md
+++ b/k3s-cluster/content/wiki/guide/configuration/roles/coredns.md
@@ -9,7 +9,7 @@ next: /wiki/guide/configuration/roles/externaldns
 The `coredns` role performs various tasks related to Helm chart deployment, reset and validation.
 
 > [!TIP]
-> Role deployments are performed at `global` level, using the [Provisioning](/k3s-cluster/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
+> Role deployments are performed at `global` level, using the [Provisioning](/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
 
 <!--more-->
 
@@ -36,7 +36,7 @@ Post-install related tasks, see [`postinstall.yaml`](https://{{< param variables
 Reset related tasks, see [`reset.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/coredns/tasks/reset.yaml) for details.
 
 > [!TIP]
-> A reset is performed at global level only, review the [Reset](/k3s-cluster/wiki/guide/playbooks/reset) playbook instructions.
+> A reset is performed at global level only, review the [Reset](/wiki/guide/playbooks/reset) playbook instructions.
 
 ### Upgrade
 
@@ -78,12 +78,12 @@ Zones configuration template, see [`config_servers.j2`](https://{{< param variab
 ## Role Variables
 
 > [!IMPORTANT]
-> A [role upgrade](/k3s-cluster/wiki/guide/configuration/roles/coredns/#upgrade) is required, in order to apply any changes related to role variables.
+> A [role upgrade](/wiki/guide/configuration/roles/coredns/#upgrade) is required, in order to apply any changes related to role variables.
 
 See the related role variables, defined into [`main.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/coredns/defaults/main.yaml) defaults file. Review the [`README.md`](https://{{< param variables.repository.cluster >}}/tree/main/roles/coredns) file, for additional details.
 
 > [!TIP]
-> Use [Renovate](/k3s-cluster/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
+> Use [Renovate](/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
 
 ## Support
 
diff --git a/k3s-cluster/content/wiki/guide/configuration/roles/externaldns.md b/k3s-cluster/content/wiki/guide/configuration/roles/externaldns.md
index 03426fc..6a28d19 100644
--- a/k3s-cluster/content/wiki/guide/configuration/roles/externaldns.md
+++ b/k3s-cluster/content/wiki/guide/configuration/roles/externaldns.md
@@ -9,7 +9,7 @@ next: /wiki/guide/configuration/roles/kured
 The `external-dns` role performs various tasks related to [Cloudflare](https://www.cloudflare.com) DNS configuration, as well the `external-dns` Helm chart deployment, reset and validation.
 
 > [!TIP]
-> Role deployments are performed at `global` level, using the [Provisioning](/k3s-cluster/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
+> Role deployments are performed at `global` level, using the [Provisioning](/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
 
 <!--more-->
 
@@ -36,7 +36,7 @@ Post-install related tasks, see [`postinstall.yaml`](https://{{< param variables
 Reset related tasks, see [`reset.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/external-dns/tasks/reset.yaml) for details.
 
 > [!TIP]
-> A reset is performed at global level only, review the [Reset](/k3s-cluster/wiki/guide/playbooks/reset) playbook instructions.
+> A reset is performed at global level only, review the [Reset](/wiki/guide/playbooks/reset) playbook instructions.
 
 ### Upgrade
 
@@ -79,12 +79,12 @@ Kubernetes `ClusterIssuer` resource template, see [`cluster_issuer.j2`](https://
 ## Role Variables
 
 > [!IMPORTANT]
-> A [role upgrade](/k3s-cluster/wiki/guide/configuration/roles/externaldns/#upgrade) is required, in order to apply any changes related to role variables.
+> A [role upgrade](/wiki/guide/configuration/roles/externaldns/#upgrade) is required, in order to apply any changes related to role variables.
 
 See the related role variables, defined into [`main.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/external-dns/defaults/main.yaml) defaults file. Review the [`README.md`](https://{{< param variables.repository.cluster >}}/tree/main/roles/external-dns) file, for additional details.
 
 > [!TIP]
-> Use [Renovate](/k3s-cluster/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
+> Use [Renovate](/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
 
 ## Support
 
diff --git a/k3s-cluster/content/wiki/guide/configuration/roles/helm.md b/k3s-cluster/content/wiki/guide/configuration/roles/helm.md
index 75a501f..2a33f3a 100644
--- a/k3s-cluster/content/wiki/guide/configuration/roles/helm.md
+++ b/k3s-cluster/content/wiki/guide/configuration/roles/helm.md
@@ -10,7 +10,7 @@ weight: 2
 The `helm` role performs various tasks related to OS configuration, reset and validation. It installs the [Balto](https://helm.baltorepo.com/stable/debian/packages/helm) stable Debian based repository needed for `helm` package, as well the related [`diff`](https://github.com/databus23/helm-diff/releases) Helm plugin.
 
 > [!TIP]
-> Role deployments are performed at `global` level, using the [Provisioning](/k3s-cluster/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
+> Role deployments are performed at `global` level, using the [Provisioning](/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
 
 <!--more-->
 
@@ -22,7 +22,6 @@ See the related role tasks, listed below.
 
 ### Facts
 
-
 Ansible facts, see [`facts.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/helm/tasks/facts.yaml) for details.
 
 ### Main
@@ -38,7 +37,7 @@ Plugins related tasks, see [`plugins.yaml`](https://{{< param variables.reposito
 Reset related tasks, see [`reset.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/helm/tasks/reset.yaml) for details.
 
 > [!TIP]
-> A reset is performed at global level only, review the [Reset](/k3s-cluster/wiki/guide/playbooks/reset) playbook instructions.
+> A reset is performed at global level only, review the [Reset](/wiki/guide/playbooks/reset) playbook instructions.
 
 ### Upgrade
 
@@ -77,12 +76,12 @@ Service timer template, see [`timer.j2`](https://{{< param variables.repository.
 ## Role Variables
 
 > [!IMPORTANT]
-> A [role upgrade](/k3s-cluster/wiki/guide/configuration/roles/helm/#upgrade) is required, in order to apply any changes related to role variables.
+> A [role upgrade](/wiki/guide/configuration/roles/helm/#upgrade) is required, in order to apply any changes related to role variables.
 
 See the related role variables, defined into [`main.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/helm/defaults/main.yaml) defaults file. Review the [`README.md`](https://{{< param variables.repository.cluster >}}/tree/main/roles/helm) file, for additional details.
 
 > [!TIP]
-> Use [Renovate](/k3s-cluster/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
+> Use [Renovate](/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
 
 ## Support
 
diff --git a/k3s-cluster/content/wiki/guide/configuration/roles/k3s.md b/k3s-cluster/content/wiki/guide/configuration/roles/k3s.md
index 9d045b3..9bfb191 100644
--- a/k3s-cluster/content/wiki/guide/configuration/roles/k3s.md
+++ b/k3s-cluster/content/wiki/guide/configuration/roles/k3s.md
@@ -10,7 +10,7 @@ weight: 2
 The `k3s` role performs various tasks related to OS configuration, K3s cluster deployment, reset and validation.
 
 > [!TIP]
-> Role deployments are performed at `global` level, using the [Provisioning](/k3s-cluster/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
+> Role deployments are performed at `global` level, using the [Provisioning](/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
 
 <!--more-->
 
@@ -41,7 +41,7 @@ Main role related tasks, see [`main.yaml`](https://{{< param variables.repositor
 Reset related tasks, see [`reset.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/k3s/tasks/reset.yaml) for details.
 
 > [!TIP]
-> A reset is performed at global level only, review the [Reset](/k3s-cluster/wiki/guide/playbooks/reset) playbook instructions.
+> A reset is performed at global level only, review the [Reset](/wiki/guide/playbooks/reset) playbook instructions.
 
 ### Upgrade
 
@@ -51,7 +51,7 @@ Upgrade related tasks, see [`upgrade.yaml`](https://{{< param variables.reposito
 ansible-playbook --ask-vault-pass --tags=k3s upgrade.yaml
 ```
 
-The upgrade will trigger the [Kured](/k3s-cluster/wiki/guide/configuration/roles/kured) role execution, performing safe automatic node reboots.
+The upgrade will trigger the [Kured](/wiki/guide/configuration/roles/kured) role execution, performing safe automatic node reboots.
 
 ### Validation
 
@@ -100,12 +100,12 @@ Service configuration template, see [`service.j2`](https://{{< param variables.r
 ## Role Variables
 
 > [!IMPORTANT]
-> A [role upgrade](/k3s-cluster/wiki/guide/configuration/roles/k3s/#upgrade) is required, in order to apply any changes related to role variables.
+> A [role upgrade](/wiki/guide/configuration/roles/k3s/#upgrade) is required, in order to apply any changes related to role variables.
 
 See the related role variables, defined into [`main.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/k3s/defaults/main.yaml) defaults file. Review the [`README.md`](https://{{< param variables.repository.cluster >}}/tree/main/roles/k3s) file, for additional details.
 
 > [!TIP]
-> Use [Renovate](/k3s-cluster/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
+> Use [Renovate](/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
 
 ## Support
 
diff --git a/k3s-cluster/content/wiki/guide/configuration/roles/kured.md b/k3s-cluster/content/wiki/guide/configuration/roles/kured.md
index a09fca2..c9f76c1 100644
--- a/k3s-cluster/content/wiki/guide/configuration/roles/kured.md
+++ b/k3s-cluster/content/wiki/guide/configuration/roles/kured.md
@@ -9,7 +9,7 @@ next: /wiki/guide/configuration/roles/longhorn
 The `kured` role performs various tasks related to Helm chart deployment, reset and validation.
 
 > [!TIP]
-> Role deployments are performed at `global` level, using the [Provisioning](/k3s-cluster/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
+> Role deployments are performed at `global` level, using the [Provisioning](/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
 
 <!--more-->
 
@@ -36,7 +36,7 @@ Post-install related tasks, see [`postinstall.yaml`](https://{{< param variables
 Reset related tasks, see [`reset.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/kured/tasks/reset.yaml) for details.
 
 > [!TIP]
-> A reset is performed at global level only, review the [Reset](/k3s-cluster/wiki/guide/playbooks/reset) playbook instructions.
+> A reset is performed at global level only, review the [Reset](/wiki/guide/playbooks/reset) playbook instructions.
 
 ### Upgrade
 
@@ -74,12 +74,12 @@ Helm chart values template, see [`values.j2`](https://{{< param variables.reposi
 ## Role Variables
 
 > [!IMPORTANT]
-> A [role upgrade](/k3s-cluster/wiki/guide/configuration/roles/kured/#upgrade) is required, in order to apply any changes related to role variables.
+> A [role upgrade](/wiki/guide/configuration/roles/kured/#upgrade) is required, in order to apply any changes related to role variables.
 
 See the related role variables, defined into [`main.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/kured/defaults/main.yaml) defaults file. Review the [`README.md`](https://{{< param variables.repository.cluster >}}/tree/main/roles/kured) file, for additional details.
 
 > [!TIP]
-> Use [Renovate](/k3s-cluster/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
+> Use [Renovate](/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
 
 ## Support
 
diff --git a/k3s-cluster/content/wiki/guide/configuration/roles/longhorn.md b/k3s-cluster/content/wiki/guide/configuration/roles/longhorn.md
index 1f8972c..f0959ee 100644
--- a/k3s-cluster/content/wiki/guide/configuration/roles/longhorn.md
+++ b/k3s-cluster/content/wiki/guide/configuration/roles/longhorn.md
@@ -9,7 +9,7 @@ next: /wiki/guide/configuration/roles/metricsserver
 The `longhorn` role performs various tasks related to Helm chart deployment, reset and validation.
 
 > [!TIP]
-> Role deployments are performed at `global` level, using the [Provisioning](/k3s-cluster/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
+> Role deployments are performed at `global` level, using the [Provisioning](/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
 
 <!--more-->
 
@@ -36,7 +36,7 @@ Post-install related tasks, see [`postinstall.yaml`](https://{{< param variables
 Reset related tasks, see [`reset.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/longhorn/tasks/reset.yaml) for details.
 
 > [!TIP]
-> A reset is performed at global level only, review the [Reset](/k3s-cluster/wiki/guide/playbooks/reset) playbook instructions.
+> A reset is performed at global level only, review the [Reset](/wiki/guide/playbooks/reset) playbook instructions.
 
 ### Upgrade
 
@@ -93,12 +93,12 @@ Kubernetes `HTTPRoute` resource template, see [`http_route_secure.j2`](https://{
 ## Role Variables
 
 > [!IMPORTANT]
-> A [role upgrade](/k3s-cluster/wiki/guide/configuration/roles/longhorn/#upgrade) is required, in order to apply any changes related to role variables.
+> A [role upgrade](/wiki/guide/configuration/roles/longhorn/#upgrade) is required, in order to apply any changes related to role variables.
 
 See the related role variables, defined into [`main.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/longhorn/defaults/main.yaml) defaults file. Review the [`README.md`](https://{{< param variables.repository.cluster >}}/tree/main/roles/longhorn) file, for additional details.
 
 > [!TIP]
-> Use [Renovate](/k3s-cluster/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
+> Use [Renovate](/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
 
 ## Support
 
diff --git a/k3s-cluster/content/wiki/guide/configuration/roles/metricsserver.md b/k3s-cluster/content/wiki/guide/configuration/roles/metricsserver.md
index 160ed32..fae88de 100644
--- a/k3s-cluster/content/wiki/guide/configuration/roles/metricsserver.md
+++ b/k3s-cluster/content/wiki/guide/configuration/roles/metricsserver.md
@@ -9,7 +9,7 @@ next: /wiki/guide/configuration/roles/victorialogs
 The `metrics-server` role performs various tasks related to Helm chart deployment, reset and validation.
 
 > [!TIP]
-> Role deployments are performed at `global` level, using the [Provisioning](/k3s-cluster/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
+> Role deployments are performed at `global` level, using the [Provisioning](/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
 
 <!--more-->
 
@@ -67,12 +67,12 @@ Helm chart values template, see [`values.j2`](https://{{< param variables.reposi
 ## Role Variables
 
 > [!IMPORTANT]
-> A [role upgrade](/k3s-cluster/wiki/guide/configuration/roles/metricsserver/#upgrade) is required, in order to apply any changes related to role variables.
+> A [role upgrade](/wiki/guide/configuration/roles/metricsserver/#upgrade) is required, in order to apply any changes related to role variables.
 
 See the related role variables, defined into [`main.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/metrics-server/defaults/main.yaml) defaults file. Review the [`README.md`](https://{{< param variables.repository.cluster >}}/tree/main/roles/metrics-server) file, for additional details.
 
 > [!TIP]
-> Use [Renovate](/k3s-cluster/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
+> Use [Renovate](/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
 
 ## Support
 
diff --git a/k3s-cluster/content/wiki/guide/configuration/roles/victorialogs.md b/k3s-cluster/content/wiki/guide/configuration/roles/victorialogs.md
index f9d55c2..5a15e20 100644
--- a/k3s-cluster/content/wiki/guide/configuration/roles/victorialogs.md
+++ b/k3s-cluster/content/wiki/guide/configuration/roles/victorialogs.md
@@ -9,7 +9,7 @@ next: /wiki/guide/configuration/roles/victoriametrics
 The `victoria-logs` role performs various tasks related to Helm chart deployment, reset and validation.
 
 > [!TIP]
-> Role deployments are performed at `global` level, using the [Provisioning](/k3s-cluster/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
+> Role deployments are performed at `global` level, using the [Provisioning](/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
 
 <!--more-->
 
@@ -67,12 +67,12 @@ Helm chart values template, see [`values.j2`](https://{{< param variables.reposi
 ## Role Variables
 
 > [!IMPORTANT]
-> A [role upgrade](/k3s-cluster/wiki/guide/configuration/roles/victorialogs/#upgrade) is required, in order to apply any changes related to role variables.
+> A [role upgrade](/wiki/guide/configuration/roles/victorialogs/#upgrade) is required, in order to apply any changes related to role variables.
 
 See the related role variables, defined into [`main.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/victoria-logs/defaults/main.yaml) defaults file. Review the [`README.md`](https://{{< param variables.repository.cluster >}}/tree/main/roles/victoria-logs) file, for additional details.
 
 > [!TIP]
-> Use [Renovate](/k3s-cluster/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
+> Use [Renovate](/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
 
 ## Support
 
diff --git a/k3s-cluster/content/wiki/guide/configuration/roles/victoriametrics.md b/k3s-cluster/content/wiki/guide/configuration/roles/victoriametrics.md
index 2768c2c..b1276e6 100644
--- a/k3s-cluster/content/wiki/guide/configuration/roles/victoriametrics.md
+++ b/k3s-cluster/content/wiki/guide/configuration/roles/victoriametrics.md
@@ -9,7 +9,7 @@ next: /wiki/guide/playbooks
 The `victoria-metrics` role performs various tasks related to Helm chart deployment, reset and validation.
 
 > [!TIP]
-> Role deployments are performed at `global` level, using the [Provisioning](/k3s-cluster/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
+> Role deployments are performed at `global` level, using the [Provisioning](/wiki/guide/playbooks/provisioning) playbook. Upgrades can be performed at `role` level, see the instructions detailed below.
 
 <!--more-->
 
@@ -81,12 +81,12 @@ Kubernetes `Secret` resource template containing the user credentials, see [`cre
 ## Role Variables
 
 > [!IMPORTANT]
-> A [role upgrade](/k3s-cluster/wiki/guide/configuration/roles/victoriametrics/#upgrade) is required, in order to apply any changes related to role variables.
+> A [role upgrade](/wiki/guide/configuration/roles/victoriametrics/#upgrade) is required, in order to apply any changes related to role variables.
 
 See the related role variables, defined into [`main.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/victoria-metrics/defaults/main.yaml) defaults file. Review the [`README.md`](https://{{< param variables.repository.cluster >}}/tree/main/roles/victoria-metrics) file, for additional details.
 
 > [!TIP]
-> Use [Renovate](/k3s-cluster/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
+> Use [Renovate](/tutorials/handbook/tools/#renovate) to automate release pull requests and keep dependencies up-to-date.
 
 ## Support
 
diff --git a/k3s-cluster/content/wiki/guide/configuration/user.md b/k3s-cluster/content/wiki/guide/configuration/user.md
index 020509f..3d7174e 100644
--- a/k3s-cluster/content/wiki/guide/configuration/user.md
+++ b/k3s-cluster/content/wiki/guide/configuration/user.md
@@ -16,22 +16,22 @@ The Ansible user is used to remotely execute various deployment tasks into clust
 Set the [`ansible_user`](https://docs.ansible.com/ansible/latest/reference_appendices/special_variables.html) variable into [`all.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/inventory/cluster/group_vars/all.yaml) global configuration file.
 
 > [!IMPORTANT]
-> Use the `username` value defined into [OS General Settings](/k3s-cluster/tutorials/handbook/server/#os-general-settings) server installation, to set the `ansible_user` variable.
+> Use the `username` value defined into [OS General Settings](/tutorials/handbook/server/#os-general-settings) server installation, to set the `ansible_user` variable.
 
 ### User Password
 
-Encrypt the `ansible_password` variable with [`ansible-vault`](/k3s-cluster/tutorials/handbook/ansible/#vault) and set the encrypted value into [`all.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/inventory/cluster/group_vars/all.yaml) global configuration file.
+Encrypt the `ansible_password` variable with [`ansible-vault`](/tutorials/handbook/ansible/#vault) and set the encrypted value into [`all.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/inventory/cluster/group_vars/all.yaml) global configuration file.
 
 ### SSH Key
 
-Generate the [SSH key](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent), which will be copied into each cluster node, while running the [Provisioning](/k3s-cluster/wiki/guide/playbooks/provisioning) playbook:
+Generate the [SSH key](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent), which will be copied into each cluster node, while running the [Provisioning](/wiki/guide/playbooks/provisioning) playbook:
 
 ```shell
 ssh-keygen -t ed25519 -C 'your_email@example.com'
 ```
 
 > [!IMPORTANT]
-> The [Provisioning](/k3s-cluster/wiki/guide/playbooks/provisioning) playbook will look for the generated SSH key, into default `/Users/username/.ssh` location.
+> The [Provisioning](/wiki/guide/playbooks/provisioning) playbook will look for the generated SSH key, into default `/Users/username/.ssh` location.
 
 For a different storage location, update the `cluster_vars.ssh.path` value into Cluster role [`main.yaml`](https://{{< param variables.repository.cluster >}}/blob/main/roles/cluster/defaults/main.yaml) configuration file.
 
diff --git a/k3s-cluster/content/wiki/guide/playbooks/provisioning.md b/k3s-cluster/content/wiki/guide/playbooks/provisioning.md
index 6547c38..b0fa867 100644
--- a/k3s-cluster/content/wiki/guide/playbooks/provisioning.md
+++ b/k3s-cluster/content/wiki/guide/playbooks/provisioning.md
@@ -3,12 +3,12 @@ title: Provisioning
 prev: /wiki/guide/playbooks
 ---
 
-The playbook allows the end-user to perform an initial cluster deployment, or a cluster re-deployment, after a performed [cluster reset](/k3s-cluster/wiki/guide/playbooks/reset).
+The playbook allows the end-user to perform an initial cluster deployment, or a cluster re-deployment, after a performed [cluster reset](/wiki/guide/playbooks/reset).
 
 <!--more-->
 
 > [!IMPORTANT]
-> Refer to the Ansible [tutorial](/k3s-cluster/tutorials/handbook/ansible), for usage of encrypted variables and files.
+> Refer to the Ansible [tutorial](/tutorials/handbook/ansible), for usage of encrypted variables and files.
 
 ## Execution
 
diff --git a/k3s-cluster/content/wiki/guide/playbooks/reset.md b/k3s-cluster/content/wiki/guide/playbooks/reset.md
index c83abc1..7d9fc73 100644
--- a/k3s-cluster/content/wiki/guide/playbooks/reset.md
+++ b/k3s-cluster/content/wiki/guide/playbooks/reset.md
@@ -8,7 +8,7 @@ The playbook allows the end-user to perform a cluster reset, bringing the nodes
 <!--more-->
 
 > [!IMPORTANT]
-> Refer to the Ansible [tutorial](/k3s-cluster/tutorials/handbook/ansible), for usage of encrypted variables and files.
+> Refer to the Ansible [tutorial](/tutorials/handbook/ansible), for usage of encrypted variables and files.
 
 ## Execution
 
diff --git a/k3s-cluster/content/wiki/guide/playbooks/upgrade.md b/k3s-cluster/content/wiki/guide/playbooks/upgrade.md
index b0be9d7..1775298 100644
--- a/k3s-cluster/content/wiki/guide/playbooks/upgrade.md
+++ b/k3s-cluster/content/wiki/guide/playbooks/upgrade.md
@@ -8,7 +8,7 @@ The playbook allows the end-user to perform a cluster component upgrade, for exa
 <!--more-->
 
 > [!IMPORTANT]
-> Refer to the Ansible [tutorial](/k3s-cluster/tutorials/handbook/ansible), for usage of encrypted variables and files.
+> Refer to the Ansible [tutorial](/tutorials/handbook/ansible), for usage of encrypted variables and files.
 
 ## Execution
 
@@ -26,7 +26,7 @@ Vault password: my-Gl0bal-Passw0rd
 
 ## Renovate
 
-Follow the steps detailed below, prior merging a [Renovate](/k3s-cluster/tutorials/handbook/tools/#renovate) dependency branch.
+Follow the steps detailed below, prior merging a [Renovate](/tutorials/handbook/tools/#renovate) dependency branch.
 
 {{% steps %}}
 
diff --git a/k3s-cluster/content/wiki/guide/playbooks/validation.md b/k3s-cluster/content/wiki/guide/playbooks/validation.md
index 1d719a4..f136abf 100644
--- a/k3s-cluster/content/wiki/guide/playbooks/validation.md
+++ b/k3s-cluster/content/wiki/guide/playbooks/validation.md
@@ -8,7 +8,7 @@ The playbook allows the end-user to perform an initial cluster components valida
 <!--more-->
 
 > [!IMPORTANT]
-> Refer to the Ansible [tutorial](/k3s-cluster/tutorials/handbook/ansible), for usage of encrypted variables and files.
+> Refer to the Ansible [tutorial](/tutorials/handbook/ansible), for usage of encrypted variables and files.
 
 ## Execution
 
diff --git a/k3s-cluster/content/wiki/guide/playbooks/vault.md b/k3s-cluster/content/wiki/guide/playbooks/vault.md
index 626db3e..f27c2e5 100644
--- a/k3s-cluster/content/wiki/guide/playbooks/vault.md
+++ b/k3s-cluster/content/wiki/guide/playbooks/vault.md
@@ -8,7 +8,7 @@ The playbook allows the end-user to perform various Ansible Vault related tasks,
 <!--more-->
 
 > [!IMPORTANT]
-> Refer to the Ansible [tutorial](/k3s-cluster/tutorials/handbook/ansible), for usage of encrypted variables and files.
+> Refer to the Ansible [tutorial](/tutorials/handbook/ansible), for usage of encrypted variables and files.
 
 ## Execution