fastapi · tiangolo · Oct 1, 2021 · Oct 1, 2021 · Oct 1, 2021 · Oct 1, 2021
diff --git a/docs/en/docs/deployment/concepts.md b/docs/en/docs/deployment/concepts.md
diff --git a/docs/en/docs/deployment/deta.md b/docs/en/docs/deployment/deta.md
@@ -238,3 +238,21 @@ You can also edit them and re-play them.
 At some point you will probably want to store some data for your app in a way that persists through time. For that you can use <a href="https://docs.deta.sh/docs/base/py_tutorial?ref=fastapi" class="external-link" target="_blank">Deta Base</a>, it also has a generous **free tier**.
 
 You can also read more in the <a href="https://docs.deta.sh?ref=fastapi" class="external-link" target="_blank">Deta Docs</a>.
+
+## Deployment Concepts
+
+Coming back to the concepts we discussed in [Deployments Concepts](./concepts.md){.internal-link target=_blank}, here's how each of them would be handled with Deta:
+
+* **HTTPS**: Handled by Deta, they will give you a subdomain and handle HTTPS automatically.
+* **Running on startup**: Handled by Deta, as part of their service.
+* **Restarts**: Handled by Deta, as part of their service.
+* **Replication**: Handled by Deta, as part of their service.
+* **Memory**: Limit predefined by Deta, you could contact them to increase it.
+* **Previous steps before starting**: Not directly supported, you could make it work with their Cron system or additional scripts.
+
+!!! note
+    Deta is designed to make it easy (and free) to deploy simple applications quickly.
+
+    It can simplify a lot several use cases, but at the same time it doesn't support others, like using external databases (apart from Deta's own NoSQL database system), custom virtual machines, etc.
+
+    You can read more details in the <a href="https://docs.deta.sh/docs/micros/about/" class="external-link" target="_blank">Deta docs</a> to see if it's the right choice for you.
diff --git a/docs/en/docs/deployment/docker.md b/docs/en/docs/deployment/docker.md
diff --git a/docs/en/docs/deployment/index.md b/docs/en/docs/deployment/index.md
@@ -2,6 +2,20 @@
 
 Deploying a **FastAPI** application is relatively easy.
 
+## What Does Deployment Mean
+
+To **deploy** an application means to perform the necessary steps to make it **available to the users**.
+
+For a **web API**, it normally involves putting it in a **remote machine**, with a **server program** that provides good performance, stability, etc, so that your **users** can **access** the application efficiently and without interruptions or problems.
+
+This is in contrast to the the **development** stages, where you are constantly changing the code, breaking it and fixing it, stopping and restarting the development server, etc.
+
+## Deployment Strategies
+
 There are several ways to do it depending on your specific use case and the tools that you use.
 
-You will see more details to have in mind and some of the techniques to do it in the next sections.
+You could **deploy a server** yourself using a combination of tools, you could use a **cloud service** that does part of the work for you, or other possible options.
+
+I will show you some of the main concepts you should probably have in mind when deploying a **FastAPI** application (although most of it applies to any other type of web application).
+
+You will see more details to have in mind and some of the techniques to do it in the next sections. ✨
diff --git a/docs/en/docs/deployment/manually.md b/docs/en/docs/deployment/manually.md
@@ -1,8 +1,26 @@
-# Deploy manually
+# Run a Server Manually - Uvicorn
 
-You can deploy **FastAPI** manually as well.
+The main thing you need to run a **FastAPI** application in a remote server machine is an ASGI server program like **Uvicorn**.
 
