From 2e750d69f01e954f5106b18b31d9691fd4d59764 Mon Sep 17 00:00:00 2001
From: Aleksei Sviridkin <f@lex.la>
Date: Mon, 7 Sep 2026 02:14:04 +0300
Subject: [PATCH 1/4] fix(operations): replace the component removal recipe
 that undoes itself

Removing an installed component was documented as `kubectl delete hr
-n <namespace> <component>`. The Package that emitted the release
owns it through a controller ownerReference, and the operator
watches HelmReleases with Owns(), so the delete fires the reconcile
that recreates it. The command reports success, nothing logs an
error, and the component is running again afterwards.

That is not the harmless no-op it looks like. The operator sets no
uninstall policy and no suspend on the HelmReleases it builds, so
Flux's default applies and the release is uninstalled when the
object goes away. Anything the uninstall destroys is gone before the
reinstall brings the workloads back, and the restored release hides
that it happened. The page now says so, for the benefit of anyone
who already ran the old recipe.

Deleting the cluster-scoped Package is what cascades into the
uninstall deliberately. It needs the disabledPackages entry to land
first, or the next platform upgrade renders the Package again and
the removal undoes itself one level up. The reader confirms that by
reading the disabledPackages list back off the platform HelmRelease,
which is the only observation here that cannot go green early. A
condition wait returns instantly against the Ready left standing by
the previous reconcile; re-reading the Package after deleting it
returns NotFound unconditionally; and comparing observedGeneration
against generation on that HelmRelease is equal in exactly the
window that matters, because the operator has not yet copied the
edit across from the Package the reader changed.

What the uninstall takes is stated above the command rather than
after it, in a warning callout. Anything the chart rendered as an
ordinary template and did not annotate resource-policy: keep goes
with the release, CRDs and namespaces alike, and the apiserver
cascades every custom resource of those CRD kinds. Removing
cozystack.metallb takes the MetalLB CRDs and the objects of those
kinds cluster-wide; removing cozystack.cozystack-basics takes the
cozy-public namespace, which that chart renders as a plain template
and which is not its install namespace. The one exception is the
namespace a component installs into: the operator applies that
itself, outside the release, so the uninstall never had it.

The v1.1 and v1.2 pages qualify the step count in place, next to the
instruction it governs, because the behaviour changed inside those
lines rather than between them. The keep annotation on Packages
arrived in v1.1.5 and v1.2.1 as backports, so v1.1.0 through v1.1.4
and v1.2.0 have no annotation and adding the name to
disabledPackages removes the component by itself, putting the
destruction on that step instead of the delete. The clauses name
their range rather than saying "and earlier", which would be false
across lines: v1.1.5 through v1.1.7 are lower-versioned than v1.2.0
and do carry the annotation.

Applied to next and v1.1 through v1.6. Left out v1.0, whose line
never received the annotation at all, so that page needs the
single-step correction rather than this one. v0 predates Package
objects: its platform chart renders HelmReleases directly, so
deleting the HelmRelease there names the object the chart creates,
though that page carries no destruction warning either.

The v1.1 disabledPackages examples listed bare names, which match
nothing against the fully-qualified names the platform chart feeds
the helper. Both copies are fixed: the one in the components page,
and the one in the Hetzner install guide that page links to as its
worked example. Leaving the second would have had v1.1 teach the
qualified form on one page and hand out the broken form on the page
it cites, on the one provider where swapping MetalLB for RobotLB is
mandatory.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>
---
 .../operations/configuration/components.md    | 21 ++++++++++++--
 .../en/docs/v1.1/install/providers/hetzner.md |  4 +--
 .../operations/configuration/components.md    | 28 +++++++++++++++----
 .../operations/configuration/components.md    | 23 +++++++++++++--
 .../operations/configuration/components.md    | 21 ++++++++++++--
 .../operations/configuration/components.md    | 21 ++++++++++++--
 .../operations/configuration/components.md    | 21 ++++++++++++--
 .../operations/configuration/components.md    | 21 ++++++++++++--
 8 files changed, 140 insertions(+), 20 deletions(-)

diff --git a/content/en/docs/next/operations/configuration/components.md b/content/en/docs/next/operations/configuration/components.md
index 53c04ea7..75882fbf 100644
--- a/content/en/docs/next/operations/configuration/components.md
+++ b/content/en/docs/next/operations/configuration/components.md
@@ -70,8 +70,25 @@ spec:
 
 Disabling components must be done before installing Cozystack.
 Applying updated configuration with `disabledPackages` will not remove components that are already installed.
-To remove already installed components, delete the Helm release manually using this command:
+Removing one that is already installed takes two steps. Add its name to `disabledPackages` in the Platform Package above, then wait for the operator to carry that edit across. The name appears in this output once it has:
 
 ```bash
-kubectl delete hr -n <namespace> <component>
+kubectl get helmrelease cozystack-platform --namespace cozy-system \
+  --output jsonpath='{.spec.values.bundles.disabledPackages}'
 ```
+
+Then delete the Package object. `kubectl get packages` lists the names.
+
+{{% alert title="Warning" color="warning" %}}
+Deleting the Package uninstalls the component's Helm release, and that destroys more than the workloads. Anything the chart rendered as an ordinary template without `helm.sh/resource-policy: keep` goes with the release, CRDs and namespaces included, and Kubernetes deletes every custom resource of those CRD kinds along with them. Removing `cozystack.metallb` takes the MetalLB CRDs and with them every IPAddressPool, L2Advertisement, BGPPeer and the rest of those kinds cluster-wide; removing `cozystack.cozystack-basics` takes the `cozy-public` namespace and everything stored in it. Back up anything you still need first.
+{{% /alert %}}
+
+The namespace a component installs into is the exception: the operator applies that one itself, outside the component's release and with no ownerReference, so the uninstall never had it to remove.
+
+```bash
+kubectl delete package.cozystack.io <package-name>
+```
+
+Deleting the Package while the platform values still render it means the next platform upgrade brings it back, undoing the removal one level up. Nothing reports this at the time: the delete succeeds either way and the Package reappears whenever that upgrade happens to run.
+
+`kubectl delete hr` is not a lighter-weight version of this. Flux uninstalls the release when the HelmRelease goes away, so it destroys the same CRDs and custom resources, and then the Package recreates the HelmRelease and the chart reinstalls. The workloads come back, the custom resources do not. If you have run it before, those custom resources are already gone and have to be recreated from your own manifests or a backup.
diff --git a/content/en/docs/v1.1/install/providers/hetzner.md b/content/en/docs/v1.1/install/providers/hetzner.md
index ded13a7b..17948983 100644
--- a/content/en/docs/v1.1/install/providers/hetzner.md
+++ b/content/en/docs/v1.1/install/providers/hetzner.md
@@ -344,9 +344,9 @@ The final stage of deploying a Cozystack cluster on Hetzner is to install Cozyst
           values:
             bundles:
               disabledPackages:
-                - metallb
+                - cozystack.metallb
               enabledPackages:
-                - hetzner-robotlb
+                - cozystack.hetzner-robotlb
             publishing:
               host: "example.org"
               apiServerEndpoint: "https://api.example.org:443"
