backport typos according to 4364 (#4407)

docs/components/best-practices/architecture/deciding-about-your-stack-c7.md

@@ -64,7 +64,7 @@ We decided on this stack for the following reasons:
 - All components are open source and easily available.
 - Camunda Run is the favorite distribution, as it focuses on external tasks, the more modern paradigm also present in Camunda 8.
 - Spring Boot is currently the most adopted way of building Java applications.
-- Spring Boot applications are easy to customize as well as easy to roll out into test and production environments, either on-premise or in the cloud.
+- Spring Boot applications are easy to customize as well as easy to roll out into test and production environments, either on-premises or in the cloud.
 - PostgreSQL has a great track-record for performance.
 
 There are several _advantages using the greenfield stack_:

docs/components/best-practices/architecture/deciding-about-your-stack.md

@@ -27,7 +27,7 @@ This architecture diagram illustrates the flow of requests from a user's browser
 
 - SaaS simplifies workflow engine integration.
 - Spring Boot is widely adopted for Java application development.
-- Flexible for both on-premise and cloud environments.
+- Flexible for both on-premises and cloud environments.
 
 Discover more in our [getting started guide for microservices orchestration](/guides/getting-started-orchestrate-microservices.md) or the [Spring Zeebe SDK instructions](../../../apis-tools/spring-zeebe-sdk/getting-started.md).
 

docs/components/best-practices/development/invoking-services-from-the-process-c7.md

@@ -28,7 +28,7 @@ In most cases, you should use a pull approach, where external worker threads que
 
 There are two patterns available to glue your code to a process model:
 
-- **Push:** The process engine actively issues a **service call** (or executes a **script**) via the mechanisms described below. The workflow engie pushes the work.
+- **Push:** The process engine actively issues a **service call** (or executes a **script**) via the mechanisms described below. The workflow engine pushes the work.
 - **Pull:** External worker threads query the process engine API for **external tasks**, and they pull the work. Then, they do the actual work and notify the process engine of works completion.
 
 ### External tasks
@@ -51,7 +51,7 @@ Using external tasks comes with the following advantages:
 
 - **Better scaling**: The pattern allows you to start and stop workers as you like, and run as many of them as you need. By doing so, you can scale each service task (or to be precise, each "topic") individually.
 
-- **Connect cloud and on-premise**: The pattern supports you in running Camunda somewhere in the cloud (as our customers often do), because you can still have services on-premise, as they can now query their work via REST over SSL, which is also quite firewall-friendly.
+- **Connect cloud and on-premises**: The pattern supports you in running Camunda somewhere in the cloud (as our customers often do), because you can still have services on-premises, as they can now query their work via REST over SSL, which is also quite firewall-friendly.
 
 - **Avoid timeouts**: The pattern allows you to asynchronously call long-running services, which eventually block for hours (and would therefore cause transaction and connection timeouts when being called synchronously).
 

docs/components/zeebe/zeebe-overview.md

@@ -12,7 +12,7 @@ With Zeebe you can:
 - Define processes graphically in [BPMN 2.0](../modeler/bpmn/bpmn-coverage.md).
 - Choose any [gRPC](/apis-tools/zeebe-api/grpc.md)-supported programming language to implement your workers.
 - Build processes that react to events from Apache Kafka and other messaging platforms.
-- Use as part of a software as a service (SaaS) offering with Camunda 8 or deploy with Docker and Kubernetes (in the cloud or on-premise) with Camunda 8 Self-Managed.
+- Use as part of a software as a service (SaaS) offering with Camunda 8 or deploy with Docker and Kubernetes (in the cloud or on-premises) with Camunda 8 Self-Managed.
 - Scale horizontally to handle very high throughput.
 - Rely on fault tolerance and high availability for your processes.
 - Export processes data for monitoring and analysis (available through the [exporters](../../self-managed/zeebe-deployment/exporters/exporters.md) added in Camunda 8 Self-Managed).
@@ -22,7 +22,7 @@ For documentation on deploying Zeebe as part of Camunda 8 Self-Managed, refer to
 
 ## Enterprise support for Zeebe
 
-Paid support for Zeebe is available via either Camunda 8 Starter or Camunda 8 Enterprise plans. Customers can choose either plan based on their process automation requirements. Camunda 8 Enterprise customers also have the option of on-premise or private cloud deployment.
+Paid support for Zeebe is available via either Camunda 8 Starter or Camunda 8 Enterprise plans. Customers can choose either plan based on their process automation requirements. Camunda 8 Enterprise customers also have the option of on-premises or private cloud deployment.
 
 Additionally, regardless of how you are working with Zeebe and Camunda 8, you can always find support through the [community](/contact/).
 

docs/guides/migrating-from-cawemo.md

@@ -24,7 +24,7 @@ Data access and transition deadline: This means that you have until the 30th of
 
 - Move to [Web Modeler](/components/modeler/web-modeler/launch-web-modeler.md): Experience the combined power of Cawemo and our Desktop Modeler in a seamless, collaborative environment. For modeling only or Camunda 8 processes.
 - Move to [Desktop Modeler](/components/modeler/desktop-modeler/install-the-modeler.md): Opt for a standalone BPMN modeling experience. Support both Camunda 7 and Camunda 8 processes.
-- Move to Cawemo On-Premise: Continue with the familiar Cawemo environment, for modeling only or Camunda 7 processes. Please note that support for Cawemo On-Premise aligns with Camunda 7 timelines.
+- Move to Cawemo on-premises: Continue with the familiar Cawemo environment, for modeling only or Camunda 7 processes. Please note that support for Cawemo on-premises aligns with Camunda 7 timelines.
 
 We understand that change can be challenging, and our team is dedicated to ensuring a smooth transition for you and your organization. For any queries or support during this transition phase, reach out to your account team.
 :::

docs/reference/supported-environments.md

@@ -49,7 +49,7 @@ We recommend running Camunda 8 Self-Managed in a Kubernetes environment. We prov
 
 ### Deployment options
 
-With the right configuration, Camunda 8 Self-Managed can be deployed on any [Certified Kubernetes](https://www.cncf.io/training/certification/software-conformance/#benefits) distribution (cloud or on-premise). However, we officially test and support a specific list of platforms.
+With the right configuration, Camunda 8 Self-Managed can be deployed on any [Certified Kubernetes](https://www.cncf.io/training/certification/software-conformance/#benefits) distribution (cloud or on-premises). However, we officially test and support a specific list of platforms.
 
 The following are tested and supported deployment options for Kubernetes, Docker, and manual installation:
 

docs/self-managed/setup/deploy/openshift/redhat-openshift.md

@@ -7,7 +7,7 @@ description: "Deploy Camunda 8 Self-Managed on Red Hat OpenShift"
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-Red Hat OpenShift, a Kubernetes distribution maintained by [Red Hat](https://www.redhat.com/en/technologies/cloud-computing/openshift), provides options for both managed and on-premise hosting.
+Red Hat OpenShift, a Kubernetes distribution maintained by [Red Hat](https://www.redhat.com/en/technologies/cloud-computing/openshift), provides options for both managed and on-premises hosting.
 
 :::note
 Deploying Camunda 8 on Red Hat OpenShift is achievable using Helm, given the appropriate configurations. However, it's important to note that the [Security Context Constraints (SCCs)](#security-context-constraints-sccs) and [Routes](./redhat-openshift.md?current-ingress=openshift-routes#using-openshift-routes) configurations might require slight deviations from the guidelines provided in the [general Helm deployment guide](/self-managed/setup/install.md).

docs/self-managed/setup/overview.md

@@ -20,7 +20,7 @@ For details on supported environments (e.g. Java or Elasticsearch versions), see
 
 ## Deployment options
 
-- [**Helm/Kubernetes**](./install.md): We recommend using Kubernetes and Helm to deploy and run Camunda 8 Self-Managed in production. With the right configuration, Camunda 8 Self-Managed can be deployed on any Certified Kubernetes distribution (cloud or on-premise). We also officially support a variety of providers like [Red Hat OpenShift](./deploy/openshift/redhat-openshift.md) and [Amazon EKS](./deploy/amazon/amazon-eks/amazon-eks.md).
+- [**Helm/Kubernetes**](./install.md): We recommend using Kubernetes and Helm to deploy and run Camunda 8 Self-Managed in production. With the right configuration, Camunda 8 Self-Managed can be deployed on any Certified Kubernetes distribution (cloud or on-premises). We also officially support a variety of providers like [Red Hat OpenShift](./deploy/openshift/redhat-openshift.md) and [Amazon EKS](./deploy/amazon/amazon-eks/amazon-eks.md).
 - [**Docker**](./deploy/other/docker.md): Component [Docker images](https://hub.docker.com/u/camunda) are available for use in production on Linux systems. Windows or macOS are only supported for development environments.
 - [**Manual**](./deploy/local/manual.md): The Java applications can run on a local or virtual machine if it provides a supported Java Virtual Machine (JVM). This allows you to run Camunda on virtual machines or bare metal and offers a significant amount of flexibility. However, you will need to configure the details for the components to interact correctly yourself. We consider this a last resort. Note that Windows/Mac is **not** supported for production usage of Zeebe.
 

versioned_docs/version-1.3/components/best-practices/architecture/deciding-about-your-stack-c7.md

@@ -64,7 +64,7 @@ We decided on this stack for the following reasons:
 - All components are open-source and easily available.
 - Camunda Run is the favorite distribution, as it focuses on external tasks, the more modern paradigm also present in Camunda Cloud.
 - Spring Boot is currently the most adopted way of building Java applications.
-- Spring Boot applications are easy to customize as well as easy to roll out into test and production environments, either on-premise or in the cloud.
+- Spring Boot applications are easy to customize as well as easy to roll out into test and production environments, either on-premises or in the cloud.
 - PostgreSQL has a great track-record for performance.
 
 There are severa; *advantages using the greenfield stack*:

versioned_docs/version-1.3/components/best-practices/architecture/deciding-about-your-stack.md

@@ -53,7 +53,7 @@ We decided on this stack for the following reasons:
 - All components are open-source and easily available.
 - SaaS is the easiest way to consume capabilities like a workflow engine.
 - Spring Boot is currently the most adopted way of building Java applications.
-- Spring Boot applications are easy to customize as well as easy to roll out into test and production environments, either on-premise or in the cloud.
+- Spring Boot applications are easy to customize as well as easy to roll out into test and production environments, either on-premises or in the cloud.
 
 You might want to follow the [get started guide for microservices orchestration](/guides/getting-started-orchestrate-microservices.md) or follow the instrucstions in [Spring Zeebe](https://github.com/camunda-community-hub/spring-zeebe) to get going
 

versioned_docs/version-1.3/components/best-practices/development/invoking-services-from-the-process-c7.md

@@ -28,7 +28,7 @@ In most cases, you should use a pull approach, where external worker threads que
 
 There are two patterns available to glue your code to a process model:
 
-* **Push:** The process engine actively issues a **service call** (or executes a **script**) via the mechanisms described below. The workflow engie pushes the work.
+* **Push:** The process engine actively issues a **service call** (or executes a **script**) via the mechanisms described below. The workflow engine pushes the work.
 * **Pull:** External worker threads query the process engine API for **external tasks**, and they pull the work. Then, they do the actual work and notify the process engine of works completion.
 
 ### External tasks
@@ -51,7 +51,7 @@ Using external tasks comes with the following advantages:
 
 * **Better scaling**: The pattern allows you to start and stop workers as you like, and run as many of them as you need. By doing so, you can scale each service task (or to be precise, each "topic") individually.
 
-* **Connect cloud and on-premise**: The pattern supports you in running Camunda somewhere in the cloud (as our customers often do), because you can still have services on-premise, as they can now query their work via REST over SSL, which is also quite firewall-friendly.
+* **Connect cloud and on-premises**: The pattern supports you in running Camunda somewhere in the cloud (as our customers often do), because you can still have services on-premises, as they can now query their work via REST over SSL, which is also quite firewall-friendly.
 
 * **Avoid timeouts**: The pattern allows you to asynchronously call long-running services, which eventually block for hours (and would therefore cause transaction and connection timeouts when being called synchronously).
 

versioned_docs/version-8.2/components/best-practices/architecture/deciding-about-your-stack-c7.md

@@ -64,7 +64,7 @@ We decided on this stack for the following reasons:
 - All components are open source and easily available.
 - Camunda Run is the favorite distribution, as it focuses on external tasks, the more modern paradigm also present in Camunda 8.
 - Spring Boot is currently the most adopted way of building Java applications.
-- Spring Boot applications are easy to customize as well as easy to roll out into test and production environments, either on-premise or in the cloud.
+- Spring Boot applications are easy to customize as well as easy to roll out into test and production environments, either on-premises or in the cloud.
 - PostgreSQL has a great track-record for performance.
 
 There are several _advantages using the greenfield stack_:

versioned_docs/version-8.2/components/best-practices/architecture/deciding-about-your-stack.md

@@ -31,7 +31,7 @@ This architecture diagram illustrates the flow of requests from a user's browser
 
 - SaaS simplifies workflow engine integration.
 - Spring Boot is widely adopted for Java application development.
-- Flexible for both on-premise and cloud environments.
+- Flexible for both on-premises and cloud environments.
 
 Discover more in our [getting started guide for microservices orchestration](/guides/getting-started-orchestrate-microservices.md) or the [Spring Zeebe instructions](https://github.com/camunda-community-hub/spring-zeebe).
 

versioned_docs/version-8.2/components/best-practices/development/invoking-services-from-the-process-c7.md

@@ -28,7 +28,7 @@ In most cases, you should use a pull approach, where external worker threads que
 
 There are two patterns available to glue your code to a process model:
 
-- **Push:** The process engine actively issues a **service call** (or executes a **script**) via the mechanisms described below. The workflow engie pushes the work.
+- **Push:** The process engine actively issues a **service call** (or executes a **script**) via the mechanisms described below. The workflow engine pushes the work.
 - **Pull:** External worker threads query the process engine API for **external tasks**, and they pull the work. Then, they do the actual work and notify the process engine of works completion.
 
 ### External tasks
@@ -51,7 +51,7 @@ Using external tasks comes with the following advantages:
 
 - **Better scaling**: The pattern allows you to start and stop workers as you like, and run as many of them as you need. By doing so, you can scale each service task (or to be precise, each "topic") individually.
 
-- **Connect cloud and on-premise**: The pattern supports you in running Camunda somewhere in the cloud (as our customers often do), because you can still have services on-premise, as they can now query their work via REST over SSL, which is also quite firewall-friendly.
+- **Connect cloud and on-premises**: The pattern supports you in running Camunda somewhere in the cloud (as our customers often do), because you can still have services on-premises, as they can now query their work via REST over SSL, which is also quite firewall-friendly.
 
 - **Avoid timeouts**: The pattern allows you to asynchronously call long-running services, which eventually block for hours (and would therefore cause transaction and connection timeouts when being called synchronously).
 

versioned_docs/version-8.2/self-managed/platform-deployment/helm-kubernetes/deploy.md

@@ -38,7 +38,7 @@ When installing the [camunda-platform](https://github.com/camunda/camunda-platfo
 
 Before deploying Camunda using Helm you need the following:
 
-- [Kubernetes cluster](./overview.md#kubernetes-environments): either local, cloud platform, or on-premise.
+- [Kubernetes cluster](./overview.md#kubernetes-environments): either local, cloud platform, or on-premises.
 - [Helm](https://helm.sh/docs/intro/install/) binary.
 - [Kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) binary.
 

versioned_docs/version-8.2/self-managed/platform-deployment/helm-kubernetes/overview.md

@@ -20,7 +20,7 @@ You can install Camunda 8 on your Kubernetes environment of choice, e.g.:
 
 ## Officially supported platforms
 
-With the right configuration, Camunda 8 can be deployed on any Kubernetes distribution (Cloud or on-premise). However, we officially test and support a [specific list of platforms](./platforms/platforms.md).
+With the right configuration, Camunda 8 can be deployed on any Kubernetes distribution (Cloud or on-premises). However, we officially test and support a [specific list of platforms](./platforms/platforms.md).
 
 ## Versioning
 

versioned_docs/version-8.2/self-managed/platform-deployment/helm-kubernetes/platforms/platforms.md

@@ -9,7 +9,7 @@ import {useCurrentSidebarCategory} from '@docusaurus/theme-common';
 
 [Deploying Camunda 8 using Helm charts](../deploy.md) will work for all platforms and distributions. However, each platform or cloud provider may have special prerequisites or pitfalls to avoid. This section highlights important notes for a smooth Camunda 8 deployment on different Kubernetes platforms.
 
-In addition to Stock Kubernetes (which could be deployed on cloud or on-premise), Camunda only officially tests and supports the following platforms:
+In addition to Stock Kubernetes (which could be deployed on cloud or on-premises), Camunda only officially tests and supports the following platforms:
 
 <DocCardList items={useCurrentSidebarCategory().items}/>
 

versioned_docs/version-8.2/self-managed/platform-deployment/overview.md

@@ -20,7 +20,7 @@ For details on supported environments (e.g. Java or Elasticsearch versions), see
 
 ## Deployment options
 
-- [**Helm/Kubernetes**](./helm-kubernetes/deploy.md): We recommend using Kubernetes and Helm to deploy and run Camunda 8 Self-Managed in production. With the right configuration, Camunda 8 Self-Managed can be deployed on any Certified Kubernetes distribution (cloud or on-premise). We also officially support a variety of providers like [Red Hat OpenShift](./helm-kubernetes/platforms/redhat-openshift.md) and [Amazon EKS](./helm-kubernetes/platforms/amazon-eks.md).
+- [**Helm/Kubernetes**](./helm-kubernetes/deploy.md): We recommend using Kubernetes and Helm to deploy and run Camunda 8 Self-Managed in production. With the right configuration, Camunda 8 Self-Managed can be deployed on any Certified Kubernetes distribution (cloud or on-premises). We also officially support a variety of providers like [Red Hat OpenShift](./helm-kubernetes/platforms/redhat-openshift.md) and [Amazon EKS](./helm-kubernetes/platforms/amazon-eks.md).
 - [**Docker**](../platform-deployment/docker.md): Component [Docker images](https://hub.docker.com/u/camunda) are available for use in production on Linux systems. Windows or macOS are only supported for development environments.
 - [**Manual**](../platform-deployment/manual.md): The Java applications can run on a local or virtual machine if it provides a supported Java Virtual Machine (JVM). This allows you to run Camunda on virtual machines or bare metal and offers a significant amount of flexibility. However, you will need to configure the details for the components to interact correctly yourself. We consider this a last resort. Note that Windows/Mac is **not** supported for production usage of Zeebe.
 

versioned_docs/version-8.3/components/best-practices/architecture/deciding-about-your-stack-c7.md

@@ -64,7 +64,7 @@ We decided on this stack for the following reasons:
 - All components are open source and easily available.
 - Camunda Run is the favorite distribution, as it focuses on external tasks, the more modern paradigm also present in Camunda 8.
 - Spring Boot is currently the most adopted way of building Java applications.
-- Spring Boot applications are easy to customize as well as easy to roll out into test and production environments, either on-premise or in the cloud.
+- Spring Boot applications are easy to customize as well as easy to roll out into test and production environments, either on-premises or in the cloud.
 - PostgreSQL has a great track-record for performance.
 
 There are several _advantages using the greenfield stack_: