diff --git a/modules/ROOT/pages/kubernetes/gke.adoc b/modules/ROOT/pages/kubernetes/gke.adoc
index b1bad498a..2dd456af8 100644
--- a/modules/ROOT/pages/kubernetes/gke.adoc
+++ b/modules/ROOT/pages/kubernetes/gke.adoc
@@ -3,6 +3,6 @@
 
 https://cloud.google.com/kubernetes-engine[https://cloud.google.com/kubernetes-engine{external-link-icon}^]
 
-Autopilot clusters are not suported, as the xref:secret-operator:index.adoc[secret-operator] requires special privileges that are not granted in Autopilot clusters.
+Autopilot clusters are not supported, as the xref:secret-operator:index.adoc[secret-operator] requires special privileges that are not granted in Autopilot clusters.
 
 Other than that no special steps are needed.
diff --git a/modules/ROOT/pages/release-guide.adoc b/modules/ROOT/pages/release-guide.adoc
index 12baf3696..57bd94cdf 100644
--- a/modules/ROOT/pages/release-guide.adoc
+++ b/modules/ROOT/pages/release-guide.adoc
@@ -1,7 +1,7 @@
 :description: Work-in-progress internal guide with the git and cargo steps to cut a release and bump the next development version.
 
 
-(this is work in progress that is why it's not explicitely linked in nav.doc)
+(this is work in progress that is why it's not explicitly linked in nav.doc)
 
 Prerequisites:
 
diff --git a/modules/ROOT/partials/release-notes/release-22.9.adoc b/modules/ROOT/partials/release-notes/release-22.9.adoc
index 8605f027d..a07e485a4 100644
--- a/modules/ROOT/partials/release-notes/release-22.9.adoc
+++ b/modules/ROOT/partials/release-notes/release-22.9.adoc
@@ -12,7 +12,7 @@ The following new major platform features were added:
 
 ===== OpenShift compatibility
 
-We have made continued progress towards OpenShift compability, and the following operators can now be previewed on OpenShift.
+We have made continued progress towards OpenShift compatibility, and the following operators can now be previewed on OpenShift.
 Further improvements are expected in future releases, but no stability or compatibility guarantees are currently made for OpenShift clusters.
 
 * https://github.com/stackabletech/airflow-operator/pull/127[Apache Airflow]
diff --git a/modules/ROOT/partials/release-notes/release-24.3.adoc b/modules/ROOT/partials/release-notes/release-24.3.adoc
index ac9e8a5cb..37dfe3b7e 100644
--- a/modules/ROOT/partials/release-notes/release-24.3.adoc
+++ b/modules/ROOT/partials/release-notes/release-24.3.adoc
@@ -321,7 +321,7 @@ The `spec.version` field has been removed.
 
 The `spec.mode` field is now required and must be set to `cluster`.
 
-The `spec.mainClass` field is now required and must point to a location on ths file system or S3 where the main class is located.
+The `spec.mainClass` field is now required and must point to a location on the file system or S3 where the main class is located.
 ====
 
 * https://github.com/stackabletech/spark-k8s-operator/pull/355[Remove usage of `userClassPathFirst` properties]
diff --git a/modules/ROOT/partials/release-notes/release-24.7.adoc b/modules/ROOT/partials/release-notes/release-24.7.adoc
index a74e1479c..e7686dc89 100644
--- a/modules/ROOT/partials/release-notes/release-24.7.adoc
+++ b/modules/ROOT/partials/release-notes/release-24.7.adoc
@@ -259,7 +259,7 @@ Use "stackablectl release list" to list available releases.
 Afterwards you will need to upgrade the CustomResourceDefinitions (CRDs) installed by the Stackable Platform.
 The reason for this is that helm will uninstall the operators but not the CRDs. This can be done using `kubectl replace`.
 
-NOTE: The cluster name for the hello-world operator has been changed in this release so the CRD cannot be patched in-place. For this reason in the snipets below the CRD for this operator will be subject to a `delete` command (plus an `apply` as part of the operator rollout in the new release) instead of a `replace`.
+NOTE: The cluster name for the hello-world operator has been changed in this release so the CRD cannot be patched in-place. For this reason in the snippets below the CRD for this operator will be subject to a `delete` command (plus an `apply` as part of the operator rollout in the new release) instead of a `replace`.
 
 [source]
 ----
@@ -406,5 +406,5 @@ spec:
 IMPORTANT: Do not override this property for the 1.27 cluster version.
 
 This is necessary because the 2.x versions do not support the XML format for flow definitions anymore.
-Support for the JSON format has been addded in version 1.16 and both formats have been maintained up to (excluding) version 2.0.
+Support for the JSON format has been added in version 1.16 and both formats have been maintained up to (excluding) version 2.0.
 The next SDP release 24.11 will automatically take care of this step for you.
diff --git a/modules/compliance/pages/licenses.adoc b/modules/compliance/pages/licenses.adoc
index aa643f67b..ea2f7050f 100644
--- a/modules/compliance/pages/licenses.adoc
+++ b/modules/compliance/pages/licenses.adoc
@@ -35,4 +35,4 @@ https://github.com/stackabletech/stackablectl/blob/main/LICENSE[License{external
 https://github.com/stackabletech/docker-images/blob/main/LICENSE[License{external-link-icon}^] for the product Docker images.
 
 The Docker images are built on the https://catalog.redhat.com/software/containers/ubi9-minimal/61832888c0d15aff4912fe0d[Red Hat ubi9-minimal base image{external-link-icon}^].
-It is https://www.redhat.com/licenses/EULA_Red_Hat_Universal_Base_Image_English_20190422.pdf[licensed seperately{external-link-icon}^].
+It is https://www.redhat.com/licenses/EULA_Red_Hat_Universal_Base_Image_English_20190422.pdf[licensed separately{external-link-icon}^].
diff --git a/modules/concepts/pages/artifact-registries/container-images.adoc b/modules/concepts/pages/artifact-registries/container-images.adoc
index b8da20fb4..360696b70 100644
--- a/modules/concepts/pages/artifact-registries/container-images.adoc
+++ b/modules/concepts/pages/artifact-registries/container-images.adoc
@@ -9,7 +9,7 @@ The core artifacts of the Stackable Data Platform are container images of Kubern
 
 == Images overview
 
-Every operator is packaged into its own image and every product is also packaged into its own, seperate image.
+Every operator is packaged into its own image and every product is also packaged into its own, separate image.
 Products that require multiple different processes to run, such as a coordinator and a worker, still only run off of one image;
 usually these products also only provide a single artifact that is used to run all processes.
 
diff --git a/modules/concepts/pages/index.adoc b/modules/concepts/pages/index.adoc
index 7a42a8c38..ca45a8028 100644
--- a/modules/concepts/pages/index.adoc
+++ b/modules/concepts/pages/index.adoc
@@ -3,7 +3,7 @@
 
 == Overview
 
-The xref:overview.adoc[Platform overview] is a good starting point to understand the Stackable Data Platform covering the overall architecture, deployement and configuration.
+The xref:overview.adoc[Platform overview] is a good starting point to understand the Stackable Data Platform covering the overall architecture, deployment and configuration.
 
 == General configuration mechanisms
 
@@ -19,8 +19,8 @@ Learn about how to access xref:experimental-arm64-support[ARM64-support].
 == Connectivity
 
 Many Platform components depend on other components or expose functionality that you can connect to.
-This connectivity is achived with xref:service-discovery.adoc[service discovery ConfigMaps].
-To access your Stackable operated products from outside the Kuberenetes cluster learn more about xref:service-exposition.adoc[].
+This connectivity is achieved with xref:service-discovery.adoc[service discovery ConfigMaps].
+To access your Stackable operated products from outside the Kubernetes cluster learn more about xref:service-exposition.adoc[].
 
 == Security
 
diff --git a/modules/concepts/pages/overrides.adoc b/modules/concepts/pages/overrides.adoc
index dd0adb3d2..06e65301e 100644
--- a/modules/concepts/pages/overrides.adoc
+++ b/modules/concepts/pages/overrides.adoc
@@ -163,7 +163,7 @@ All override property values must be strings.
 
 For a role or role group, at the same level of `config`, you can specify `podOverrides` for any of the attributes you can configure on a Pod.
 Every Stacklet contains one or more StatefulSets, DaemonSets, or Deployments, which in turn contain a Pod template that is used by Kubernetes to create the Pods that make up the Stacklet.
-The `podOverrides` allow you to specify a fragment of a Pod template that is then overlayed over the one created by the operator.
+The `podOverrides` allow you to specify a fragment of a Pod template that is then overlaid over the one created by the operator.
 
 An example for an HDFS cluster looks as follows:
 
diff --git a/modules/concepts/pages/s3.adoc b/modules/concepts/pages/s3.adoc
index a990934b4..96a95130f 100644
--- a/modules/concepts/pages/s3.adoc
+++ b/modules/concepts/pages/s3.adoc
@@ -119,7 +119,7 @@ spec:
 ==== Stand-alone resources
 
 To reuse S3Buckets across different applications, they can be defined as stand-alone resources. In a similar fashion, S3Connections can also be defined as stand-alone resources.
-In the example below, ony bucket is used by a DruidCluster and a second bucket is used by both a TrinoCluster and a SparkCluster. Both buckets reference the same S3Connection.
+In the example below, one bucket is used by a DruidCluster and a second bucket is used by both a TrinoCluster and a SparkCluster. Both buckets reference the same S3Connection.
 
 image::s3-fully-separated.drawio.svg[One S3Connection is referenced by two different S3Buckets. The first Bucket is referenced by a DruidCluster and the second bucket is referenced by a SparkCluster and TrinoCluster. No object is inlined.]
 
diff --git a/modules/concepts/pages/service-discovery.adoc b/modules/concepts/pages/service-discovery.adoc
index bb471dc52..08f1833c9 100644
--- a/modules/concepts/pages/service-discovery.adoc
+++ b/modules/concepts/pages/service-discovery.adoc
@@ -88,7 +88,7 @@ The ConfigMap should look something like this:
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: my-already-exisiting-hdfs
+  name: my-already-existing-hdfs
 data:
   core-site.xml: |
     <here should be your core-site.xml file contents>
@@ -105,7 +105,7 @@ kind: HbaseCluster
 metadata:
   name: simple-hbase
 spec:
-  hdfsConfigMapName: my-already-exisiting-hdfs
+  hdfsConfigMapName: my-already-existing-hdfs
   ...
 ----
 
diff --git a/modules/contributor/pages/adr/ADR001-choose_project_language.adoc b/modules/contributor/pages/adr/ADR001-choose_project_language.adoc
index ec5b3b166..b8fec53e5 100644
--- a/modules/contributor/pages/adr/ADR001-choose_project_language.adoc
+++ b/modules/contributor/pages/adr/ADR001-choose_project_language.adoc
@@ -29,7 +29,7 @@ As currently all participants are German, the first choice would be German, howe
 
 == Decision Outcome
 
-Chosen option: "English", because the desire to create an active community with participants from all over the world is much more important than the minor barrier that this decision might create initally.
+Chosen option: "English", because the desire to create an active community with participants from all over the world is much more important than the minor barrier that this decision might create initially.
 
 === Positive Consequences
 
@@ -51,4 +51,4 @@ Chosen option: "English", because the desire to create an active community with
 === English
 
 * Good, because it allows growing an international community
-* Bad, would initially add a small language barrier that is not strictly speaking necessary
\ No newline at end of file
+* Bad, would initially add a small language barrier that is not strictly speaking necessary
diff --git a/modules/contributor/pages/adr/ADR003-choose_review_mechanism.adoc b/modules/contributor/pages/adr/ADR003-choose_review_mechanism.adoc
index d7fd3656e..0ba3d1f22 100644
--- a/modules/contributor/pages/adr/ADR003-choose_review_mechanism.adoc
+++ b/modules/contributor/pages/adr/ADR003-choose_review_mechanism.adoc
@@ -50,7 +50,7 @@ Chosen option: "Review then commit", because it meets both decision drivers.
 
 === Review then commit
 
-This option requires a full review and approval of all changes before they are commited to the development branch.
+This option requires a full review and approval of all changes before they are committed to the development branch.
 Who and how many people need to approve a change will need to be defined in the contribution guidelines at a later time.
 
 * Good, because there is no need to keep track of unreviewed commits
diff --git a/modules/contributor/pages/adr/ADR012-authn_token_management.adoc b/modules/contributor/pages/adr/ADR012-authn_token_management.adoc
index be09813bb..6e14d52bc 100644
--- a/modules/contributor/pages/adr/ADR012-authn_token_management.adoc
+++ b/modules/contributor/pages/adr/ADR012-authn_token_management.adoc
@@ -73,6 +73,6 @@ are injected into pods using a custom CSI provider or init container.
 * Good, because it can enforce policy for generated identities (for example: tying TLS certificate to Pod or Node identity)
 * Good, because it can pick pregenerated tokens based on Pod/Node identity
 * Good, because it can have a cluster-global policy for picking between backends
-* Good, because it can accomodate to whatever authn methods we end up supporting
+* Good, because it can accommodate to whatever authn methods we end up supporting
 * Bad, because it's another bespoke thing to maintain and develop
 * Bad, because none of us are experienced with writing CSI providers
diff --git a/modules/contributor/pages/adr/ADR015-using_values_from_configmaps.adoc b/modules/contributor/pages/adr/ADR015-using_values_from_configmaps.adoc
index f5f3b3d3a..ff96c07a3 100644
--- a/modules/contributor/pages/adr/ADR015-using_values_from_configmaps.adoc
+++ b/modules/contributor/pages/adr/ADR015-using_values_from_configmaps.adoc
@@ -17,7 +17,7 @@ Technical Story: https://github.com/stackabletech/issues/issues/208[#208]
 == Context and Problem Statement
 
 One of the main focus areas of Stackable is making components of the stack work together well.
-This requires a high degree of composability where one component refers to another compenent in its definition.
+This requires a high degree of composability where one component refers to another component in its definition.
 While this is a simple concept in principle it requires that operators obtain information about the object that is referred to and inject this information into the configuration of the object that refers to it.
 An example for this is a NiFi cluster definition referring to a ZooKeeper cluster definition via a znode name:
 
@@ -74,7 +74,7 @@ The target config would then be written either to a ConfigMap or a Secret, depen
 * Bad, because it would allow referencing ConfigMaps and Secrets in different namespaces, which would dilute namespace separation
 * Bad, because it makes debugging startup issues of products much harder, as pods will simply not appear if required ConfigMaps are missing, effectively bypassing well established k8s patterns (like a pod missing a mount not starting and writing events about why it is not starting)
 * Bad, because the dependencies between pods and configmaps / secrets become very complex and hard to debug as they are not modelled in any way as k8s dependencies (mounts)
-* Bad, because setting up the correct watches in the operator becomes very complex, with a likelyhood of inadvertently forgetting to add a new watch that becomes necessary as CRDs evolve
+* Bad, because setting up the correct watches in the operator becomes very complex, with a likelihood of inadvertently forgetting to add a new watch that becomes necessary as CRDs evolve
 * Bad, because it potentially propagates sensitive values to multiple places by copying secret content to additional places
 * Bad, because the Operator is seeing the Secrets. This is not a problem _now_, but if we could avoid it that would be better
 
@@ -86,4 +86,4 @@ Accessing the content of these mounted objects would then need to be done in an
 
 * Good, because mounting the ConfigMap/Secret directly into the pod allows the restart controller to automatically restart a Pod if a mounted object changes. Otherwise, changes would not be propagated or the Operator would have to watch the ConfigMap/Secret for changes itself. The watching/restarting is done once by Kubernetes + the restart controller and makes our Operators simpler
 * Bad, because the mounted properties cannot be validated by the Operator. Although Kubernetes at least verifies that all the properties that should be mounted exist
-* Bad, because it is more difficult to see which config is actually used to run the product, as the actual config is only finally assembled inside of the container
\ No newline at end of file
+* Bad, because it is more difficult to see which config is actually used to run the product, as the actual config is only finally assembled inside of the container
diff --git a/modules/contributor/pages/adr/ADR022-spark-history-server.adoc b/modules/contributor/pages/adr/ADR022-spark-history-server.adoc
index afb4f6eac..64adcb6ac 100644
--- a/modules/contributor/pages/adr/ADR022-spark-history-server.adoc
+++ b/modules/contributor/pages/adr/ADR022-spark-history-server.adoc
@@ -138,7 +138,7 @@ spec:
 ...
 ----
 
-In the example above, the application will log its events to the bucket specifed in `logFileDirectory`.
+In the example above, the application will log its events to the bucket specified in `logFileDirectory`.
 In addition, the application processes data from a S3 bucket configured within the `s3connection` section of the specification.
 
 The operator will read the `s3Connection` and set up the `fs.s3a.aws.credentials.provider` and co (endpoint, accesskey, secretkey, tls, path-style access - basically all attributes of S3Connection) settings.
@@ -149,6 +149,6 @@ NOTE: the credentials used by the `HistoryServer` *do not* have to be shared wit
 
 === Advantages
 
-* Fully flexible solution, which allows the logDir to be on a different S3 ednpoint than the data.
+* Fully flexible solution, which allows the logDir to be on a different S3 endpoint than the data.
 * If they are on the same endpojnt, a single S3BucketDef can be shared between HistoryServer and SparkApplication for ease of use.
 * HDFS and/or other distributed filesystems can be added non-breaking later on
diff --git a/modules/contributor/pages/adr/ADR024-out-of-cluster_access.adoc b/modules/contributor/pages/adr/ADR024-out-of-cluster_access.adoc
index ef1b3f1d1..8d0852e63 100644
--- a/modules/contributor/pages/adr/ADR024-out-of-cluster_access.adoc
+++ b/modules/contributor/pages/adr/ADR024-out-of-cluster_access.adoc
@@ -15,7 +15,7 @@ Technical Story: https://github.com/stackabletech/listener-operator/pull/1
 == Context and Problem Statement
 // Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.
 
-Eventually, the products we host in Kubernetes will need to be accessed from outside of the cluster, as this is where the client is. Our current solution for this is NodePort services. They are a simple and common solution for on-premise clusters, where nodes are reachable hosts in the local network. To get traffic into a Kubernetes cluster that runs in a public cloud, NodePorts do not work; instead LoadBalancers are the preferred solution. 
+Eventually, the products we host in Kubernetes will need to be accessed from outside of the cluster, as this is where the client is. Our current solution for this is NodePort services. They are a simple and common solution for on-premise clusters, where nodes are reachable hosts in the local network. To get traffic into a Kubernetes cluster that runs in a public cloud, NodePorts do not work; instead LoadBalancers are the preferred solution.
 
 While a Pods name is stable across restarts and rescheduling, the IP of the NodePort can change if a Pod is rescheduled to a different node. This means that external addresses from simple NodePorts are not stable. LoadBalancers are not tied to nodes, but they are often not available in on-prem clusters.
 At the moment we deploy NodePort Services per RoleGroup; clients cannot connect to an individual Pod in a RoleGroup.
@@ -26,7 +26,7 @@ Additionally, Pods currently do not know the address under which they are reacha
 Problems:
 
 * **Unstable addresses** - Clients need stable addresses to connect to, but Kubernetes can move pods around. While the discovery ConfigMap is updated, it's not feasible to ask the client to pull the new info from there every time, clients will want to use static config files with static addresses to connect to.
-* **Replicas not addressable** - In our current setup, there's no way to connect to a specific replica in a StatefulSet or Deployement - which is necessary for cases like the data nodes of HDFS.
+* **Replicas not addressable** - In our current setup, there's no way to connect to a specific replica in a StatefulSet or Deployment - which is necessary for cases like the data nodes of HDFS.
 * **Pods don't know their outside address** - The hostname and IP that the pods know about themselves is from _inside_ the cluster. The IP only works inside the overlay network. This means ProductCluster processes cannot link to other nodes of the cluster.
 
 == Decision Drivers
@@ -72,7 +72,7 @@ spec:
   serviceAnnotations:
     networking.gke.io/load-balancer-type: Internal
 
-ListenerClasses allow for various different ways of getting outside traffic into the cluster. A dedicated operator seperates the deployment of this out - the product operators need to only request the listeners.
+ListenerClasses allow for various different ways of getting outside traffic into the cluster. A dedicated operator separates the deployment of this out - the product operators need to only request the listeners.
 
 Requests for Listeners are made through annotated volume claim templates:
 
@@ -188,4 +188,4 @@ With ARP, the LoadBalancers appear as "real" IP addresses in the same subnet as
 
 === Calico
 
-link:https://www.tigera.io/project-calico/[Calico] requires BGP, another component that we cannot make required for customer setups.
\ No newline at end of file
+link:https://www.tigera.io/project-calico/[Calico] requires BGP, another component that we cannot make required for customer setups.
diff --git a/modules/contributor/pages/adr/ADR026-affinities.adoc b/modules/contributor/pages/adr/ADR026-affinities.adoc
index be13d4f22..0f00d2caa 100644
--- a/modules/contributor/pages/adr/ADR026-affinities.adoc
+++ b/modules/contributor/pages/adr/ADR026-affinities.adoc
@@ -111,7 +111,7 @@ spec:
 
 ==== Pros
 
-* Enables definining only one of the two structs an the CRD
+* Enables defining only one of the two structs an the CRD
 
 ==== Cons
 
diff --git a/modules/contributor/pages/adr/ADR029-database-connection.adoc b/modules/contributor/pages/adr/ADR029-database-connection.adoc
index d82f51bfc..deccdaa81 100644
--- a/modules/contributor/pages/adr/ADR029-database-connection.adoc
+++ b/modules/contributor/pages/adr/ADR029-database-connection.adoc
@@ -141,13 +141,13 @@ spec:
   database:
     postgresql:
       host: druid-postgresql # mandatory
-      port: 5432 # defaults to some port number - depending on wether tls is enabled
+      port: 5432 # defaults to some port number - depending on whether tls is enabled
       schema: druid # defaults to druid
       credentials: druid-postgresql-credentials # mandatory. key username and password
       parameters: {} # optional
     redis:
       host: airflow-redis-master # mandatory
-      port: 6379 # defaults to some port number - depending on wether tls is enabled
+      port: 6379 # defaults to some port number - depending on whether tls is enabled
       schema: druid # defaults to druid
       credentials: airflow-redis-credentials # optional. key password
       parameters: {} # optional
diff --git a/modules/contributor/pages/adr/ADR032-oidc-support.adoc b/modules/contributor/pages/adr/ADR032-oidc-support.adoc
index 2af59b652..8b235c838 100644
--- a/modules/contributor/pages/adr/ADR032-oidc-support.adoc
+++ b/modules/contributor/pages/adr/ADR032-oidc-support.adoc
@@ -35,7 +35,7 @@ Useful information to consider in the decision.
 === OIDC clients and product-client-mappings
 
 To configure a product to use OIDC, it needs information about where to find the OIDC provider (typically the URL of the discovery endpoint), as well as client credentials to authenticate with the provider.
-The connection information is generic and shared between all clients, but the crendentials are product specific.
+The connection information is generic and shared between all clients, but the credentials are product specific.
 
 It is best practice to have one client per connecting product.
 This allows the user to define exactly from which hosts the client can be used, as well as valid redirect URLs.
@@ -85,7 +85,7 @@ Does not support reading an OIDC discovery URL but requires:
 
 * separate API base URL, auth URL, token URL
 * the `email`, `profile` and `openid` scopes
-* that the auth and token URL are supplied at the `.well-known` endoint, but the base URL is not
+* that the auth and token URL are supplied at the `.well-known` endpoint, but the base URL is not
 
 We could opt to implement proper OIDC support using fab-oidc. This however needs maintenance work from us.
 
diff --git a/modules/contributor/pages/adr/ADR034-foundation-webhooks-deployment.adoc b/modules/contributor/pages/adr/ADR034-foundation-webhooks-deployment.adoc
index cef5e8393..a93f3aaa9 100644
--- a/modules/contributor/pages/adr/ADR034-foundation-webhooks-deployment.adoc
+++ b/modules/contributor/pages/adr/ADR034-foundation-webhooks-deployment.adoc
@@ -19,7 +19,7 @@ Technical Story: https://github.com/stackabletech/issues/issues/361
 == Context
 
 We must version our CustomResourceDefinitions (CRDs).
-This step allows us to move away from unstable alpha or beta versions (like `v1alhpa1`) to stable versions like `v1` or `v2`.
+This step allows us to move away from unstable alpha or beta versions (like `v1alpha1`) to stable versions like `v1` or `v2`.
 These versions provide stable interfaces which customers can rely on.
 Since we cannot avoid having breaking changes in the future (which require a bump in the respective CRD version), we have to supply conversion webhooks that take care of converting older versions to the current storage version.
 
@@ -59,7 +59,7 @@ Setting:
 Downgrade procedure:
 
 * Step 1: request the cluster definition in "v1" and apply it again
-* Step 2: donwgrade operator and webhook deployments
+* Step 2: downgrade operator and webhook deployments
 
 [NOTE]
 ====
diff --git a/modules/contributor/pages/adr/deprecated/ADR006-choose_orchestrator_storage_backend.adoc b/modules/contributor/pages/adr/deprecated/ADR006-choose_orchestrator_storage_backend.adoc
index 9a9714604..aced646dc 100644
--- a/modules/contributor/pages/adr/deprecated/ADR006-choose_orchestrator_storage_backend.adoc
+++ b/modules/contributor/pages/adr/deprecated/ADR006-choose_orchestrator_storage_backend.adoc
@@ -12,7 +12,7 @@ Technical Story:
 This ADR has been superseded by ADR7, which decided to stop development on the orchestrator for now and use the kube-apiserver instead.
 As the kube-apiserver exclusively supports etcd as backend provider there is no decision to document at this time.
 
-This ADR reflects the current state of dicussion at the time of approving ADR7 and should not be considered complete!
+This ADR reflects the current state of discussion at the time of approving ADR7 and should not be considered complete!
 
 == Context and Problem Statement
 
@@ -49,7 +49,7 @@ Our usage of this storage will most probably be extremely simple, even if a SQL
 https://etcd.io/
 
 * Good, because etcd is used by Kubernetes
-** Likelyhood that it is already deployed
+** Likelihood that it is already deployed
 ** Expertise with etcd by Kubernetes admins can be reused
 * Good, because it offers watch functionality
 * Good, because it offers consensus mechanisms
@@ -60,7 +60,7 @@ https://etcd.io/
 
 https://zookeeper.apache.org/
 
-* Good, because it is well established and unterstood
+* Good, because it is well established and understood
 * Good, because it offers watch functionality
 * Good, because it offers consensus mechanisms
 * Bad, because it offers no real benefit over etcd
diff --git a/modules/contributor/pages/adr/drafts/ADRx-choose_authorization_engine.adoc b/modules/contributor/pages/adr/drafts/ADRx-choose_authorization_engine.adoc
index 6acbc1331..748bbf274 100644
--- a/modules/contributor/pages/adr/drafts/ADRx-choose_authorization_engine.adoc
+++ b/modules/contributor/pages/adr/drafts/ADRx-choose_authorization_engine.adoc
@@ -26,7 +26,7 @@ This engine should have the ability to express universal access controls, as it
 * ...
 
 Depending on which option is chosen, there is a second, implicit, decision that is taken as part of this record: whether or not to include an identity provider.
-Keycloak and Ranger both offer user management on top of authoriztion, whereas Open Policy Agent is purely an authorization engine.
+Keycloak and Ranger both offer user management on top of authorization, whereas Open Policy Agent is purely an authorization engine.
 
 I'm not sure if we need to split this decision out into a separate ADR, but I suspect that it may make sense.
 If Open Policy Agent is chosen as part of this ADR, at some point we need to decide whether we also need an identity provider and if so, which one we should pick.
@@ -100,4 +100,4 @@ It allows integration with LDAP and AD, offers authorization, a clustered mode f
 == Links
 
 * [Link type] [Link to ADR] <!-- example: Refined by [ADR-0005](0005-example.md) -->
-* … <!-- numbers of links can vary -->
\ No newline at end of file
+* … <!-- numbers of links can vary -->
diff --git a/modules/contributor/pages/code-style-guide.adoc b/modules/contributor/pages/code-style-guide.adoc
index 8ef400e97..409e6e408 100644
--- a/modules/contributor/pages/code-style-guide.adoc
+++ b/modules/contributor/pages/code-style-guide.adoc
@@ -366,7 +366,7 @@ Further, `snafu` allows us to use the same source error in multiple error varian
 This feature can be used for cases where more fine-grained error variants are required.
 This behaviour is not possible when using `thiserror`, as it uses the `From` trait to convert the source error into an error variant.
 
-Additionally, the usage of the `#[snafu(context(false))]` atrribute on error variants is restricted.
+Additionally, the usage of the `#[snafu(context(false))]` attribute on error variants is restricted.
 This ensures that fallible functions need to call `.context()` to pass the error along.
 
 The usage of `thiserror` is considered invalid.
diff --git a/modules/contributor/pages/docs/troubleshooting-antora.adoc b/modules/contributor/pages/docs/troubleshooting-antora.adoc
index 1ae0512b6..c99b3b738 100644
--- a/modules/contributor/pages/docs/troubleshooting-antora.adoc
+++ b/modules/contributor/pages/docs/troubleshooting-antora.adoc
@@ -13,4 +13,4 @@
    Omitting the component entirely will instead link to the target page _within the same version_ as the page resides in.
 * Other `xref` and `include` issues
 ** Familiarize yourself with the {antora-xref-docs}[`xref` documentation{external-link-icon}^] which explains the syntax in great detail.
-   Unfortunately the xref syntax is a common place to make mistakes, and it is easy to accidently link to the wrong place.
+   Unfortunately the xref syntax is a common place to make mistakes, and it is easy to accidentally link to the wrong place.
diff --git a/modules/contributor/pages/guidelines/webhook-server.adoc b/modules/contributor/pages/guidelines/webhook-server.adoc
index 88185ce8f..82f09a418 100644
--- a/modules/contributor/pages/guidelines/webhook-server.adoc
+++ b/modules/contributor/pages/guidelines/webhook-server.adoc
@@ -96,7 +96,7 @@ fn handler(request: ConversionReview) -> ConversionReview {
 == Mutating and validating webhooks
 
 The `stackable-webhook` library currently doesn't provide ready-to-use webhook servers for mutating or validating webhooks like `ConversionWebhookServer` above.
-Instead, you can implement a completly custom `Router` via the `axum` crate.
+Instead, you can implement a completely custom `Router` via the `axum` crate.
 
 [source,rust]
 ----
diff --git a/modules/contributor/pages/project-overview.adoc b/modules/contributor/pages/project-overview.adoc
index 7be0cd57a..bbb190ba1 100644
--- a/modules/contributor/pages/project-overview.adoc
+++ b/modules/contributor/pages/project-overview.adoc
@@ -37,7 +37,7 @@ It is a Rust library that is used by all operators and contains shared structs a
 image::project-overview-docker-images.drawio.svg[]
 
 The https://github.com/stackabletech/docker-images/[docker-images{external-link-icon}^] repository contains Dockerfiles for all the products that are supported by the SDP.
-The actual product artifacts are pulled from the <<product-artifacts, product artifacs store>> and packaged into images.
+The actual product artifacts are pulled from the <<product-artifacts, product artifacts store>> and packaged into images.
 The images are pushed into an <<docker-images, image registry>>.
 
 [[management-tooling]]
@@ -66,7 +66,7 @@ On top of the mentioned repositories, there are various smaller tools or product
 Two examples are the https://github.com/stackabletech/image-tools[image-tools{external-link-icon}^] used to build Docker images and the https://github.com/stackabletech/druid-opa-authorizer/[druid-opa-authorizer{external-link-icon}^] which is a Druid extension that enables OPA support for Druid.
 
 [[infrastructure-repositories]]
-=== Infastructure: T2
+=== Infrastructure: T2
 
 https://github.com/stackabletech/t2[T2 - Test & Troubleshoot Platform{external-link-icon}^] is used for integration testing across different versions and cloud providers, find more information in the README of the repository.
 
diff --git a/modules/contributor/pages/testing-infrastructure.adoc b/modules/contributor/pages/testing-infrastructure.adoc
index a09e591eb..88da5b543 100644
--- a/modules/contributor/pages/testing-infrastructure.adoc
+++ b/modules/contributor/pages/testing-infrastructure.adoc
@@ -17,7 +17,7 @@ Having the manifest files as Jinja2 templates avoids duplication and makes the t
 
 == Requirements
 
-To run the integration tests from your local machine, you need to have the follwing tools installed:
+To run the integration tests from your local machine, you need to have the following tools installed:
 
 * {python}[Python{external-link-icon}^] to run scripts.
 * {kuttl}[KuTTL{external-link-icon}^] to run the tests.
@@ -91,8 +91,8 @@ You can also run the tests manually there, for a particular pull request, if you
 
 == Adding a new test
 
-To add a new test, add a new directory in `tests/templates/kuttl` and also a corresponding in the `test-defintion.yaml` file.
-Have a look at other tests to familiarize yourself with the general pattern of steps in a test defintion.
+To add a new test, add a new directory in `tests/templates/kuttl` and also a corresponding in the `test-definition.yaml` file.
+Have a look at other tests to familiarize yourself with the general pattern of steps in a test definition.
 
 == Further reading
 
diff --git a/modules/guides/pages/kubernetes-cluster-domain.adoc b/modules/guides/pages/kubernetes-cluster-domain.adoc
index d53ecde1d..62e7f599c 100644
--- a/modules/guides/pages/kubernetes-cluster-domain.adoc
+++ b/modules/guides/pages/kubernetes-cluster-domain.adoc
@@ -14,4 +14,4 @@ helm install <product>-operator stackable-stable/<product>-operator --set kubern
 
 You can also specify a custom cluster domain with a trailing dot (`my.domain.` instead of `my.domain`) to reduce the number of DNS requests under certain conditions (see https://github.com/stackabletech/issues/issues/656[https://github.com/stackabletech/issues/issues/656{external-link-icon}^] for details). Note however that support for this is still considered experimental.
 
-If the environment variable `KUBERNETES_CLUSTER_DOMAIN` (or the helm property `kubernetesClusterDomain`) are not set / overriden, the operator will default the cluster domain to `cluster.local`.
+If the environment variable `KUBERNETES_CLUSTER_DOMAIN` (or the helm property `kubernetesClusterDomain`) are not set / overridden, the operator will default the cluster domain to `cluster.local`.
diff --git a/modules/guides/pages/providing-resources-with-pvcs.adoc b/modules/guides/pages/providing-resources-with-pvcs.adoc
index f3a3a7e91..32e20bdc9 100644
--- a/modules/guides/pages/providing-resources-with-pvcs.adoc
+++ b/modules/guides/pages/providing-resources-with-pvcs.adoc
@@ -56,7 +56,7 @@ spec:
 == Access modes and the StorageClass
 
 Not all storage classes support all {pvc-access-modes}[access modes{external-link-icon}^].
-The supported access modes also depend on the Kubernetes implementation, see for example the compatiblity table https://docs.openshift.com/container-platform/4.8/storage/understanding-persistent-storage.html#pv-access-modes_understanding-persistent-storage[Supported access modes for PVs{external-link-icon}^] in the OpenShift documentation. Other managed Kubernetes implementations will be similar, albeit with different default storage class names.
+The supported access modes also depend on the Kubernetes implementation, see for example the compatibility table https://docs.openshift.com/container-platform/4.8/storage/understanding-persistent-storage.html#pv-access-modes_understanding-persistent-storage[Supported access modes for PVs{external-link-icon}^] in the OpenShift documentation. Other managed Kubernetes implementations will be similar, albeit with different default storage class names.
 The important point is that the default StorageClass only supports `ReadWriteOnce`, which limits access to the PersistentVolumeClaim to a single node.
 A strategy governing PersistentVolumeClaim resources will thus address the following:
 
diff --git a/modules/guides/pages/viewing-and-verifying-sboms.adoc b/modules/guides/pages/viewing-and-verifying-sboms.adoc
index 7e59ad62f..65e3491b3 100644
--- a/modules/guides/pages/viewing-and-verifying-sboms.adoc
+++ b/modules/guides/pages/viewing-and-verifying-sboms.adoc
@@ -36,7 +36,7 @@ Explanation of the commands and parameters:
 
 The `--type` parameter specifies the type of the predicate, in this case `cyclonedx` for CycloneDX SBOMs.
 The `--certificate-identity-regexp` parameter specifies a regular expression that is used to match the identity of the signer of the attestation. In this case, that means: The attestation must be signed by a GitHub Actions workflow run by the `stackabletech` organization (the *identity*). Now, because in general anyone could claim to be a `stackabletech` workflow run, the `--certificate-oidc-issuer` parameter ensures that this identity was actually verified by GitHub.
-If the identity of the signer matches, you can be sure the contents of the attestation are authentic and were created by one of Stackable's Github Action Workflows. `cosign verify-attestation` then prints the signed attestation to `stdout`, which is an https://github.com/in-toto/attestation[in-toto attestation{external-link-icon}^] wrapped in a https://github.com/secure-systems-lab/dsse[DSSE{external-link-icon}^]. The next command (`jq '.payload'`) gets the payload of the envelope, which is the base64 encoded attestation. `base64 -d` decodes it and returns the attestation in JSON format. The attestation has a `subject` attribute, which provides information about the container image the SBOM belongs to. `predicate` is the actual SBOM, which is extrated by the `jq '.predicate'` command and then printed to `stdout` in JSON format.
+If the identity of the signer matches, you can be sure the contents of the attestation are authentic and were created by one of Stackable's Github Action Workflows. `cosign verify-attestation` then prints the signed attestation to `stdout`, which is an https://github.com/in-toto/attestation[in-toto attestation{external-link-icon}^] wrapped in a https://github.com/secure-systems-lab/dsse[DSSE{external-link-icon}^]. The next command (`jq '.payload'`) gets the payload of the envelope, which is the base64 encoded attestation. `base64 -d` decodes it and returns the attestation in JSON format. The attestation has a `subject` attribute, which provides information about the container image the SBOM belongs to. `predicate` is the actual SBOM, which is extracted by the `jq '.predicate'` command and then printed to `stdout` in JSON format.
 
 `cosign` also prints information to `stderr`, which can be used to determine further information on the verification results and the exact Github Action workflow that was used to create this attestation.
 
diff --git a/modules/operators/pages/index.adoc b/modules/operators/pages/index.adoc
index 6de3902bf..211678a0a 100644
--- a/modules/operators/pages/index.adoc
+++ b/modules/operators/pages/index.adoc
@@ -289,7 +289,7 @@ xref:secret-operator:index.adoc[Read more]
 <h3 id="listener-operator"><a class="anchor" href="#listener-operator"></a>Listener</h3>
 ++++
 
-The listener operator is reponsible for making services available outside of the Kubernetes cluster.
+The listener operator is responsible for making services available outside of the Kubernetes cluster.
 
 xref:listener-operator:index.adoc[Read more]
 
diff --git a/modules/reference/pages/glossary.adoc b/modules/reference/pages/glossary.adoc
index d7982b3cd..89ac25977 100644
--- a/modules/reference/pages/glossary.adoc
+++ b/modules/reference/pages/glossary.adoc
@@ -18,7 +18,7 @@ dt {
 
 // syntax explanation:
 // - the [[...]] creates an anchor at the list item
-// - The <<...>> creates a link to the achor
+// - The <<...>> creates a link to the anchor
 // - The {li} references the pass that you can find at the top of the document, it is a FontAwesome icon
 // - The ...:: is the syntax for a definition list item
 // - The {empty} followed by the + means that there is no "normal" list item, instead there is a block
@@ -26,7 +26,7 @@ dt {
 // - Inside the "====" is the details of the details block.
 //
 // Please create new entries the same way! This allows easy linking to glossary items.
-// Antora generates dl, dt and dd tages for the definition list, which is great because these are
+// Antora generates dl, dt and dd tags for the definition list, which is great because these are
 // semantic HTML tags.
 
 [[role]]Role <<role,{li}>>:: {empty}
diff --git a/modules/tutorials/pages/authentication_with_openldap.adoc b/modules/tutorials/pages/authentication_with_openldap.adoc
index 259650e1d..7804b8c25 100644
--- a/modules/tutorials/pages/authentication_with_openldap.adoc
+++ b/modules/tutorials/pages/authentication_with_openldap.adoc
@@ -142,7 +142,7 @@ Remember the name of the AuthenticationClass (`openldap`), you will use it in th
 
 To make Superset use your new LDAP AuthenticationClass, you have to update the SupersetCluster definition. A SupersetCluster named `superset` is already installed by the stack.
 
-Fetch the existing SupersetCluster defintion from the Kubernetes API server and save it into a `superset.yaml` file:
+Fetch the existing SupersetCluster definition from the Kubernetes API server and save it into a `superset.yaml` file:
 
 [source,bash]
 include::example$ldap-auth/40-modify-superset.sh[tag=get-superset-yaml]
diff --git a/modules/tutorials/pages/logging-vector-aggregator.adoc b/modules/tutorials/pages/logging-vector-aggregator.adoc
index 7ac903fe1..c5b5062a2 100644
--- a/modules/tutorials/pages/logging-vector-aggregator.adoc
+++ b/modules/tutorials/pages/logging-vector-aggregator.adoc
@@ -117,4 +117,4 @@ Congratulations, this concludes the tutorial!
 
 == What's next?
 
-Look into different sink configurations which are more suited to production use in the https://vector.dev/docs/reference/configuration/sinks/[sinks overview documetation{external-link-icon}^] or learn more about how logging works on the platform in the xref:concepts:observability/logging.adoc[concepts documentation].
+Look into different sink configurations which are more suited to production use in the https://vector.dev/docs/reference/configuration/sinks/[sinks overview documentation{external-link-icon}^] or learn more about how logging works on the platform in the xref:concepts:observability/logging.adoc[concepts documentation].
diff --git a/scripts/make-release-branch.sh b/scripts/make-release-branch.sh
index 9f7ccbc1d..29956803d 100755
--- a/scripts/make-release-branch.sh
+++ b/scripts/make-release-branch.sh
@@ -1,7 +1,7 @@
 #!/usr/bin/env bash
 set -euo pipefail
 
-# This script creates a new 'release-{major}.{minor}'  branch for the documetation,
+# This script creates a new 'release-{major}.{minor}'  branch for the documentation,
 # off of the 'main' branch.
 #
 # The script reminds you about some pre-requisites before actually running. These are:
@@ -66,7 +66,7 @@ DOCS_VERSION=$(echo "$VERSION" | cut -d. -f1,2)
 # ------------------------------
 
 # Ask the user if they have written release notes and merged them into main
-echo "Release notes for the new version should already be written and commited to the main branch,"
+echo "Release notes for the new version should already be written and committed to the main branch,"
 echo "so they show up in both the nightly and future versions, as well as the new release branch"
 echo "that is about the be created."
 read -r -p "Did you already write release notes and merge them into main? (yes/no): " RELEASE_NOTES_ANSWER
diff --git a/ui/src/css/footer.css b/ui/src/css/footer.css
index b48a86717..5eef60e1b 100644
--- a/ui/src/css/footer.css
+++ b/ui/src/css/footer.css
@@ -113,7 +113,7 @@ footer.footer {
   text-decoration: none;
 }
 
-.footer-seperator {
+.footer-separator {
   width: 100%;
   height: 1px;
   background-color: var(--footer-font-color);
diff --git a/ui/src/partials/footer-content.hbs b/ui/src/partials/footer-content.hbs
index 12591322d..e3a2787df 100644
--- a/ui/src/partials/footer-content.hbs
+++ b/ui/src/partials/footer-content.hbs
@@ -52,7 +52,7 @@
           </ul>
         </div>
       </div>
-      <div class="footer-seperator"></div>
+      <div class="footer-separator"></div>
       <!-- social links -->
       <div class="c-and-socials">
         <div>© 2025 Stackable.</div>