diff --git a/content/en/docs/v1.1/operations/configuration/components.md b/content/en/docs/v1.1/operations/configuration/components.md
index 88bc17b7..37df376b 100644
--- a/content/en/docs/v1.1/operations/configuration/components.md
+++ b/content/en/docs/v1.1/operations/configuration/components.md
@@ -41,6 +41,7 @@ Bundles have optional components that need to be explicitly enabled (included) i
 Regular bundle components can, on the other hand, be disabled (excluded) from the installation, when you don't need them.
 
 Use `bundles.enabledPackages` and `bundles.disabledPackages` in the Platform Package values.
+Every entry in those lists is a fully-qualified Package name under the `cozystack.` prefix — run `kubectl get package` to see the exact names on your cluster.
 For example, [installing Cozystack in Hetzner]({{% ref "/docs/v1.1/install/providers/hetzner" %}})
 requires swapping default load balancer, MetalLB, with one made specifically for Hetzner, called RobotLB:
 
@@ -56,16 +57,33 @@ spec:
       values:
         bundles:
           disabledPackages:
-            - metallb
+            - cozystack.metallb
           enabledPackages:
-            - hetzner-robotlb
+            - cozystack.hetzner-robotlb
         # rest of the config
 ```
 
 Disabling components must be done before installing Cozystack.
-Applying updated configuration with `disabledPackages` will not remove components that are already installed.
-To remove already installed components, delete the Helm release manually using this command:
+From v1.1.5 onward, applying updated configuration with `disabledPackages` will not remove components that are already installed.
+Removing one that is already installed then takes two steps. On v1.1.0 through v1.1.4 the platform does not annotate the Package with `helm.sh/resource-policy: keep`. On those releases adding the name to `disabledPackages` does remove an installed component: the destruction described below happens at that point, and there is no second command to run, so back up anything you still need before making that edit. Add its name to `disabledPackages` in the Platform Package above, then wait for the operator to carry that edit across. The name appears in this output once it has:
 
 ```bash
-kubectl delete hr -n <namespace> <component>
+kubectl get helmrelease cozystack-platform --namespace cozy-system \
+  --output jsonpath='{.spec.values.bundles.disabledPackages}'
 ```
+
+Then delete the Package object. `kubectl get packages` lists the names.
+
+{{% alert title="Warning" color="warning" %}}
+Deleting the Package uninstalls the component's Helm release, and that destroys more than the workloads. Anything the chart rendered as an ordinary template without `helm.sh/resource-policy: keep` goes with the release, CRDs and namespaces included, and Kubernetes deletes every custom resource of those CRD kinds along with them. Removing `cozystack.metallb` takes the MetalLB CRDs and with them every IPAddressPool, L2Advertisement, BGPPeer and the rest of those kinds cluster-wide; removing `cozystack.cozystack-basics` takes the `cozy-public` namespace and everything stored in it. Back up anything you still need first.
+{{% /alert %}}
+
+The namespace a component installs into is the exception: the operator applies that one itself, outside the component's release and with no ownerReference, so the uninstall never had it to remove.
+
+```bash
+kubectl delete package.cozystack.io <package-name>
+```
+
+Deleting the Package while the platform values still render it means the next platform upgrade brings it back, undoing the removal one level up. Nothing reports this at the time: the delete succeeds either way and the Package reappears whenever that upgrade happens to run.
+
+`kubectl delete hr` is not a lighter-weight version of this. Flux uninstalls the release when the HelmRelease goes away, so it destroys the same CRDs and custom resources, and then the Package recreates the HelmRelease and the chart reinstalls. The workloads come back, the custom resources do not. If you have run it before, those custom resources are already gone and have to be recreated from your own manifests or a backup.
diff --git a/content/en/docs/v1.2/operations/configuration/components.md b/content/en/docs/v1.2/operations/configuration/components.md
index 3cdc9b9f..e358038f 100644
--- a/content/en/docs/v1.2/operations/configuration/components.md
+++ b/content/en/docs/v1.2/operations/configuration/components.md
@@ -69,9 +69,26 @@ spec:
 ```
 
 Disabling components must be done before installing Cozystack.
-Applying updated configuration with `disabledPackages` will not remove components that are already installed.
-To remove already installed components, delete the Helm release manually using this command:
+From v1.2.1 onward, applying updated configuration with `disabledPackages` will not remove components that are already installed.
+Removing one that is already installed then takes two steps. On v1.2.0 the platform does not annotate the Package with `helm.sh/resource-policy: keep`. There, adding the name to `disabledPackages` does remove an installed component: the destruction described below happens at that point, and there is no second command to run, so back up anything you still need before making that edit. Add its name to `disabledPackages` in the Platform Package above, then wait for the operator to carry that edit across. The name appears in this output once it has:
 
 ```bash
-kubectl delete hr -n <namespace> <component>
+kubectl get helmrelease cozystack-platform --namespace cozy-system \
+  --output jsonpath='{.spec.values.bundles.disabledPackages}'
 ```
+
+Then delete the Package object. `kubectl get packages` lists the names.
+
+{{% alert title="Warning" color="warning" %}}
+Deleting the Package uninstalls the component's Helm release, and that destroys more than the workloads. Anything the chart rendered as an ordinary template without `helm.sh/resource-policy: keep` goes with the release, CRDs and namespaces included, and Kubernetes deletes every custom resource of those CRD kinds along with them. Removing `cozystack.metallb` takes the MetalLB CRDs and with them every IPAddressPool, L2Advertisement, BGPPeer and the rest of those kinds cluster-wide; removing `cozystack.cozystack-basics` takes the `cozy-public` namespace and everything stored in it. Back up anything you still need first.
+{{% /alert %}}
+
+The namespace a component installs into is the exception: the operator applies that one itself, outside the component's release and with no ownerReference, so the uninstall never had it to remove.
+
+```bash
+kubectl delete package.cozystack.io <package-name>
+```
+
+Deleting the Package while the platform values still render it means the next platform upgrade brings it back, undoing the removal one level up. Nothing reports this at the time: the delete succeeds either way and the Package reappears whenever that upgrade happens to run.
+
+`kubectl delete hr` is not a lighter-weight version of this. Flux uninstalls the release when the HelmRelease goes away, so it destroys the same CRDs and custom resources, and then the Package recreates the HelmRelease and the chart reinstalls. The workloads come back, the custom resources do not. If you have run it before, those custom resources are already gone and have to be recreated from your own manifests or a backup.
diff --git a/content/en/docs/v1.3/operations/configuration/components.md b/content/en/docs/v1.3/operations/configuration/components.md
index c9fb3eb3..aa372ed6 100644
--- a/content/en/docs/v1.3/operations/configuration/components.md
+++ b/content/en/docs/v1.3/operations/configuration/components.md
@@ -70,8 +70,25 @@ spec:
 
 Disabling components must be done before installing Cozystack.
 Applying updated configuration with `disabledPackages` will not remove components that are already installed.
