fix: update links to documentation

Signed-off-by: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>

Author: gbartolini

content/posts/20240228-maximizing-microservice-databases-with-k8s-postgres-cloudnativepg/index.md

@@ -191,7 +191,7 @@ development.
 As both a co-founder and maintainer of the CloudNativePG project, and a
 longtime enthusiast of both PostgreSQL and Kubernetes, I wholeheartedly
 advocate for this operator. Technically classified as a
-[level 5 Kubernetes Operator](https://cloudnative-pg.io/documentation/current/operator_capability_levels/),
+[level 5 Kubernetes Operator](https://cloudnative-pg.io/docs/1.28/operator_capability_levels/),
 CloudNativePG excels in managing PostgreSQL clusters, seamlessly handling day 0
 through day 2 operations, and is production-ready.
 
@@ -206,12 +206,12 @@ On the technical front, CloudNativePG distinguishes itself by being exclusively
 designed for Kubernetes. It seamlessly extends the Kubernetes controller,
 introducing a custom resource called `Cluster` responsible for managing the
 Postgres cluster's status. This resource relies on a component called the
-[*instance manager*](https://cloudnative-pg.io/documentation/current/instance_manager/)
+[*instance manager*](https://cloudnative-pg.io/docs/1.28/instance_manager/)
 to exert precise control over the underlying PostgreSQL instances.
 
 A notable aspect is the inclusion of failover management within CloudNativePG,
 eliminating the need for external tools like Patroni when providing High Availability.
-The decision to bypass statefulsets and [directly manage PVCs](https://cloudnative-pg.io/documentation/current/controller/)
+The decision to bypass statefulsets and [directly manage PVCs](https://cloudnative-pg.io/docs/1.28/controller/)
 allows for finer control over the Postgres cluster.
 
 CloudNativePG adopts a fully declarative approach, leveraging the Kubernetes
@@ -221,21 +221,21 @@ services, mutual TLS via secrets, affinity control, persistent volumes,
 and more.
 
 Out of the box, CloudNativePG offers observability through endpoints for native
-[Prometheus exporters](https://cloudnative-pg.io/documentation/current/monitoring/),
-as well as [direct log stream in JSON format to stdout](https://cloudnative-pg.io/documentation/current/logging/).
+[Prometheus exporters](https://cloudnative-pg.io/docs/1.28/monitoring/),
+as well as [direct log stream in JSON format to stdout](https://cloudnative-pg.io/docs/1.28/logging/).
 
-Key features encompass [continuous backup](https://cloudnative-pg.io/documentation/current/backup/)
-and [point-in-time recovery](https://cloudnative-pg.io/documentation/current/recovery/),
-[rolling updates](https://cloudnative-pg.io/documentation/current/rolling_update/),
-[fencing](https://cloudnative-pg.io/documentation/current/fencing/),
-[hibernation](https://cloudnative-pg.io/documentation/current/declarative_hibernation/),
-along with the ability to replicate across Kubernetes clusters, also known as [replica clusters](https://cloudnative-pg.io/documentation/current/replica_cluster/).
+Key features encompass [continuous backup](https://cloudnative-pg.io/docs/1.28/backup/)
+and [point-in-time recovery](https://cloudnative-pg.io/docs/1.28/recovery/),
+[rolling updates](https://cloudnative-pg.io/docs/1.28/rolling_update/),
+[fencing](https://cloudnative-pg.io/docs/1.28/fencing/),
+[hibernation](https://cloudnative-pg.io/docs/1.28/declarative_hibernation/),
+along with the ability to replicate across Kubernetes clusters, also known as [replica clusters](https://cloudnative-pg.io/docs/1.28/replica_cluster/).
 
-CloudNativePG features a powerful [`kubectl` plugin known as `cnpg`](https://cloudnative-pg.io/documentation/current/kubectl-plugin/),
+CloudNativePG features a powerful [`kubectl` plugin known as `cnpg`](https://cloudnative-pg.io/docs/1.28/kubectl-plugin/),
 serving as the official command-line interface (CLI) for the product. It is
 compatible with any supported Kubernetes distribution and can be effortlessly
 tested on your laptop using `kind` (Kubernetes in Docker), as outlined in the
-[quickstart](https://cloudnative-pg.io/documentation/current/quickstart/).
+[quickstart](https://cloudnative-pg.io/docs/1.28/quickstart/).
 
 ## The microservice database opportunity
 

content/posts/20240303-recipe-local-setup/index.md

@@ -19,7 +19,7 @@ your future CloudNativePG explorations with a fully open source stack._
 
 <!--more-->
 
-_NOTE: this article has been updated on June 5th, 2025 with the most recent
+_NOTE: this article has been updated on January 4th, 2026 with the most recent
 versions of `kind` and `cloudnative-pg`. You might also be interested in
 the [CNPG Playground project]({{< relref "../20240920-cnpg-playground/index.md">}})
 that was launched in the meantime._
@@ -53,7 +53,7 @@ kind version
 ```
 
 On my laptop, as of the time of the last update, the output is
-`kind v0.29.0 go1.24.3 darwin/amd64`.
+`kind v0.31.0 go1.25.5 darwin/arm64`.
 
 Now, proceed to establish your initial local Kubernetes cluster for
 CloudNativePG with:
@@ -66,7 +66,7 @@ Upon execution, you'll observe the following output:
 
 ```console
 Creating cluster "cnpg" ...
- ✓ Ensuring node image (kindest/node:v1.33.1) 🖼
+ ✓ Ensuring node image (kindest/node:v1.35.0) 🖼
  ✓ Preparing nodes 📦
  ✓ Writing configuration 📜
  ✓ Starting control-plane 🕹️
@@ -103,14 +103,14 @@ Now that our local Kubernetes playground is set up, let's explore the
 installation of CloudNativePG.
 
 To deploy the latest stable version, refer to the
-[CloudNativePG documentation for instructions on installing the operator via Kubernetes manifests](https://cloudnative-pg.io/documentation/current/installation_upgrade/#directly-using-the-operator-manifest).
+[CloudNativePG documentation for instructions on installing the operator via Kubernetes manifests](https://cloudnative-pg.io/docs/1.28/installation_upgrade/#directly-using-the-operator-manifest).
 
-For instance, to install version 1.26.1, the latest available at the time of
+For instance, to install version 1.28.0, the latest available at the time of
 writing, use the following command:
 
 ```sh
 kubectl apply --server-side -f \
-  https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.26/releases/cnpg-1.26.1.yaml
+  https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.28/releases/cnpg-1.28.0.yaml
 ```
 
 This command creates a `Deployment` resource named `cnpg-controller-manager`
@@ -141,13 +141,13 @@ Feel free to explore different versions or dive into the latest developments!
 With CloudNativePG successfully installed in your local cluster, creating your
 initial 3-instance PostgreSQL cluster is a breeze.
 
-Let's utilize the basic
-[cluster-example](https://cloudnative-pg.io/documentation/current/samples/cluster-example.yaml)
+Let's use the basic
+[cluster-example](https://cloudnative-pg.io/docs/assets/files/cluster-example-0a961e59ba2e2313c983c3386be1d7e7.yaml)
 file provided by CloudNativePG for evaluation purposes. The YAML content is
 concise, under 10 lines, and adheres to the *convention over configuration*
 paradigm embraced by CloudNativePG. This default configuration should
 seamlessly work for most use cases, and all available options are detailed in
-the [API reference](https://cloudnative-pg.io/documentation/current/cloudnative-pg.v1/),
+the [API reference](https://cloudnative-pg.io/docs/1.28/cloudnative-pg.v1/),
 giving you the flexibility to override any of them.
 
 Here's a snippet of the YAML file:
@@ -169,7 +169,7 @@ using the `kubectl apply` command:
 
 ```sh
 kubectl apply -f \
-  https://cloudnative-pg.io/documentation/current/samples/cluster-example.yaml
+  https://cloudnative-pg.io/docs/assets/files/cluster-example-0a961e59ba2e2313c983c3386be1d7e7.yaml
 ```
 
 Monitor the progress with `kubectl get pods -w`.
@@ -204,7 +204,7 @@ deployments using the concise `kubectl cnpg` command.
 
 Installation of the plugin offers flexibility through various methods,
 including package installations outlined in the
-[CloudNativePG documentation](https://cloudnative-pg.io/documentation/current/kubectl-plugin/).
+[CloudNativePG documentation](https://cloudnative-pg.io/docs/1.28/kubectl-plugin/).
 
 We strongly endorse the `cnpg` plugin, with one notable advantage being the
 inclusion of the `cnpg status` command.
@@ -220,33 +220,32 @@ This command typically yields output similar to:
 
 ```console
 Cluster Summary
-Name                 default/cluster-example
-System ID:           7512473913904742428
-PostgreSQL Image:    ghcr.io/cloudnative-pg/postgresql:13
-Primary instance:    cluster-example-1
-Primary start time:  2025-06-05 14:35:42 +0000 UTC (uptime 1m27s)
-Status:              Cluster in healthy state
-Instances:           3
-Ready instances:     3
-Size:                112M
-Current Write LSN:   0/5000060 (Timeline: 1 - WAL File: 000000010000000000000005)
-
-Continuous Backup status
-Not configured
+Name                     default/cluster-example
+System ID:               7591231340975534109
+PostgreSQL Image:        ghcr.io/cloudnative-pg/postgresql:18.1-system-trixie
+Primary instance:        cluster-example-1
+Primary promotion time:  2026-01-03 20:14:44 +0000 UTC (1m14s)
+Status:                  Cluster in healthy state
+Instances:               3
+Ready instances:         3
+Size:                    128M
+Current Write LSN:       0/6000060 (Timeline: 1 - WAL File: 000000010000000000000006)
+
+Continuous Backup not configured
 
 Streaming Replication status
 Replication Slots Enabled
 Name               Sent LSN   Write LSN  Flush LSN  Replay LSN  Write Lag  Flush Lag  Replay Lag  State      Sync State  Sync Priority  Replication Slot
 ----               --------   ---------  ---------  ----------  ---------  ---------  ----------  -----      ----------  -------------  ----------------
-cluster-example-2  0/5000060  0/5000060  0/5000060  0/5000060   00:00:00   00:00:00   00:00:00    streaming  async       0              active
-cluster-example-3  0/5000060  0/5000060  0/5000060  0/5000060   00:00:00   00:00:00   00:00:00    streaming  async       0              active
+cluster-example-2  0/6000060  0/6000060  0/6000060  0/6000060   00:00:00   00:00:00   00:00:00    streaming  async       0              active
+cluster-example-3  0/6000060  0/6000060  0/6000060  0/6000060   00:00:00   00:00:00   00:00:00    streaming  async       0              active
 
 Instances status
 Name               Current LSN  Replication role  Status  QoS         Manager Version  Node
 ----               -----------  ----------------  ------  ---         ---------------  ----
-cluster-example-1  0/5000060    Primary           OK      BestEffort  1.26.1           cnpg-control-plane
-cluster-example-2  0/5000060    Standby (async)   OK      BestEffort  1.26.1           cnpg-control-plane
-cluster-example-3  0/5000060    Standby (async)   OK      BestEffort  1.26.1           cnpg-control-plane
+cluster-example-1  0/6000060    Primary           OK      BestEffort  1.28.0           cnpg-control-plane
+cluster-example-2  0/6000060    Standby (async)   OK      BestEffort  1.28.0           cnpg-control-plane
+cluster-example-3  0/6000060    Standby (async)   OK      BestEffort  1.28.0           cnpg-control-plane
 ```
 
 This tool becomes indispensable as it provides essential insights into your

content/posts/20240307-recipe-inspection/index.md

@@ -53,7 +53,7 @@ cnpg-default-monitoring   1      14h
 
 Focus on the `cnpg-default-monitoring` ConfigMap, which CloudNativePG installs by
 default. This ConfigMap contains built-in metrics for the [embedded Prometheus
-exporter](https://cloudnative-pg.io/documentation/current/monitoring/#user-defined-metrics).
+exporter](https://cloudnative-pg.io/docs/1.28/monitoring/#user-defined-metrics).
 Inspect its content using:
 
 ```sh
@@ -85,7 +85,7 @@ Pay attention to the `monitoring` section in the returned JSON object:
 
 For more details on the observability framework available in CloudNativePG,
 including creating custom metrics, refer to the
-["Monitoring"](https://cloudnative-pg.io/documentation/current/monitoring/)
+["Monitoring"](https://cloudnative-pg.io/docs/1.28/monitoring/)
 section in the documentation.
 
 ## Default Secrets
@@ -426,7 +426,7 @@ single database within a cluster. Rather than consolidating multiple databases
 within a single Postgres cluster, the recommendation is to create distinct
 clusters, each dedicated to a [microservice database]({{< relref "../20240228-maximizing-microservice-databases-with-k8s-postgres-cloudnativepg/index.md">}}).
 Detailed insights into this strategy are available in our
-[FAQ section](https://cloudnative-pg.io/documentation/current/faq/).
+[FAQ section](https://cloudnative-pg.io/docs/1.28/faq/).
 
 In this framework, the specifics of the database, such as its name and the
 owning user (`app`), become less significant. The focal point shifts to the

content/posts/20240312-recipe-superuser/index.md

@@ -60,7 +60,7 @@ Upon inspection, it's evident that the default setting for
 CloudNativePG in line with the PoLA philosophy. This default configuration
 essentially restricts network connections via the `postgres` user, a user
 crucial for the operator to coordinate and manage a PostgreSQL server through
-the [instance manager](https://cloudnative-pg.io/documentation/current/instance_manager/).
+the [instance manager](https://cloudnative-pg.io/docs/1.28/instance_manager/).
 
 To gain insight into the configuration of PostgreSQL Host-Based Authentication,
 we can execute the following query:
@@ -95,7 +95,7 @@ The final default rule stipulates that, with a password in place, you can
 connect with any user from anywhere to any database, using both TLS and non-TLS
 connections. If this default configuration isn't suitable, you have the
 flexibility to enhance security by adding a more rigorous rule in the `pg_hba`
-file. For additional details, refer to ["The `pg_hba` section"](https://cloudnative-pg.io/documentation/current/postgresql_conf/#the-pg_hba-section).
+file. For additional details, refer to ["The `pg_hba` section"](https://cloudnative-pg.io/docs/1.28/postgresql_conf/#the-pg_hba-section).
 
 An added security benefit is that the `postgres` user within the database has a
 password set to `NULL`, effectively thwarting any unauthorized authentication

content/posts/20240322-pgadmin4/index.md

@@ -129,7 +129,7 @@ Leveraging the `--mode desktop` option provided a frictionless experience,
 bypassing authentication for swift experimentation.
 
 For further insights and detailed instructions, refer to the [CloudNativePG
-documentation](https://cloudnative-pg.io/documentation/current/kubectl-plugin/#using-pgadmin4-for-evaluationdemonstration-purposes-only)
+documentation](https://cloudnative-pg.io/docs/1.28/kubectl-plugin/#using-pgadmin4-for-evaluationdemonstration-purposes-only)
 on the `cnpg` plugin.
 
 As usual, if you found this article informative, feel free to share it within

content/posts/20240327-zero-cutover-migrations/index.md

@@ -52,11 +52,11 @@ The most notable ones are that PostgreSQL doesn’t replicate:
 Considering that you generally delimit the migration duration in time, with
 exact start and finish dates, the only blocker is the last one. The good news
 is that CloudNativePG now covers the first two limitations entirely with the
-help of the [`cnpg` plugin](https://cloudnative-pg.io/documentation/current/kubectl-plugin/),
+help of the [`cnpg` plugin](https://cloudnative-pg.io/docs/1.28/kubectl-plugin/),
 as I will show you in this article.
 
 However, this approach will not work if you use large objects and you must
-perform an [offline migration](https://cloudnative-pg.io/documentation/current/database_import/).
+perform an [offline migration](https://cloudnative-pg.io/docs/1.28/database_import/).
 The rest of this article assumes that limitations don’t apply to your case.
 
 ## About near-zero downtime migrations
@@ -210,7 +210,7 @@ going to do now is create a new CloudNativePG cluster in which we:
 - Define an external cluster called `rds` pointing to our PostgreSQL database
   in RDS using the `postgres` user
 - Take advantage of the `schemaOnly` option of the
-  [microservice database import capability](https://cloudnative-pg.io/documentation/current/database_import/#the-microservice-type)
+  [microservice database import capability](https://cloudnative-pg.io/docs/1.28/database_import/#the-microservice-type)
 
 First, create the `rds-superuser` secret for the credentials of the `postgres`
 user:

content/posts/20240408-volume-scaling-1/index.md

@@ -52,8 +52,8 @@ Start by defining your business goals: Recovery Point Objective (RPO), Recovery
 Time Objective (RTO), and the number of transactions per second (TPS) that you
 require. Then benchmark PostgreSQL, and only if the results are not good enough
 proceed with an active/active distributed solution. Benchmark the
-[storage with `fio`](https://cloudnative-pg.io/documentation/current/benchmarking/#fio)  and
-the [database using `pgbench`](https://cloudnative-pg.io/documentation/current/benchmarking/#pgbench)
+[storage with `fio`](https://cloudnative-pg.io/docs/1.28/benchmarking/#fio)  and
+the [database using `pgbench`](https://cloudnative-pg.io/docs/1.28/benchmarking/#pgbench)
 (either with the built-in OLTP-like workload or by writing your custom
 queries).
 
@@ -67,7 +67,7 @@ directly instead of relying on a `Statefulset` resource like most operators
 that work with data (another one that followed our approach is
 [Strimzi for Kafka](https://github.com/strimzi/strimzi-kafka-operator/blob/main/CHANGELOG.md#0350)).
 If you are interested, we explain the reasons behind this choice on the
-[“Pod Controller” page from the CloudNativePG documentation](https://cloudnative-pg.io/documentation/current/controller/).
+[“Pod Controller” page from the CloudNativePG documentation](https://cloudnative-pg.io/docs/1.28/controller/).
 
 Every CloudNativePG instance necessitates a mandatory volume for the PostgreSQL
 data, aka `PGDATA`, meticulously configured within the `storage` stanza.
@@ -123,7 +123,7 @@ Internally, CloudNativePG manage the symbolic link to ensure that the
 `pg_wal` directory seamlessly points to the appropriate directory within the
 WAL volume. In the event of adding a volume for WAL files later on,
 CloudNativePG orchestrates a smooth
-[rolling update](https://cloudnative-pg.io/documentation/current/rolling_update/#automated-updates-unsupervised)
+[rolling update](https://cloudnative-pg.io/docs/1.28/rolling_update/#automated-updates-unsupervised)
 process. This involves halting replicas one at a time, transferring WAL files
 to the new volume, and updating symbolic links. The process is further refined
 by the `primaryUpdateMethod` option, which dictates whether the primary