# Deployment options

When considering using WebSpellChecker Server, you can choose among a list of **deployment types** inside your infrastructure which represent a server or group of servers where copies of WebSpellChecker are deployed.

These deployment types depend on the tasks to fulfill and your infrastructure.

We recommend setting up such environments for uninterrupted work of WebSpellChecker Server integrated into your web apps as well as WebSpellChecker installation package components after you familiarize yourself with WebSpellChecker basics and want to start exploring more complex configuration tasks.

Deployment environments can be called **Production**, **Testing** or **Quality Assurance** (QA), **Development** (Dev), and others depending on your needs.

These are the most common and recommended deployment schemes:

* Using **one installation of WebSpellChecker Server** connected to one or **multiple web apps** (one to many relationships);
* Using **several installations of WebSpellChecker Servers** connected to **several web applications** (many to many relationships);
* Using multiple copies of **WebSpellChecker Servers which are scaled depending on the load** connected to **multiple web apps**;
* Having WebSpellChecker Server and your web app installed on the **same server**.

### Scenario A. One WebSpellChecker Server and multiple client servers <a href="#deploymentoptions-scenarioa.onewebspellcheckerserverandmultipleclientservers" id="deploymentoptions-scenarioa.onewebspellcheckerserverandmultipleclientservers"></a>

In this simplest scenario type, which we recommend to use right from the start, you have the following deployment components:

* WebSpellChecker Server
* Production Server
* Dev/QA Server

Environments here can be development/QA, and production environments in your IT infrastructure.

All of them are connected to a **single centralized WSC Server** which processes the service requests from them.

#### **Scenario advantages** <a href="#deploymentoptions-scenarioadvantages" id="deploymentoptions-scenarioadvantages"></a>

You minimize your expenses on licensing WebSpellChecker though you have quite stable and isolated production environment enabling uninterrupted workflow of both your production environment and WebSpellChecker Server.

On the other hand, with such a deployment type you should consider the WSC Server workload issues since all web apps are set up to use only one WSC Server. Thus, the number of service requests (such as spelling and grammar check) sent should be supervised/managed and set up properly.

### Scenario B. Multiple WebSpellChecker Servers and multiple client environments <a href="#deploymentoptions-scenariob.multiplewebspellcheckerserversandmultipleclientenvironments" id="deploymentoptions-scenariob.multiplewebspellcheckerserversandmultipleclientenvironments"></a>

In this scenario you have the following deployment components:

* Multiple WebSpellChecker Servers
* **Load Balancer** and Auto Scaling mechanisms
* Production Server
* Dev/QA Server

Environments can be Development/QA, and Production environments in your IT infrastructure.

Here, **Load Balancer** enables even allocation of service requests for grammar and spelling check.Thus, the environments don’t fully rely on one centralized server to fulfill the needs of all connected web apps.

#### **Scenario advantages** <a href="#deploymentoptions-scenarioadvantages.1" id="deploymentoptions-scenarioadvantages.1"></a>

Compared with Scenario A, if some issues take place in the Production environment, the whole structure easily adjusts and starts using a different available WSC Server. Moreover, with a Load Balancer, the WSC Server workload is leveraged, and the Server keeps processing the requests from your Production and/or Dev/QA Servers. The whole system can be scaled to serve distributed environments where each environment can have its own dedicated WSC Server.

### Scenario C. Scaled WebSpellChecker Servers and multiple client environments <a href="#deploymentoptions-scenarioc.scaledwebspellcheckerserversandmultipleclientenvironments" id="deploymentoptions-scenarioc.scaledwebspellcheckerserversandmultipleclientenvironments"></a>

In this scenario you have the following deployment components:

* WebSpellChecker Servers dedicated for Production or Dev/QA purposes only
* Load Balancer and Auto Scaling mechanisms
* Production Server
* Dev/QA Server

Here, Production, Development, and QA environments are **isolated**. Load Balancer enables uninterrupted work of Production environment serving the requests on multiple WSC Servers.

You can perform your development tasks, test the results of your work on a dedicated testing and development server and later integrate them to your web apps on the Production Server. Thus, the whole environment is safe and easy to maintain.

Such an environment can be scaled to serve distributed environments where Production and Dev/QA environments can have their own dedicated WSC Server.

### Scenario D. WebSpellChecker Server and client application installed on the same server <a href="#deploymentoptions-scenariod.webspellcheckerserverandclientapplicationinstalledonthesameserver" id="deploymentoptions-scenariod.webspellcheckerserverandclientapplicationinstalledonthesameserver"></a>

In this scenario, WebSpellChecker is installed on the same server as your web apps, and all service requests and their processing take place on the same server. Such deployment scheme does not imply any Load Balancers or distributed server environment.

Thus, it is necessary to consider that any issues occurring in the Production, QA, and Development environments can affect or interrupt the work of WCS Server.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.wproofreader.com/deployment/installation/deployment-options.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.