-To remove already installed components, delete the Helm release manually using this command:
+Removing one that is already installed takes two steps. Add its name to `disabledPackages` in the Platform Package above, then wait for the operator to carry that edit across. The name appears in this output once it has:
 
 ```bash
-kubectl delete hr -n <namespace> <component>
+kubectl get helmrelease cozystack-platform --namespace cozy-system \
+  --output jsonpath='{.spec.values.bundles.disabledPackages}'
 ```
+
+Then delete the Package object. `kubectl get packages` lists the names.
+
+{{% alert title="Warning" color="warning" %}}
+Deleting the Package uninstalls the component's Helm release, and that destroys more than the workloads. Anything the chart rendered as an ordinary template without `helm.sh/resource-policy: keep` goes with the release, CRDs and namespaces included, and Kubernetes deletes every custom resource of those CRD kinds along with them. Removing `cozystack.metallb` takes the MetalLB CRDs and with them every IPAddressPool, L2Advertisement, BGPPeer and the rest of those kinds cluster-wide; removing `cozystack.cozystack-basics` takes the `cozy-public` namespace and everything stored in it. Back up anything you still need first.
+{{% /alert %}}
+
+The namespace a component installs into is the exception: the operator applies that one itself, outside the component's release and with no ownerReference, so the uninstall never had it to remove.
+
+```bash
+kubectl delete package.cozystack.io <package-name>
+```
+
+Deleting the Package while the platform values still render it means the next platform upgrade brings it back, undoing the removal one level up. Nothing reports this at the time: the delete succeeds either way and the Package reappears whenever that upgrade happens to run.
+
+`kubectl delete hr` is not a lighter-weight version of this. Flux uninstalls the release when the HelmRelease goes away, so it destroys the same CRDs and custom resources, and then the Package recreates the HelmRelease and the chart reinstalls. The workloads come back, the custom resources do not. If you have run it before, those custom resources are already gone and have to be recreated from your own manifests or a backup.
diff --git a/content/en/docs/v1.4/operations/configuration/components.md b/content/en/docs/v1.4/operations/configuration/components.md
index f3ce3c92..98e76f8f 100644
--- a/content/en/docs/v1.4/operations/configuration/components.md
+++ b/content/en/docs/v1.4/operations/configuration/components.md
@@ -70,8 +70,25 @@ spec:
 
 Disabling components must be done before installing Cozystack.
 Applying updated configuration with `disabledPackages` will not remove components that are already installed.
-To remove already installed components, delete the Helm release manually using this command:
+Removing one that is already installed takes two steps. Add its name to `disabledPackages` in the Platform Package above, then wait for the operator to carry that edit across. The name appears in this output once it has:
 
 ```bash
-kubectl delete hr -n <namespace> <component>
+kubectl get helmrelease cozystack-platform --namespace cozy-system \
+  --output jsonpath='{.spec.values.bundles.disabledPackages}'
 ```
+
+Then delete the Package object. `kubectl get packages` lists the names.
+
+{{% alert title="Warning" color="warning" %}}
+Deleting the Package uninstalls the component's Helm release, and that destroys more than the workloads. Anything the chart rendered as an ordinary template without `helm.sh/resource-policy: keep` goes with the release, CRDs and namespaces included, and Kubernetes deletes every custom resource of those CRD kinds along with them. Removing `cozystack.metallb` takes the MetalLB CRDs and with them every IPAddressPool, L2Advertisement, BGPPeer and the rest of those kinds cluster-wide; removing `cozystack.cozystack-basics` takes the `cozy-public` namespace and everything stored in it. Back up anything you still need first.
+{{% /alert %}}
+
+The namespace a component installs into is the exception: the operator applies that one itself, outside the component's release and with no ownerReference, so the uninstall never had it to remove.
+
+```bash
+kubectl delete package.cozystack.io <package-name>
+```
+
+Deleting the Package while the platform values still render it means the next platform upgrade brings it back, undoing the removal one level up. Nothing reports this at the time: the delete succeeds either way and the Package reappears whenever that upgrade happens to run.
+
+`kubectl delete hr` is not a lighter-weight version of this. Flux uninstalls the release when the HelmRelease goes away, so it destroys the same CRDs and custom resources, and then the Package recreates the HelmRelease and the chart reinstalls. The workloads come back, the custom resources do not. If you have run it before, those custom resources are already gone and have to be recreated from your own manifests or a backup.
diff --git a/content/en/docs/v1.5/operations/configuration/components.md b/content/en/docs/v1.5/operations/configuration/components.md
index 3d799682..cdcf189f 100644
--- a/content/en/docs/v1.5/operations/configuration/components.md
+++ b/content/en/docs/v1.5/operations/configuration/components.md
@@ -70,8 +70,25 @@ spec:
 
 Disabling components must be done before installing Cozystack.
 Applying updated configuration with `disabledPackages` will not remove components that are already installed.
-To remove already installed components, delete the Helm release manually using this command:
+Removing one that is already installed takes two steps. Add its name to `disabledPackages` in the Platform Package above, then wait for the operator to carry that edit across. The name appears in this output once it has:
 
 ```bash
-kubectl delete hr -n <namespace> <component>
+kubectl get helmrelease cozystack-platform --namespace cozy-system \
+  --output jsonpath='{.spec.values.bundles.disabledPackages}'
 ```
+
+Then delete the Package object. `kubectl get packages` lists the names.
+
+{{% alert title="Warning" color="warning" %}}
+Deleting the Package uninstalls the component's Helm release, and that destroys more than the workloads. Anything the chart rendered as an ordinary template without `helm.sh/resource-policy: keep` goes with the release, CRDs and namespaces included, and Kubernetes deletes every custom resource of those CRD kinds along with them. Removing `cozystack.metallb` takes the MetalLB CRDs and with them every IPAddressPool, L2Advertisement, BGPPeer and the rest of those kinds cluster-wide; removing `cozystack.cozystack-basics` takes the `cozy-public` namespace and everything stored in it. Back up anything you still need first.
+{{% /alert %}}
+
+The namespace a component installs into is the exception: the operator applies that one itself, outside the component's release and with no ownerReference, so the uninstall never had it to remove.
+
+```bash
+kubectl delete package.cozystack.io <package-name>
+```
+
+Deleting the Package while the platform values still render it means the next platform upgrade brings it back, undoing the removal one level up. Nothing reports this at the time: the delete succeeds either way and the Package reappears whenever that upgrade happens to run.
+
+`kubectl delete hr` is not a lighter-weight version of this. Flux uninstalls the release when the HelmRelease goes away, so it destroys the same CRDs and custom resources, and then the Package recreates the HelmRelease and the chart reinstalls. The workloads come back, the custom resources do not. If you have run it before, those custom resources are already gone and have to be recreated from your own manifests or a backup.
diff --git a/content/en/docs/v1.6/operations/configuration/components.md b/content/en/docs/v1.6/operations/configuration/components.md
index 7224274c..6adec197 100644
--- a/content/en/docs/v1.6/operations/configuration/components.md
+++ b/content/en/docs/v1.6/operations/configuration/components.md
@@ -70,8 +70,25 @@ spec:
 
 Disabling components must be done before installing Cozystack.
 Applying updated configuration with `disabledPackages` will not remove components that are already installed.