-You just need to install an ASGI compatible server like:
+There are 3 main alternatives:
+
+* <a href="https://www.uvicorn.org/" class="external-link" target="_blank">Uvicorn</a>: a high performance ASGI server.
+* <a href="https://pgjones.gitlab.io/hypercorn/" class="external-link" target="_blank">Hypercorn</a>: an ASGI server compatible with HTTP/2 and Trio among other features.
+* <a href="https://github.com/django/daphne" class="external-link" target="_blank">Daphne</a>: the ASGI server built for Django Channels.
+
+## Server Machine and Server Program
+
+There's a small detail about names to have in mind. 💡
+
+The word "**server**" is commonly used to refer to both the remote/cloud computer (the physical or virtual machine) and also the program that is running on that machine (e.g. Uvicorn).
+
+Just have that in mind when you read "server" in general, it could refer to one of those two things.
+
+When referring to the remote machine, it's common to call it **server**, but also **machine**, **VM** (virtual machine), **node**. Those all refer to some type of remote machine, normally running Linux, where you run programs.
+
+## Install the Server Program
+
+You can install an ASGI compatible server with:
 
 === "Uvicorn"
 
@@ -39,7 +57,9 @@ You just need to install an ASGI compatible server like:
 
     ...or any other ASGI server.
 
-And run your application the same way you have done in the tutorials, but without the `--reload` option, e.g.:
+## Run the Server Program
+
+You can then your application the same way you have done in the tutorials, but without the `--reload` option, e.g.:
 
 === "Uvicorn"
 
@@ -65,10 +85,24 @@ And run your application the same way you have done in the tutorials, but withou
 
     </div>
 
-You might want to set up some tooling to make sure it is restarted automatically if it stops.
+!!! warning
+    Remember to remove the `--reload` option if you were using it.
+
+    The `--reload` option consumes much more resources, is more unstable, etc.
+
+    It helps a lot during **development**, but you **shouldn't** use it in **production**.
+
+## Deployment Concepts
+
+These examples run the server program (e.g Uvicorn), starting **a single process**, listening on all the IPs (`0.0.0.0`) on a predefined port (e.g. `80`).
 
-You might also want to install <a href="https://gunicorn.org/" class="external-link" target="_blank">Gunicorn</a> and <a href="https://www.uvicorn.org/#running-with-gunicorn" class="external-link" target="_blank">use it as a manager for Uvicorn</a>, or use Hypercorn with multiple workers.
+This is the basic idea. But you will probably want to take care of some additional things, like:
 
-Making sure to fine-tune the number of workers, etc.
+* Security - HTTPS
+* Running on startup
+* Restarts
+* Replication (the number of processes running)
+* Memory
+* Previous steps before starting
 
