remove self-hosted in favor of self-managed (#815)

modules/deploy/partials/high-availability.adoc

@@ -399,7 +399,7 @@ NOTE: With follower fetching enabled, a consumer chooses the closest replica rat
 
 === Multi-AZ example
 
-Redpanda provides an official https://github.com/redpanda-data/deployment-automation[deployment automation] project using Ansible and Terraform to help self-hosted users stand up multi-AZ deployments quickly and efficiently.
+Redpanda provides an official https://github.com/redpanda-data/deployment-automation[deployment automation] project using Ansible and Terraform to help self-managed users stand up multi-AZ deployments quickly and efficiently.
 
 ==== Configure Terraform
 

modules/develop/pages/transactions.adoc

@@ -39,7 +39,7 @@ The two primary use cases for transactions are:
 ifndef::env-cloud[]
 * When running transactional workloads from clients, tune xref:reference:cluster-properties#max_transactions_per_coordinator[`max_transactions_per_coordinator`] to the number of active transactions that you expect your clients to run at any given time (if your client transaction IDs are not reused). The total number of transactions in the cluster at any one time is `max_transactions_per_coordinator * transaction_coordinator_partitions` (default is 50). When the threshold is exceeded, Redpanda terminates old sessions. If an idle producer corresponding to the terminated session wakes up and produces, its batches are rejected with the message `invalid producer epoch` or `invalid_producer_id_mapping`, depending on where it is in the transaction execution phase.
 Be aware that if you keep the default as 50 and your clients create a new ID for every transaction, the total continues to accumulate, which bloats memory.
-* When upgrading a self-hosted deployment, make sure to use maintenance mode with a glossterm:rolling upgrade[].
+* When upgrading a self-managed deployment, make sure to use maintenance mode with a glossterm:rolling upgrade[].
 
 endif::[]
 

modules/manage/pages/schema-reg/schema-reg-api.adoc

@@ -52,7 +52,7 @@ The following examples cover the basic functionality of the Redpanda Schema Regi
 To run the sample commands and code in each example, follow these steps to set up Redpanda and other tools:
 
 ifndef::env-cloud[]
-. You need a running Redpanda cluster. If you don't have one, you can follow the xref:get-started:quick-start.adoc[quickstart] to deploy a self-hosted cluster.
+. You need a running Redpanda cluster. If you don't have one, you can follow the xref:get-started:quick-start.adoc[quickstart] to deploy a self-managed cluster.
 endif::[]
 ifdef::env-cloud[]
 . You need a running Redpanda cluster. If you don't have one, you can xref:get-started:cluster-types/serverless.adoc[create a cluster] using Redpanda Serverless.

modules/upgrade/pages/k-upgrade-kubernetes.adoc

@@ -10,7 +10,7 @@ Upgrading the Kubernetes version in a cluster ensures that your infrastructure i
 
 * A staging environment in which to test the upgrade procedure before performing it in production.
 * A running Redpanda deployment on a Kubernetes cluster.
-* Familiarity with your hosting platform (GKE, EKS, AKS, or self-hosted) and any CLI tools your platform provides, such as `gcloud` or `eksctl`.
+* Familiarity with your hosting platform (GKE, EKS, AKS, or self-managed) and any CLI tools your platform provides, such as `gcloud` or `eksctl`.
 * Confirmation that the new version of Kubernetes is compatible with the version of Redpanda you are using. See the xref:reference:k-redpanda-helm-spec.adoc#requirements[Helm chart requirements].
 * <<Upgrade the Redpanda Helm chart>>.
 
@@ -81,7 +81,7 @@ Before you upgrade a worker node, make sure that it is cordoned to prevent new P
 * https://cloud.google.com/kubernetes-engine/docs/how-to/upgrading-a-cluster[Upgrade on GKE (Google Kubernetes Engine)^]
 * https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html[Upgrade on EKS (Elastic Kubernetes Service)^]
 * https://learn.microsoft.com/en-us/azure/aks/upgrade-cluster?tabs=azure-cli[Upgrade on AKS (Azure Kubernetes Service)^]
-* https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade/[Upgrade on Self-Hosted^]
+* https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade/[Upgrade on Self-Managed^]
 
 After completing the upgrade process, verify the health of your Redpanda deployment and ensure that data has been retained as expected.