-To remove already installed components, delete the Helm release manually using this command:
+Removing one that is already installed takes two steps. Add its name to `disabledPackages` in the Platform Package above, then wait for the operator to carry that edit across. The name appears in this output once it has:
 
 ```bash
-kubectl delete hr -n <namespace> <component>
+kubectl get helmrelease cozystack-platform --namespace cozy-system \
+  --output jsonpath='{.spec.values.bundles.disabledPackages}'
 ```
+
+Then delete the Package object. `kubectl get packages` lists the names.
+
+{{% alert title="Warning" color="warning" %}}
+Deleting the Package uninstalls the component's Helm release, and that destroys more than the workloads. Anything the chart rendered as an ordinary template without `helm.sh/resource-policy: keep` goes with the release, CRDs and namespaces included, and Kubernetes deletes every custom resource of those CRD kinds along with them. Removing `cozystack.metallb` takes the MetalLB CRDs and with them every IPAddressPool, L2Advertisement, BGPPeer and the rest of those kinds cluster-wide; removing `cozystack.cozystack-basics` takes the `cozy-public` namespace and everything stored in it. Back up anything you still need first.
+{{% /alert %}}
+
+The namespace a component installs into is the exception: the operator applies that one itself, outside the component's release and with no ownerReference, so the uninstall never had it to remove.
+
+```bash
+kubectl delete package.cozystack.io <package-name>
+```
+
+Deleting the Package while the platform values still render it means the next platform upgrade brings it back, undoing the removal one level up. Nothing reports this at the time: the delete succeeds either way and the Package reappears whenever that upgrade happens to run.
+
+`kubectl delete hr` is not a lighter-weight version of this. Flux uninstalls the release when the HelmRelease goes away, so it destroys the same CRDs and custom resources, and then the Package recreates the HelmRelease and the chart reinstalls. The workloads come back, the custom resources do not. If you have run it before, those custom resources are already gone and have to be recreated from your own manifests or a backup.

From e25136bd25e874e7297ff7034bb743adff954013 Mon Sep 17 00:00:00 2001
From: Aleksei Sviridkin <f@lex.la>
Date: Tue, 8 Sep 2026 01:58:25 +0300
Subject: [PATCH 2/4] fix(i18n): add the Live Demo section to the translated
 home pages

The English home page gained a Live Demo block; the four translations
did not, so their recorded source digest no longer matched and the
freshness guard failed on every pull request against main.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>
---
 content/de/_index.md    | 13 ++++++++++++-
 content/hi/_index.md    | 13 ++++++++++++-
 content/ru/_index.md    | 13 ++++++++++++-
 content/zh-cn/_index.md | 13 ++++++++++++-
 4 files changed, 48 insertions(+), 4 deletions(-)

diff --git a/content/de/_index.md b/content/de/_index.md
index 229a28d0..06dd00da 100644
--- a/content/de/_index.md
+++ b/content/de/_index.md
@@ -8,7 +8,7 @@ seo:
   title: "Cozystack — Open-Source Private Cloud auf Kubernetes"
   description: "Open-Source-Cloud-Plattform auf Kubernetes für Managed VMs, Datenbanken, S3-Storage und GPU-Workloads. CNCF-Sandbox-Projekt."
   keywords: ["private cloud", "managed kubernetes", "kubernetes plattform", "open source cloud"]
-source_digest: "sha256:24e38da4716b93c35dcb9eb607152d193ef3d5ad42c0e22a25063a89da9f8dde"
+source_digest: "sha256:e8f982c2431355bc79d3bb2133781cc539553c4c0a293d36e4c23dc54e7fcf80"
 translation_status: current
 l10n: transcreate
 taglines:
@@ -83,6 +83,17 @@ features:
 <!-- Screenshot Gallery -->
 {{< home/screenshot-gallery >}}
 
+<!-- Live Demo -->
+<div class="section-live-demo">
+{{< blocks/lead color="primary" >}}
+<h2 class="section-label">Sehen Sie die Konsole, bevor Sie irgendetwas installieren</h2>
+
+Das echte Dashboard von Cozystack, vollständig in Ihrem Browser — kein Cluster, keine Anmeldung, keine Einrichtung. Stöbern Sie im Marketplace, öffnen Sie Managed Services, klicken Sie sich durch die Konsole. Es ist die echte UI, nur mit Demo-Daten.
+
+<a class="btn btn-lg btn-primary mt-4" href="/demo/">Live-Demo öffnen &rarr;</a>
+{{< /blocks/lead >}}
+</div>
+
 <!-- Benefits & Features -->
 
 {{< home/benefits >}}
diff --git a/content/hi/_index.md b/content/hi/_index.md
index e3cfdb54..1b96915a 100644
--- a/content/hi/_index.md
+++ b/content/hi/_index.md
@@ -8,7 +8,7 @@ seo:
   title: "Cozystack — Kubernetes पर ओपन-सोर्स प्राइवेट क्लाउड"
   description: "Kubernetes पर ओपन-सोर्स क्लाउड प्लेटफ़ॉर्म: मैनेज्ड VMs, डेटाबेस, S3 स्टोरेज और GPU वर्कलोड। CNCF Sandbox प्रोजेक्ट।"
   keywords: ["private cloud", "managed kubernetes", "kubernetes platform", "cloud platform"]
-source_digest: "sha256:24e38da4716b93c35dcb9eb607152d193ef3d5ad42c0e22a25063a89da9f8dde"
+source_digest: "sha256:e8f982c2431355bc79d3bb2133781cc539553c4c0a293d36e4c23dc54e7fcf80"
 translation_status: current
 l10n: transcreate
 taglines:
@@ -83,6 +83,17 @@ features:
 <!-- Screenshot Gallery -->
 {{< home/screenshot-gallery >}}
 
+<!-- Live Demo -->
+<div class="section-live-demo">
+{{< blocks/lead color="primary" >}}
+<h2 class="section-label">कुछ भी इंस्टॉल करने से पहले कंसोल देखें</h2>
+
+Cozystack का असली डैशबोर्ड, पूरी तरह आपके ब्राउज़र में चलता हुआ — न क्लस्टर, न साइनअप, न सेटअप। मार्केटप्लेस देखें, मैनेज्ड सेवाएँ खोलें, कंसोल में क्लिक करके घूमें। यह असली UI ही है, बस डेमो डेटा के साथ।
+
+<a class="btn btn-lg btn-primary mt-4" href="/demo/">लाइव डेमो खोलें &rarr;</a>
+{{< /blocks/lead >}}
+</div>
+
 <!-- Benefits & Features -->
 
 {{< home/benefits >}}
diff --git a/content/ru/_index.md b/content/ru/_index.md
index f4d19482..230785d3 100644
--- a/content/ru/_index.md
+++ b/content/ru/_index.md
@@ -8,7 +8,7 @@ seo:
   title: "Cozystack — частное облако с открытым кодом на Kubernetes"
   description: "Open-source облачная платформа на Kubernetes: управляемые ВМ, базы данных, S3-хранилище и GPU. Проект CNCF Sandbox."
   keywords: ["частное облако", "managed kubernetes", "kubernetes платформа", "облачная платформа"]