-But if you are doing all that, you might just use the Docker image that does it automatically.
+I'll tell you more about each of these concepts, how to think about them, and some concrete examples with strategies to handle them in the next chapters. 🚀
diff --git a/docs/en/docs/deployment/server-workers.md b/docs/en/docs/deployment/server-workers.md
@@ -0,0 +1,178 @@
+# Server Workers - Gunicorn with Uvicorn
+
+Let's check back those deployment concepts from before:
+
+* Security - HTTPS
+* Running on startup
+* Restarts
+* **Replication (the number of processes running)**
+* Memory
+* Previous steps before starting
+
+Up to this point, with all the tutorials in the docs, you have probably been running a **server program** like Uvicorn, running a **single process**.
+
+When deploying applications you will probably want to have some **replication of processes** to take advantage of **multiple cores** and to be able to handle more requests.
+
+As you saw in the previous chapter about [Deployment Concepts](./concepts.md){.internal-link target=_blank}, there are multiple strategies you can use.
+
+Here I'll show you how to use <a href="https://gunicorn.org/" class="external-link" target="_blank">**Gunicorn**</a> with **Uvicorn worker processes**.
+
+!!! info
+    If you are using containers, for example with Docker or Kubernetes, I'll tell you more about that in the next chapter: [FastAPI in Containers - Docker](./docker.md){.internal-link target=_blank}.
+
+    In particular, when running on **Kubernetes** you will probably **not** want to use Gunicorn, and instead run **a single Uvicorn process per container**, but I'll tell you about it later in that chapter.
+
+## Gunicorn with Uvicorn Workers
+
+**Gunicorn** is mainly an application server using the **WSGI standard**. That means that Gunicorn can serve applications like Flask and Django. Gunicorn by itself is not compatible with **FastAPI**, as FastAPI uses the newest **<a href="https://asgi.readthedocs.io/en/latest/" class="external-link" target="_blank">ASGI standard</a>**.
+
+But Gunicorn supports working as a **process manager** and allowing users to tell it which specific **worker process class** to use. Then Gunicorn would start one or more **worker processes** using that class.
+
+And **Uvicorn** has a **Gunicorn-compatible worker class**.
+
+Using that combination, Gunicorn would act as a **process manager**, listening on the **port** and the **IP**. And it would **transmit** the communication to the worker processes running the **Uvicorn class**.
+
+And then the Gunicorn-compatible **Uvicorn worker** class would be in charge of converting the data sent by Gunicorn to the ASGI standard for FastAPI to use it.
+
+## Install Gunicorn and Uvicorn
+
+<div class="termy">
+
+```console
+$ pip install uvicorn[standard] gunicorn
+
+---> 100%
+```
+
+</div>
+
+That will install both Uvicorn with the `standard` extra packages (to get high performance) and Gunicorn.
+
+## Run Gunicorn with Uvicorn Workers
+
+Then you can run Gunicorn with:
+
+<div class="termy">
+
+```console
+$ gunicorn main:app --workers 4 --worker-class uvicorn.workers.UvicornWorker --bind 0.0.0.0:80
+
+[19499] [INFO] Starting gunicorn 20.1.0
+[19499] [INFO] Listening at: http://0.0.0.0:80 (19499)
+[19499] [INFO] Using worker: uvicorn.workers.UvicornWorker
+[19511] [INFO] Booting worker with pid: 19511
+[19513] [INFO] Booting worker with pid: 19513
+[19514] [INFO] Booting worker with pid: 19514
+[19515] [INFO] Booting worker with pid: 19515
+[19511] [INFO] Started server process [19511]
+[19511] [INFO] Waiting for application startup.
+[19511] [INFO] Application startup complete.
+[19513] [INFO] Started server process [19513]
+[19513] [INFO] Waiting for application startup.
+[19513] [INFO] Application startup complete.
+[19514] [INFO] Started server process [19514]
+[19514] [INFO] Waiting for application startup.
+[19514] [INFO] Application startup complete.
+[19515] [INFO] Started server process [19515]
+[19515] [INFO] Waiting for application startup.
+[19515] [INFO] Application startup complete.
+```
+
+</div>
+
+Let's see what each of those options mean:
+
+* `main:app`: This is the same syntax used by Uvicorn, `main` means the Python module named "`main`", so, a file `main.py`. And `app` is the name of the variable that is the **FastAPI** application.
+    * You can imagine that `main:app` is equivalent to a Python `import` statement like:
+
+        ```Python
+        from main import app
+        ```
+
+    * So, the colon in `main:app` would be equivalent to the Python `import` part in `from main import app`.
+* `--workers`: The number of worker processes to use, each will run a Uvicorn worker, in this case 4 workers.
+* `--worker-class`: The Gunicorn-compatible worker class to use in the worker processes.
+    * Here we pass the class that Gunicorn can import and use with:
+
+        ```Python
+        import uvicorn.workers.UvicornWorker
+        ```
+
+* `--bind`: This tells Gunicorn the IP and the port to listen to, using a colon (`:`) to separate the IP and the port.
+    * If you were running Uvicorn directly, instead of `--bind 0.0.0.0:80` (the Gunicorn option) you would use `--host 0.0.0.0` and `--port 80`.
+
+In the output you can see that it shows the **PID** (process ID) of each process (it's just a number).
+
+You can see that:
+
+* The Gunicorn **process manager** starts with PID `19499` (in your case it will be a different number).
+* Then it starts `Listening at: http://0.0.0.0:80`.
+* Then it detects that it has to use the worker class at `uvicorn.workers.UvicornWorker`.
+* And then it starts **4 workers**, each with its own PID: `19511`, `19513`, `19514`, and `19515`.
+
+Gunicorn would also take care of managing **dead processes** and **restarting** new ones if needed to keep the number of workers. So that helps in part with the **restart** concept from the list above.
+
+Nevertheless, you would probably also want to have something outside making sure to **restart Gunicorn** if necessary, and also to **run it on startup**, etc.
+
+## Uvicorn with Workers
+
+Uvicorn also has an option to start and run several **worker processes**.
+
+Nevertheless, as of now, Uvicorn's capabilities for handling worker processes are more limited than Gunicorn's. So, if you want to have a process manager at this level (at the Python level), then it might be better to try with Gunicorn as the process manager.
+
+In any case, you would run it like this:
+
+<div class="termy">
+
+```console
+$ uvicorn main:app --host 0.0.0.0 --port 8080 --workers 4
+<font color="#A6E22E">INFO</font>:     Uvicorn running on <b>http://0.0.0.0:8080</b> (Press CTRL+C to quit)
+<font color="#A6E22E">INFO</font>:     Started parent process [<font color="#A1EFE4"><b>27365</b></font>]
+<font color="#A6E22E">INFO</font>:     Started server process [<font color="#A1EFE4">27368</font>]
+<font color="#A6E22E">INFO</font>:     Waiting for application startup.
+<font color="#A6E22E">INFO</font>:     Application startup complete.
+<font color="#A6E22E">INFO</font>:     Started server process [<font color="#A1EFE4">27369</font>]
+<font color="#A6E22E">INFO</font>:     Waiting for application startup.
+<font color="#A6E22E">INFO</font>:     Application startup complete.
+<font color="#A6E22E">INFO</font>:     Started server process [<font color="#A1EFE4">27370</font>]
+<font color="#A6E22E">INFO</font>:     Waiting for application startup.
+<font color="#A6E22E">INFO</font>:     Application startup complete.
+<font color="#A6E22E">INFO</font>:     Started server process [<font color="#A1EFE4">27367</font>]
+<font color="#A6E22E">INFO</font>:     Waiting for application startup.
+<font color="#A6E22E">INFO</font>:     Application startup complete.
+```
+
+</div>
+
+The only new option here is `--workers` telling Uvicorn to start 4 worker processes.
+
+You can also see that it shows the **PID** of each process, `27365` for the parent process (this is the **process manager**) and one for each worker process: `27368`, `27369`, `27370`, and `27367`.
+
+## Deployment Concepts
+
+Here you saw how to use **Gunicorn** (or Uvicorn) managing **Uvicorn worker processes** to **parallelize** the execution of the application, take advantage of **multiple cores** in the CPU, and be able to serve **more requests**.
+
+From the list of deployment concepts from above, using workers would mainly help with the **replication** part, and a little bit with the **restarts**, but you still need to take care of the others:
+
+* **Security - HTTPS**
+* **Running on startup**
+* ***Restarts***
+* Replication (the number of processes running)
+* **Memory**
+* **Previous steps before starting**
+
+## Containers and Docker
+
+In the next chapter about [FastAPI in Containers - Docker](./docker.md){.internal-link target=_blank} I'll tell some strategies you could use to handle the other **deployment concepts**.
+
+I'll also show you the **official Docker image** that includes **Gunicorn with Uvicorn workers** and some default configurations that can be useful for simple cases.
+
+There I'll also show you how to **build your own image from scratch** to run a single Uvicorn process (without Gunicorn). It is a simple process and is probably what you would want to do when using a distributed container management system like **Kubernetes**.
+
+## Recap
+
+You can use **Gunicorn** (or also Uvicorn) as a process manager with Uvicorn workers to take advantage of **multi-core CPUs**, to run **multiple processes in parallel**.
+
+You could use these tools and ideas if you are setting up **your own deployment system** while taking care of the other deployment concepts yourself.
+
+Check out the next chapter to learn about **FastAPI** with containers (e.g. Docker and Kubernetes). You will see that those tools have simple ways to solve the other **deployment concepts** as well. ✨
diff --git a/docs/en/docs/img/deployment/concepts/image01.png b/docs/en/docs/img/deployment/concepts/image01.png