-source_digest: "sha256:24e38da4716b93c35dcb9eb607152d193ef3d5ad42c0e22a25063a89da9f8dde"
+source_digest: "sha256:e8f982c2431355bc79d3bb2133781cc539553c4c0a293d36e4c23dc54e7fcf80"
 translation_status: current
 l10n: transcreate
 taglines:
@@ -83,6 +83,17 @@ features:
 <!-- Screenshot Gallery -->
 {{< home/screenshot-gallery >}}
 
+<!-- Live Demo -->
+<div class="section-live-demo">
+{{< blocks/lead color="primary" >}}
+<h2 class="section-label">Посмотрите на консоль до того, как что-то устанавливать</h2>
+
+Настоящая панель управления Cozystack, целиком работающая в браузере — без кластера, без регистрации, без настройки. Загляните в маркетплейс, откройте управляемые сервисы, покликайте по консоли. Это тот самый интерфейс, только с демонстрационными данными.
+
+<a class="btn btn-lg btn-primary mt-4" href="/demo/">Открыть живое демо &rarr;</a>
+{{< /blocks/lead >}}
+</div>
+
 <!-- Benefits & Features -->
 
 {{< home/benefits >}}
diff --git a/content/zh-cn/_index.md b/content/zh-cn/_index.md
index 1c4c4391..26e42a9f 100644
--- a/content/zh-cn/_index.md
+++ b/content/zh-cn/_index.md
@@ -8,7 +8,7 @@ seo:
   title: "Cozystack — 基于 Kubernetes 的开源私有云"
   description: "基于 Kubernetes 的开源云平台，提供托管虚拟机、数据库、S3 存储和 GPU 工作负载。CNCF Sandbox 项目。"
   keywords: ["私有云", "Kubernetes", "开源云平台", "托管 Kubernetes"]
-source_digest: "sha256:24e38da4716b93c35dcb9eb607152d193ef3d5ad42c0e22a25063a89da9f8dde"
+source_digest: "sha256:e8f982c2431355bc79d3bb2133781cc539553c4c0a293d36e4c23dc54e7fcf80"
 translation_status: current
 l10n: transcreate
 taglines:
@@ -83,6 +83,17 @@ features:
 <!-- Screenshot Gallery -->
 {{< home/screenshot-gallery >}}
 
+<!-- Live Demo -->
+<div class="section-live-demo">
+{{< blocks/lead color="primary" >}}
+<h2 class="section-label">先看看控制台，再决定是否安装</h2>
+
+真实的 Cozystack 仪表盘，完全在你的浏览器中运行——无需集群、无需注册、无需配置。浏览应用市场，打开托管服务，随意点击体验控制台。这就是真正的 UI，只是换成了演示数据。
+
+<a class="btn btn-lg btn-primary mt-4" href="/demo/">打开在线演示 &rarr;</a>
+{{< /blocks/lead >}}
+</div>
+
 <!-- Benefits & Features -->
 
 {{< home/benefits >}}

From f6e58e6a9896db4bd1927e44a0111c47ff1865e1 Mon Sep 17 00:00:00 2001
From: Aleksei Sviridkin <f@lex.la>
Date: Tue, 8 Sep 2026 02:06:43 +0300
Subject: [PATCH 3/4] docs(operations): widen the uninstall warning and give it
 a done signal

The named CRD kinds in the warning cover the top-level MetalLB chart
only; a subchart such as frr-k8s brings its own group, so the list
undercounts what an uninstall takes. Point at the chart instead of
enumerating kinds, which also stops the list needing maintenance per
component.

Package carries no finalizer, so deleting it returns before the Helm
uninstall that follows it has done anything. Add the wait that tells an
operator the destructive part is over.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>
---
 .../en/docs/next/operations/configuration/components.md   | 8 +++++++-
 .../en/docs/v1.1/operations/configuration/components.md   | 8 +++++++-
 .../en/docs/v1.2/operations/configuration/components.md   | 8 +++++++-
 .../en/docs/v1.3/operations/configuration/components.md   | 8 +++++++-
 .../en/docs/v1.4/operations/configuration/components.md   | 8 +++++++-
 .../en/docs/v1.5/operations/configuration/components.md   | 8 +++++++-
 .../en/docs/v1.6/operations/configuration/components.md   | 8 +++++++-
 7 files changed, 49 insertions(+), 7 deletions(-)

diff --git a/content/en/docs/next/operations/configuration/components.md b/content/en/docs/next/operations/configuration/components.md
index 75882fbf..870f646e 100644
--- a/content/en/docs/next/operations/configuration/components.md
+++ b/content/en/docs/next/operations/configuration/components.md
@@ -80,7 +80,7 @@ kubectl get helmrelease cozystack-platform --namespace cozy-system \
 Then delete the Package object. `kubectl get packages` lists the names.
 
 {{% alert title="Warning" color="warning" %}}
-Deleting the Package uninstalls the component's Helm release, and that destroys more than the workloads. Anything the chart rendered as an ordinary template without `helm.sh/resource-policy: keep` goes with the release, CRDs and namespaces included, and Kubernetes deletes every custom resource of those CRD kinds along with them. Removing `cozystack.metallb` takes the MetalLB CRDs and with them every IPAddressPool, L2Advertisement, BGPPeer and the rest of those kinds cluster-wide; removing `cozystack.cozystack-basics` takes the `cozy-public` namespace and everything stored in it. Back up anything you still need first.
+Deleting the Package uninstalls the component's Helm release, and that destroys more than the workloads. Anything the chart rendered as an ordinary template without `helm.sh/resource-policy: keep` goes with the release, CRDs and namespaces included, and Kubernetes deletes every custom resource of those CRD kinds along with them. Removing `cozystack.metallb` takes every CRD the MetalLB chart bundles, subcharts included, and with them every custom resource of those kinds cluster-wide; removing `cozystack.cozystack-basics` takes the `cozy-public` namespace and everything stored in it. Back up anything you still need first.
 {{% /alert %}}
 
 The namespace a component installs into is the exception: the operator applies that one itself, outside the component's release and with no ownerReference, so the uninstall never had it to remove.
@@ -89,6 +89,12 @@ The namespace a component installs into is the exception: the operator applies t
 kubectl delete package.cozystack.io <package-name>
 ```
 
+Nothing holds a finalizer on the Package, so this command returns as soon as the object is gone and the uninstall it triggers runs afterwards. Wait on the HelmRelease to know the destructive part has finished:
+
+```bash
+kubectl wait --for=delete helmrelease/<component> --namespace <namespace> --timeout=10m
+```
+
 Deleting the Package while the platform values still render it means the next platform upgrade brings it back, undoing the removal one level up. Nothing reports this at the time: the delete succeeds either way and the Package reappears whenever that upgrade happens to run.
 
 `kubectl delete hr` is not a lighter-weight version of this. Flux uninstalls the release when the HelmRelease goes away, so it destroys the same CRDs and custom resources, and then the Package recreates the HelmRelease and the chart reinstalls. The workloads come back, the custom resources do not. If you have run it before, those custom resources are already gone and have to be recreated from your own manifests or a backup.
diff --git a/content/en/docs/v1.1/operations/configuration/components.md b/content/en/docs/v1.1/operations/configuration/components.md
index 37df376b..63075ae5 100644
--- a/content/en/docs/v1.1/operations/configuration/components.md
+++ b/content/en/docs/v1.1/operations/configuration/components.md
@@ -75,7 +75,7 @@ kubectl get helmrelease cozystack-platform --namespace cozy-system \
 Then delete the Package object. `kubectl get packages` lists the names.
 
 {{% alert title="Warning" color="warning" %}}
-Deleting the Package uninstalls the component's Helm release, and that destroys more than the workloads. Anything the chart rendered as an ordinary template without `helm.sh/resource-policy: keep` goes with the release, CRDs and namespaces included, and Kubernetes deletes every custom resource of those CRD kinds along with them. Removing `cozystack.metallb` takes the MetalLB CRDs and with them every IPAddressPool, L2Advertisement, BGPPeer and the rest of those kinds cluster-wide; removing `cozystack.cozystack-basics` takes the `cozy-public` namespace and everything stored in it. Back up anything you still need first.
+Deleting the Package uninstalls the component's Helm release, and that destroys more than the workloads. Anything the chart rendered as an ordinary template without `helm.sh/resource-policy: keep` goes with the release, CRDs and namespaces included, and Kubernetes deletes every custom resource of those CRD kinds along with them. Removing `cozystack.metallb` takes every CRD the MetalLB chart bundles, subcharts included, and with them every custom resource of those kinds cluster-wide; removing `cozystack.cozystack-basics` takes the `cozy-public` namespace and everything stored in it. Back up anything you still need first.
 {{% /alert %}}
 
 The namespace a component installs into is the exception: the operator applies that one itself, outside the component's release and with no ownerReference, so the uninstall never had it to remove.
@@ -84,6 +84,12 @@ The namespace a component installs into is the exception: the operator applies t
 kubectl delete package.cozystack.io <package-name>
 ```
 
+Nothing holds a finalizer on the Package, so this command returns as soon as the object is gone and the uninstall it triggers runs afterwards. Wait on the HelmRelease to know the destructive part has finished:
+
+```bash
+kubectl wait --for=delete helmrelease/<component> --namespace <namespace> --timeout=10m
+```
+
 Deleting the Package while the platform values still render it means the next platform upgrade brings it back, undoing the removal one level up. Nothing reports this at the time: the delete succeeds either way and the Package reappears whenever that upgrade happens to run.
 
 `kubectl delete hr` is not a lighter-weight version of this. Flux uninstalls the release when the HelmRelease goes away, so it destroys the same CRDs and custom resources, and then the Package recreates the HelmRelease and the chart reinstalls. The workloads come back, the custom resources do not. If you have run it before, those custom resources are already gone and have to be recreated from your own manifests or a backup.
diff --git a/content/en/docs/v1.2/operations/configuration/components.md b/content/en/docs/v1.2/operations/configuration/components.md
index e358038f..0fa2e4c6 100644
--- a/content/en/docs/v1.2/operations/configuration/components.md
+++ b/content/en/docs/v1.2/operations/configuration/components.md
@@ -80,7 +80,7 @@ kubectl get helmrelease cozystack-platform --namespace cozy-system \
 Then delete the Package object. `kubectl get packages` lists the names.
 
 {{% alert title="Warning" color="warning" %}}
-Deleting the Package uninstalls the component's Helm release, and that destroys more than the workloads. Anything the chart rendered as an ordinary template without `helm.sh/resource-policy: keep` goes with the release, CRDs and namespaces included, and Kubernetes deletes every custom resource of those CRD kinds along with them. Removing `cozystack.metallb` takes the MetalLB CRDs and with them every IPAddressPool, L2Advertisement, BGPPeer and the rest of those kinds cluster-wide; removing `cozystack.cozystack-basics` takes the `cozy-public` namespace and everything stored in it. Back up anything you still need first.
+Deleting the Package uninstalls the component's Helm release, and that destroys more than the workloads. Anything the chart rendered as an ordinary template without `helm.sh/resource-policy: keep` goes with the release, CRDs and namespaces included, and Kubernetes deletes every custom resource of those CRD kinds along with them. Removing `cozystack.metallb` takes every CRD the MetalLB chart bundles, subcharts included, and with them every custom resource of those kinds cluster-wide; removing `cozystack.cozystack-basics` takes the `cozy-public` namespace and everything stored in it. Back up anything you still need first.
 {{% /alert %}}
 
 The namespace a component installs into is the exception: the operator applies that one itself, outside the component's release and with no ownerReference, so the uninstall never had it to remove.
@@ -89,6 +89,12 @@ The namespace a component installs into is the exception: the operator applies t
 kubectl delete package.cozystack.io <package-name>
 ```
 
+Nothing holds a finalizer on the Package, so this command returns as soon as the object is gone and the uninstall it triggers runs afterwards. Wait on the HelmRelease to know the destructive part has finished:
+
+```bash
+kubectl wait --for=delete helmrelease/<component> --namespace <namespace> --timeout=10m
+```
+
 Deleting the Package while the platform values still render it means the next platform upgrade brings it back, undoing the removal one level up. Nothing reports this at the time: the delete succeeds either way and the Package reappears whenever that upgrade happens to run.
 
 `kubectl delete hr` is not a lighter-weight version of this. Flux uninstalls the release when the HelmRelease goes away, so it destroys the same CRDs and custom resources, and then the Package recreates the HelmRelease and the chart reinstalls. The workloads come back, the custom resources do not. If you have run it before, those custom resources are already gone and have to be recreated from your own manifests or a backup.
diff --git a/content/en/docs/v1.3/operations/configuration/components.md b/content/en/docs/v1.3/operations/configuration/components.md
index aa372ed6..18346727 100644
--- a/content/en/docs/v1.3/operations/configuration/components.md
+++ b/content/en/docs/v1.3/operations/configuration/components.md
@@ -80,7 +80,7 @@ kubectl get helmrelease cozystack-platform --namespace cozy-system \
 Then delete the Package object. `kubectl get packages` lists the names.
 
 {{% alert title="Warning" color="warning" %}}
-Deleting the Package uninstalls the component's Helm release, and that destroys more than the workloads. Anything the chart rendered as an ordinary template without `helm.sh/resource-policy: keep` goes with the release, CRDs and namespaces included, and Kubernetes deletes every custom resource of those CRD kinds along with them. Removing `cozystack.metallb` takes the MetalLB CRDs and with them every IPAddressPool, L2Advertisement, BGPPeer and the rest of those kinds cluster-wide; removing `cozystack.cozystack-basics` takes the `cozy-public` namespace and everything stored in it. Back up anything you still need first.
+Deleting the Package uninstalls the component's Helm release, and that destroys more than the workloads. Anything the chart rendered as an ordinary template without `helm.sh/resource-policy: keep` goes with the release, CRDs and namespaces included, and Kubernetes deletes every custom resource of those CRD kinds along with them. Removing `cozystack.metallb` takes every CRD the MetalLB chart bundles, subcharts included, and with them every custom resource of those kinds cluster-wide; removing `cozystack.cozystack-basics` takes the `cozy-public` namespace and everything stored in it. Back up anything you still need first.
 {{% /alert %}}
 
 The namespace a component installs into is the exception: the operator applies that one itself, outside the component's release and with no ownerReference, so the uninstall never had it to remove.
@@ -89,6 +89,12 @@ The namespace a component installs into is the exception: the operator applies t
 kubectl delete package.cozystack.io <package-name>
 ```
 
+Nothing holds a finalizer on the Package, so this command returns as soon as the object is gone and the uninstall it triggers runs afterwards. Wait on the HelmRelease to know the destructive part has finished:
+
+```bash
+kubectl wait --for=delete helmrelease/<component> --namespace <namespace> --timeout=10m
+```
+
 Deleting the Package while the platform values still render it means the next platform upgrade brings it back, undoing the removal one level up. Nothing reports this at the time: the delete succeeds either way and the Package reappears whenever that upgrade happens to run.
 
 `kubectl delete hr` is not a lighter-weight version of this. Flux uninstalls the release when the HelmRelease goes away, so it destroys the same CRDs and custom resources, and then the Package recreates the HelmRelease and the chart reinstalls. The workloads come back, the custom resources do not. If you have run it before, those custom resources are already gone and have to be recreated from your own manifests or a backup.
diff --git a/content/en/docs/v1.4/operations/configuration/components.md b/content/en/docs/v1.4/operations/configuration/components.md
index 98e76f8f..84b57679 100644
--- a/content/en/docs/v1.4/operations/configuration/components.md
+++ b/content/en/docs/v1.4/operations/configuration/components.md
@@ -80,7 +80,7 @@ kubectl get helmrelease cozystack-platform --namespace cozy-system \
 Then delete the Package object. `kubectl get packages` lists the names.
 
 {{% alert title="Warning" color="warning" %}}
-Deleting the Package uninstalls the component's Helm release, and that destroys more than the workloads. Anything the chart rendered as an ordinary template without `helm.sh/resource-policy: keep` goes with the release, CRDs and namespaces included, and Kubernetes deletes every custom resource of those CRD kinds along with them. Removing `cozystack.metallb` takes the MetalLB CRDs and with them every IPAddressPool, L2Advertisement, BGPPeer and the rest of those kinds cluster-wide; removing `cozystack.cozystack-basics` takes the `cozy-public` namespace and everything stored in it. Back up anything you still need first.
+Deleting the Package uninstalls the component's Helm release, and that destroys more than the workloads. Anything the chart rendered as an ordinary template without `helm.sh/resource-policy: keep` goes with the release, CRDs and namespaces included, and Kubernetes deletes every custom resource of those CRD kinds along with them. Removing `cozystack.metallb` takes every CRD the MetalLB chart bundles, subcharts included, and with them every custom resource of those kinds cluster-wide; removing `cozystack.cozystack-basics` takes the `cozy-public` namespace and everything stored in it. Back up anything you still need first.
 {{% /alert %}}
 
 The namespace a component installs into is the exception: the operator applies that one itself, outside the component's release and with no ownerReference, so the uninstall never had it to remove.
@@ -89,6 +89,12 @@ The namespace a component installs into is the exception: the operator applies t
 kubectl delete package.cozystack.io <package-name>
 ```
 
+Nothing holds a finalizer on the Package, so this command returns as soon as the object is gone and the uninstall it triggers runs afterwards. Wait on the HelmRelease to know the destructive part has finished:
+
+```bash
+kubectl wait --for=delete helmrelease/<component> --namespace <namespace> --timeout=10m
+```
+
 Deleting the Package while the platform values still render it means the next platform upgrade brings it back, undoing the removal one level up. Nothing reports this at the time: the delete succeeds either way and the Package reappears whenever that upgrade happens to run.
 
 `kubectl delete hr` is not a lighter-weight version of this. Flux uninstalls the release when the HelmRelease goes away, so it destroys the same CRDs and custom resources, and then the Package recreates the HelmRelease and the chart reinstalls. The workloads come back, the custom resources do not. If you have run it before, those custom resources are already gone and have to be recreated from your own manifests or a backup.
diff --git a/content/en/docs/v1.5/operations/configuration/components.md b/content/en/docs/v1.5/operations/configuration/components.md
index cdcf189f..30d31d73 100644
--- a/content/en/docs/v1.5/operations/configuration/components.md
+++ b/content/en/docs/v1.5/operations/configuration/components.md
@@ -80,7 +80,7 @@ kubectl get helmrelease cozystack-platform --namespace cozy-system \
 Then delete the Package object. `kubectl get packages` lists the names.
 
 {{% alert title="Warning" color="warning" %}}
-Deleting the Package uninstalls the component's Helm release, and that destroys more than the workloads. Anything the chart rendered as an ordinary template without `helm.sh/resource-policy: keep` goes with the release, CRDs and namespaces included, and Kubernetes deletes every custom resource of those CRD kinds along with them. Removing `cozystack.metallb` takes the MetalLB CRDs and with them every IPAddressPool, L2Advertisement, BGPPeer and the rest of those kinds cluster-wide; removing `cozystack.cozystack-basics` takes the `cozy-public` namespace and everything stored in it. Back up anything you still need first.
+Deleting the Package uninstalls the component's Helm release, and that destroys more than the workloads. Anything the chart rendered as an ordinary template without `helm.sh/resource-policy: keep` goes with the release, CRDs and namespaces included, and Kubernetes deletes every custom resource of those CRD kinds along with them. Removing `cozystack.metallb` takes every CRD the MetalLB chart bundles, subcharts included, and with them every custom resource of those kinds cluster-wide; removing `cozystack.cozystack-basics` takes the `cozy-public` namespace and everything stored in it. Back up anything you still need first.
 {{% /alert %}}
 
 The namespace a component installs into is the exception: the operator applies that one itself, outside the component's release and with no ownerReference, so the uninstall never had it to remove.
@@ -89,6 +89,12 @@ The namespace a component installs into is the exception: the operator applies t
 kubectl delete package.cozystack.io <package-name>
 ```
 
+Nothing holds a finalizer on the Package, so this command returns as soon as the object is gone and the uninstall it triggers runs afterwards. Wait on the HelmRelease to know the destructive part has finished:
+
+```bash
+kubectl wait --for=delete helmrelease/<component> --namespace <namespace> --timeout=10m
+```
+
 Deleting the Package while the platform values still render it means the next platform upgrade brings it back, undoing the removal one level up. Nothing reports this at the time: the delete succeeds either way and the Package reappears whenever that upgrade happens to run.
 
 `kubectl delete hr` is not a lighter-weight version of this. Flux uninstalls the release when the HelmRelease goes away, so it destroys the same CRDs and custom resources, and then the Package recreates the HelmRelease and the chart reinstalls. The workloads come back, the custom resources do not. If you have run it before, those custom resources are already gone and have to be recreated from your own manifests or a backup.
diff --git a/content/en/docs/v1.6/operations/configuration/components.md b/content/en/docs/v1.6/operations/configuration/components.md
index 6adec197..c746dbc6 100644
--- a/content/en/docs/v1.6/operations/configuration/components.md
+++ b/content/en/docs/v1.6/operations/configuration/components.md
@@ -80,7 +80,7 @@ kubectl get helmrelease cozystack-platform --namespace cozy-system \
 Then delete the Package object. `kubectl get packages` lists the names.
 
 {{% alert title="Warning" color="warning" %}}
-Deleting the Package uninstalls the component's Helm release, and that destroys more than the workloads. Anything the chart rendered as an ordinary template without `helm.sh/resource-policy: keep` goes with the release, CRDs and namespaces included, and Kubernetes deletes every custom resource of those CRD kinds along with them. Removing `cozystack.metallb` takes the MetalLB CRDs and with them every IPAddressPool, L2Advertisement, BGPPeer and the rest of those kinds cluster-wide; removing `cozystack.cozystack-basics` takes the `cozy-public` namespace and everything stored in it. Back up anything you still need first.
+Deleting the Package uninstalls the component's Helm release, and that destroys more than the workloads. Anything the chart rendered as an ordinary template without `helm.sh/resource-policy: keep` goes with the release, CRDs and namespaces included, and Kubernetes deletes every custom resource of those CRD kinds along with them. Removing `cozystack.metallb` takes every CRD the MetalLB chart bundles, subcharts included, and with them every custom resource of those kinds cluster-wide; removing `cozystack.cozystack-basics` takes the `cozy-public` namespace and everything stored in it. Back up anything you still need first.
 {{% /alert %}}
 
 The namespace a component installs into is the exception: the operator applies that one itself, outside the component's release and with no ownerReference, so the uninstall never had it to remove.
@@ -89,6 +89,12 @@ The namespace a component installs into is the exception: the operator applies t
 kubectl delete package.cozystack.io <package-name>
 ```
 
+Nothing holds a finalizer on the Package, so this command returns as soon as the object is gone and the uninstall it triggers runs afterwards. Wait on the HelmRelease to know the destructive part has finished:
+
+```bash
+kubectl wait --for=delete helmrelease/<component> --namespace <namespace> --timeout=10m
+```
+
 Deleting the Package while the platform values still render it means the next platform upgrade brings it back, undoing the removal one level up. Nothing reports this at the time: the delete succeeds either way and the Package reappears whenever that upgrade happens to run.
 
 `kubectl delete hr` is not a lighter-weight version of this. Flux uninstalls the release when the HelmRelease goes away, so it destroys the same CRDs and custom resources, and then the Package recreates the HelmRelease and the chart reinstalls. The workloads come back, the custom resources do not. If you have run it before, those custom resources are already gone and have to be recreated from your own manifests or a backup.

From 44e27e68bd7009464d086abc8eb2e6eeb65e5f48 Mon Sep 17 00:00:00 2001
From: Aleksei Sviridkin <f@lex.la>
Date: Tue, 8 Sep 2026 02:06:50 +0300
Subject: [PATCH 4/4] docs(operations): correct the component removal path on
 v1.0

v1.0 documented `kubectl delete hr` as the way to remove an installed
component, with no warning about what an uninstall takes with it. That
command destroys the CRDs and every custom resource of those kinds, then
the Package recreates the HelmRelease and the chart reinstalls, so the
workloads come back and the data does not.

v1.0 needs a different correction from later versions rather than a copy
of it: the platform does not annotate rendered Packages with
`helm.sh/resource-policy: keep`, so `disabledPackages` alone already
removes an installed component there, in one step and with no
confirmation.

Also qualify the package names in the Hetzner and components examples.
`disabledPackages` and `enabledPackages` are matched against the full
`cozystack.<name>` form, so the bare names did nothing.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>
---
 .../en/docs/v1.0/install/providers/hetzner.md  |  4 ++--
 .../operations/configuration/components.md     | 18 +++++++++++-------
 2 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/content/en/docs/v1.0/install/providers/hetzner.md b/content/en/docs/v1.0/install/providers/hetzner.md
index 22eca2db..4cfe2ace 100644
--- a/content/en/docs/v1.0/install/providers/hetzner.md
+++ b/content/en/docs/v1.0/install/providers/hetzner.md
@@ -344,9 +344,9 @@ The final stage of deploying a Cozystack cluster on Hetzner is to install Cozyst
           values:
             bundles:
               disabledPackages:
-                - metallb
+                - cozystack.metallb
               enabledPackages:
-                - hetzner-robotlb
+                - cozystack.hetzner-robotlb
             publishing:
               host: "example.org"
               apiServerEndpoint: "https://api.example.org:443"
diff --git a/content/en/docs/v1.0/operations/configuration/components.md b/content/en/docs/v1.0/operations/configuration/components.md
index 1f04669a..7905c746 100644
--- a/content/en/docs/v1.0/operations/configuration/components.md
+++ b/content/en/docs/v1.0/operations/configuration/components.md
@@ -56,16 +56,20 @@ spec:
       values:
         bundles:
           disabledPackages:
-            - metallb
+            - cozystack.metallb
           enabledPackages:
-            - hetzner-robotlb
+            - cozystack.hetzner-robotlb
         # rest of the config
 ```
 
 Disabling components must be done before installing Cozystack.
-Applying updated configuration with `disabledPackages` will not remove components that are already installed.
-To remove already installed components, delete the Helm release manually using this command:
 
-```bash
-kubectl delete hr -n <namespace> <component>
-```
+On v1.0 the platform does not annotate the Packages it renders with `helm.sh/resource-policy: keep`, so adding a name to `disabledPackages` also removes the component when it is already installed. The next platform reconcile drops the Package, the operator's ownerReference takes the component's HelmRelease with it, and Flux uninstalls the release. There is no second command and no confirmation step, so back up anything you still need before making that edit.
+
+{{% alert title="Warning" color="warning" %}}
+Uninstalling the component's Helm release destroys more than the workloads. Anything the chart rendered as an ordinary template without `helm.sh/resource-policy: keep` goes with the release, CRDs and namespaces included, and Kubernetes deletes every custom resource of those CRD kinds along with them. Removing `cozystack.metallb` takes every CRD the MetalLB chart bundles, subcharts included, and with them every custom resource of those kinds cluster-wide; removing `cozystack.cozystack-basics` takes the `cozy-public` namespace and everything stored in it. Back up anything you still need first.
+{{% /alert %}}
+
+The namespace a component installs into is the exception: the operator applies that one itself, outside the component's release and with no ownerReference, so the uninstall never had it to remove.
+
+`kubectl delete hr` is not a lighter-weight way to do the same thing. Flux uninstalls the release when the HelmRelease goes away, so it destroys the same CRDs and custom resources, and then the Package recreates the HelmRelease and the chart reinstalls. The workloads come back, the custom resources do not. If you have run it before, those custom resources are already gone and have to be recreated from your own manifests or a backup.